Validate a Google Ads JSON Feed Before It Reaches Your Dashboard

A JSON file can parse successfully and still be the wrong input for an advertising dashboard. It might contain only the first page of results, mix account currencies or repeat yesterday's rows after a retry. Syntax validation catches none of those problems.

When an engineering team takes ownership of a Google Ads reporting feed, agree on a data contract before scheduling imports. The contract should say what one row represents, which reporting period it belongs to and how the receiver decides that a delivery is complete.

Identify the route that produced the file

Ask whether the producer called the Google Ads REST API, transformed a downloaded report or exported a warehouse table. These routes can produce different field names and nesting even when the analyst asked for the same metrics.

Do not assume a flat object with keys such as campaign.id is the untouched REST response. A connector may deliberately flatten the data into its own schema. Keep the source format and your internal format documented separately, with an example of the transformation between them.

Guangsuan's overview of routes for exporting Google Ads data to JSON is a useful starting point for choosing between an API, a local conversion and a warehouse. For the exact response shape your parser consumes, use the current API documentation or the connector's documented output.

Write down the row grain before choosing a key

“One row per campaign” is incomplete if the query also segments by date, device or network. Include every dimension that distinguishes a row in the import key. Otherwise, valid rows can overwrite one another or be mistaken for duplicates.

For example, a daily campaign-by-device dataset needs the account, campaign, date and device in its logical key. That is a teaching example, not a universal key for all Ads reports. Add or remove dimensions according to the actual query.

Record these details alongside each delivery:

• The account identifier, reporting time zone and currency.
• The requested date range and the time the extraction ran.
• The query or versioned report definition, including filters and segments.
• The meaning and unit of each metric, including any unit conversion performed by the producer.
• The conversion columns selected, so a later report does not silently change the reporting basis.

Preserve identifiers as identifiers, not quantities for arithmetic. If cost is supplied in micros, document the conversion to currency units and apply it exactly once. A receiver should not divide an already-normalized amount again.

Make completion an explicit condition

Google's Search and SearchStream documentation distinguishes paginated Search responses from streamed results. For Search, continue using the returned page token until the result set is complete. A successful first request is not proof that all rows have arrived.

For streaming or connector delivery, use that route's completion signal and failure handling. If a connection breaks, retain the partial delivery for diagnosis but do not publish it as a complete reporting period. A plausible row count is not a substitute for a known successful finish.

Write incoming rows into a staging batch. Check required fields, types, duplicate keys and completion before promoting the batch to the reporting table. Keep a batch identifier and extraction timestamp so an operator can trace a displayed figure back to its input.

Reconcile totals without double-counting a retry

Compare a small, known report slice with the corresponding account report using the same dates, filters, currency and conversion basis. Investigate differences before widening the import. If a total differs, first check missing pages, mismatched segments and unit transformations rather than immediately blaming the reporting service.

A retry should replace or merge the same logical slice according to an explicit rule. Blindly appending the file can double spending and clicks. On the other hand, treating every repeated key as an error can reject legitimate refreshed metrics. Define whether a later extraction is allowed to update the earlier value, and retain enough history to explain the change.

The acceptance test is practical: can someone identify the account and period, establish that the delivery finished, reconcile a sample and rerun it without duplicating the result? Once those checks pass, valid JSON becomes useful reporting data rather than just a readable file.