GA4 and Google Ads don't match: why the gap doesn't test your tracking

The gap does not show the most expensive error

If you want to know whether your tracking is right, do not compare GA4 and Google Ads with each other. If both tags hang off the same purchase event in the checkout and that event partly fails, both lose in the same proportion, and the difference stays exactly as it was. That is my own deduction, not a Google rule. Google itself describes discrepancies of often up to 20% as expected, and that does not help you either: a 20% gap can look exactly the same with healthy tracking and with broken tracking.

A worked example with invented figures, in euros per week, same shop, same budget:

In the second column, a quarter of the revenue measurement is missing, and the gap sits calmly at 20%. With €8,000 in costs, Google Ads then reports a ROAS of 3.75 instead of 5.0. A strategy with a target ROAS of 5.0 sees too little value and may lower bids, even though the shop is selling exactly as before. That costs revenue, and comparing the two platforms reports nothing.

In the two right-hand columns the gap does move, but it does not tell you which side is broken. In my view, it can also move without any fault at all, for example when you change the channel setting or shift budget into campaigns with longer purchase journeys. As a signal, it therefore fails in both directions.

The main check: Ads against orders with a click ID

Compare each source separately against the shop, and compare Google Ads only against the orders that can have come from an ad click. A comparison against the whole shop would spike with every newsletter and every discount campaign.

Ads coverage = Conv. value (by conv. time) of the purchase action ÷ order value of shop orders with a click ID GA4 capture rate = GA4 purchase revenue across all channels ÷ order value of all shop orders

For this, the shop has to store the click ID with the order, independently of the purchase tag. If the event then fails, the order stays in the system with its ID, and only the numerator drops. This is how you set it up:

• Store all three parameters from the landing page URL: gclid, wbraid (iOS app to website) and gbraid (web to iOS app). The gclid alone is not enough, because Google no longer sends it for iOS traffic from some Google apps.
• Keep the ID on the server side. Safari can limit cookies set via JavaScript to 24 hours after clicks with URL parameters, and anyone who buys two days later is then missing from your denominator.
• Use Conv. value (by conv. time) for the primary purchase action only, the same days and the same value definition (gross or net, with or without shipping), and only count IDs that are younger than your conversion window.
• Check with your data protection adviser beforehand whether, and from which consent onwards, you may store the IDs.

A hundred per cent is not the goal: modelled conversions, including cross-device ones, often have no matching ID in the shop. So I would check the level once with test purchases for each payment method and then take your own corridor from eight full weeks. Investigate if a rate falls outside it two weeks in a row, or immediately in the case of a large swing.

How to read the result:

Why the figures differ and which one applies to what

The discrepancy itself is usually not an error. Suppose someone clicks your ad on 28 March, returns via organic search on 3 April and buys for €100. Google Ads assigns the value to 28 March, because according to Google the primary columns are based on the time of the click. GA4 shows the purchase in April in its usual reports, and under the Paid and Organic Last Click model the full value goes to the last channel that was clicked, in this case Organic.

Then there is the lookback window: for purchases, GA4 looks back 90 days by default, Google Ads as far as you have set in the conversion action. Both systems also model separately. That is why the two figures will never become one, and they do not need to, as long as you use each for its own question:

Fault found: protect the bidding

Put the date of the break next to shop releases, Tag Manager versions and banner updates, and fix the cause first. Meanwhile, the damage to bidding continues, and that is what data exclusions are for. They apply to click dates and, according to Google, should cover at least 90% of the affected clicks. If the event was broken from the 10th to the 14th and around 90% of your purchases come within 5 days of the click, you exclude the 5th to the 14th. Bids can still drop briefly. In that case, lower the ROAS target temporarily and leave the exclusion in place. According to Google, the tool is not intended for frequent or long-term use.

If only consent drops, for example after a new banner, I treat that as a new baseline. Whether it really is only consent is shown by a test visit with the banner declined in Tag Assistant: the default status has to be "Denied", and in basic mode the Google tags are then blocked, while in advanced mode they send measurements without cookies. If that is confirmed, adjust your corridor and target and leave out the exclusion.

No click IDs, no alarm threshold

If your shop does not store click IDs, you are left with the GA4 capture rate and test purchases until it is rebuilt. The Ads side can then only be checked roughly, and I would not use a comparison against the whole shop as an alarm. If your purchase action comes in as a GA4 import rather than through its own Ads tag, Google Ads depends on GA4, and cases where only one rate falls hardly occur any more. Below roughly 100 orders a week I would compare months; that is a rule of thumb. Long purchase cycles need more time to mature before you assess a week. A large volume of orders by phone or in store should be taken out of the denominator before the comparison. Google information as of November 2026.