Most broken conversion tracking does not look broken. It reports a number, the number is plausible, and the only symptom is that budget slowly drifts toward whatever fires the event most cheaply. I have found this on accounts that had been running for years with nobody suspecting anything, and the check that finds it takes about an hour.
The reason it hides is that every measurement system in the stack is designed to keep reporting something. A broken tag does not throw an error into a dashboard. A conversion action pointed at the wrong page still records conversions. A duplicated event doubles a count without ever looking anomalous. Nothing in the interface is going to raise its hand.
Why the platforms disagreeing is not the problem
The first instinct when two numbers differ is to reconcile them against each other. That is the wrong referee. Ad platforms credit the click and report it on the click date; Analytics attributes across sessions and keeps revising. Google states that attributed key events can be updated for up to 7 days after the event is recorded, which means today’s screenshot is provisional by design.
The window setting compounds it. The default conversion window is 90 days, while more than 95% of key events are attributed within the first 14. A long window is not more accurate, it is mostly a longer tail of noise, and changing it does not change performance, only the description of performance.
Google’s own documentation puts more than 95% of key events inside 14 days, against a default window of 90.
So the referee has to be something neither platform controls: the orders the business actually shipped and was paid for.
The browser is the other half of the problem
Even a correctly configured window cannot outrun the storage it depends on. Under Safari’s tracking prevention, persistent cookies written through document.cookie are capped to one day of storage when a visitor arrives via a decorated link from a domain classified as a cross-site tracker. A 90-day window on top of one day of storage is a setting, not a measurement.
This is also why the test has to be run on a phone. Mobile is 52.57% of worldwide traffic against 45.93% for desktop, so the mobile path is the majority case rather than an edge case, and it is the one where storage restrictions bite hardest.
On one lead-gen account I audited, the tracking turned out to be almost correct. What was wrong sat one layer up: a conversion action counted a form view rather than a submission, so the cheapest traffic in the account looked like the best. Nothing in any report said so. The only thing that exposed it was walking the path and comparing what fired against what the CRM received.
What a defensible setup looks like
A conversion action is defensible when three things are true of it. It fires once per outcome, it fires only on the outcome the business is actually paying for, and it carries an identifier the business system also holds, so any disagreement can be settled row by row rather than argued in percentages. Most accounts satisfy the first condition, assume the second, and have never attempted the third.
The identifier is the part usually missing, and it is the cheapest of the three to add. Sending an order reference with the conversion turns an argument about totals into a reconciliation with a list of specific missing rows, which is the difference between suspecting a problem and being able to name it.
What it costs to leave broken
The damage is not the wrong number in the report. It is that every automated bidding system in the account is trained on that number. A conversion action that fires on a form view rather than a submission teaches the machine that the cheapest, least-committed traffic is the most valuable, and it will faithfully buy more of it. The account does not fail loudly, it quietly optimises toward the wrong thing, and the reports agree with themselves throughout.
That is why this belongs before any structural work rather than after. Bid strategy, budget allocation and creative testing all inherit whatever the conversion signal says. Optimising on top of a signal nobody has verified is expensive precision applied to a question the account cannot answer.
When to run it
Run this on every account inherited from someone else, before touching a bid. Run it again after any site release, theme update, consent-banner change or checkout edit, because tracking almost always breaks during a deployment that nobody thought of as a marketing change. And run it quarterly on anything stable, since the failure mode here is silence rather than an alert.
How to do it
- Reconcile three counts for one fixed date range. Pull orders or qualified leads from the business system, conversions from Analytics, and conversions from each ad platform, for the same seven-day range that ended at least a week ago. Write the three numbers side by side before forming any theory about them.
- Buy from yourself on a phone, on mobile data. Complete a real purchase or form submission end to end on a phone using mobile data rather than office wifi, following an ad click rather than typing the URL. A zero-priced test product makes this free to repeat as often as needed.
- Compare what fired against what was recorded. Check that the transaction from that test appears exactly once in Analytics, exactly once in the ad platform, and once in the business system, with the same value and currency. A mismatch here is a defect, not a rounding difference between vendors.
- Audit which page can fire the conversion action. List every page capable of firing the conversion event, then ask whether each one represents the outcome the business is paying for. Form views, thank-you pages reachable without converting, and careers pages are the usual culprits behind cheap fake conversions.
- Set the window to the real sales cycle, then leave it alone. Choose a conversion window that matches how long buying actually takes for this business, document why that number was chosen, and stop adjusting it. Changing a window mid-flight rewrites reported history and feels like optimisation while changing nothing real.
- Re-check the same range after seven days. Return to the identical date range a week later and confirm the numbers settled where expected, because late attribution keeps revising figures after the fact. Anything that moved substantially indicates a modelling assumption worth understanding before trusting the account's reporting.
Common questions
How long should a conversion window be?
Set it to match the real sales cycle, not the maximum available. Google's default is ninety days, but more than 95% of key events are attributed within the first fourteen. A long window mostly adds noise, and changing it mid-flight alters the reported history rather than the underlying performance.
Why do Google Ads and Analytics report different conversion counts?
Ad platforms and Analytics count different things. A platform credits the click that led to a conversion and reports it on the click date, while Analytics attributes across sessions and can revise figures for up to seven days afterwards. Neither is wrong, and neither should be reconciled without the shop's own order data.
Does Safari break conversion tracking?
Safari limits it rather than breaking it. Persistent cookies written by script are capped to a single day of storage when a visitor arrives through a decorated link from a domain classified as a tracker. Longer windows configured in a reporting interface cannot survive that, so server-side measurement matters more.
How often should conversion tracking be audited?
Quarterly for a stable account, and immediately after any site release, theme update, consent-banner change or checkout edit. Most tracking breaks silently during a deployment nobody connected to marketing, and the damage is only visible weeks later when spend has already followed the wrong signal.