Five reporting traps that can mislead a Google Ads optimizer
Why date ranges, segmentation, missing zero rows and conversion lag can turn a valid GAQL query into a bad automated decision.
Written by Touch Stone Editorial Team
Reviewed by Touch Stone Ads Technology Limited
Correct syntax does not guarantee correct evidence
GAQL makes it easy to request metrics and segments, but every added segment changes the grain of the result. A row that looks duplicated may represent a different date, device or implicit resource dimension. Summing or joining it incorrectly can inflate the evidence used by an optimizer.
Define the decision grain first: campaign-day, keyword over a fixed window, or search term within an ad group. Then review whether every selected segment belongs in that grain. If a dimension is used only for investigation, keep it out of the production decision query.
Dates, time zones and windows need explicit ownership
When date segments are selected, Google requires a finite date range. Relative date constants are convenient, but an automated recommendation should store the resolved start and end dates as well as the account time zone. Otherwise the same operation may be impossible to reproduce later.
Long-term systems also need to monitor API reporting constraints. Google documents version-specific limits for granular date segments, so a query that worked for historical analysis may require aggregation or a different extraction strategy in a later API version.
No row is not always a zero
Conversion reporting can omit rows that have no metrics, depending on the resource and query. An optimizer that fills every missing row with zero may classify an entity as failing when the real state is absent, delayed or outside the selected grain.
Model missing, zero and not-yet-mature as distinct states. Reconcile totals against a known interface view for representative accounts, and add tests for campaigns with no activity, removed entities and delayed conversions.
- Verify row grain before aggregation.
- Resolve relative dates and store the exact window.
- Distinguish missing data from measured zero.
- Exclude or flag immature conversion periods.
- Test joins for implicit segmentation and duplicate-looking rows.
Make data readiness a gate
Before producing a recommendation, the system should validate query completion, expected columns, row count, freshness and reconciliation tolerances. If those checks fail, the correct output is data not ready, not a low-confidence optimization.
Store the reviewed query or query version with each proposal. That makes a later change in metrics, segments or attribution treatment visible instead of silently altering the meaning of the automation.