Seven production catches from live Google Ads queries that dashboards rolled over: conversions inflated 6.5x by silent summing, renamed campaigns zeroing reports, target ROAS read at the wrong level, "done" work that didn't exist in the account, cost metrics that change meaning by campaign type, a mislabeled client-side tag, and a catalog reporting twice its true size.
Dashboards report what a system believes about itself. A live query cross-examines it. These seven came out of production accounts, each one invisible on the surface the platform shows by default, each one found by querying the account directly.
On one account, reported conversions ran 6.5x above reality. The conversions metric was silently adding every conversion action together: purchases, sign-ups, everything, one number. The dashboard was not wrong; it was answering a different question than anyone thought they were asking. A query segmented by conversion action name exposed the blend in one pass. Until then, every efficiency number built on it was fiction.
Reports filtered on campaign names return zero rows the day the campaign gets renamed, and nothing warns you. One account's naming convention changed mid-quarter; any name-based pull from that day forward would have quietly dropped the campaign from every report. The durable fix: query by campaign ID or by channel type, which asks the account what a campaign is instead of guessing from what it is called.
Campaign-level and ad-group-level target ROAS can tell two different stories on the same day in the same account. Only one of them is the number the bidding system is actually using. A dashboard shows whichever level you happen to be looking at; a query pulls both and shows which one is load-bearing.
A checklist recorded video conversion goals as configured on June 26. A live pull on July 1 found zero such conversion actions in the account, while campaigns depending on them were already spending. Assigned and done are different claims. The gap between them is invisible right up until it costs something, and only a query against the live system distinguishes them.
Performance Max cost-per-acquisition reads from a different conversions column than Search. Read the wrong one and PMax cost per booking looks roughly 3x better than it is. Documented API behavior, operationalized almost nowhere. The fix is a standing rule specifying the column per campaign type, so the number cannot drift based on who ran the report.
A conversion action named after a server-side tracking vendor was, on inspection of its actual type, firing client-side. The label promised one measurement architecture; the configuration delivered another. No interface view states an action's type outright. It takes querying the type field directly, across every action in the account, to know which of your conversions are what they claim to be.
The ads platform's reporting view claimed roughly 8,291 products. Merchant Center, queried directly, showed 4,076 active. The ads view retains historical inactive products indefinitely, so every analysis reasoning from the larger number was reasoning about inventory that no longer exists. The gap only appears when the two systems' answers sit next to each other.
The pattern across all seven: the dashboard was never lying. It was summarizing, and the defect lived in what the summary rolled over. A live query does not summarize; it answers the question asked, against the account as it exists right now.
How the query layer works: the live-query stack hub. What it looks like applied to your account:
These seven, and the rest, checked against your own account — a structured read with every finding traceable to a query.
Get in touch.
Are these rare edge cases?
Items 1, 2, 5, and 7 are structural: they exist in any account with multiple conversion actions, evolving naming, PMax, or a mature catalog. The other three are common enough that we check for them on every account.
Can I find these in the Google Ads UI?
Some, one screen at a time, if you already know exactly where to look. The point of a query is finding the population of a problem at once, including the instances nobody suspected.
What tool does this require?
Any programmatic read access can do it. Akorn runs it through read-only MCP servers plus a maintained rulebook for how each number gets calculated; the rulebook is the part that keeps the answers consistent. See the live-query stack hub for how ours is built.