Skip to content

Analytics9 min

When GA4 shows half the purchases: a tracking audit in an online store

Ads are running, orders arrive, and none of the reports agree. In this store Meta caught about 95 percent of purchases while GA4 caught fewer than half. Below: the three causes we found by measuring, and how to tell them apart in your own store.

In short

  • 13 tracking cookies before consent, zero after the fix
  • Withdrawal used to delete 1 cookie out of 22
  • Consent Mode failed because another plugin rewrote the page
  • Server-side sending ran with no consent check at all
  • After the fix, attributed orders drop, and that is correct

Where it started: ads work, reports disagree

A mid-sized WooCommerce store. Ads run on several platforms, orders come in, and the reports do not agree with each other. Meta shows almost every purchase, Analytics fewer than half, and the store admin a third number.

Before changing anything we measured the current state and wrote it down as the baseline. Without it there is no way to say whether a week of work made things better. Measurements were taken in a clean browser session and repeated the same way after every change.

What we found: 13 cookies before the question is even asked

Before the consent banner was touched, the browser already held 13 tracking cookies, and seven different third-party servers had received a request. Among them was a live Universal Analytics tag on a property Google shut down in 2024.

Withdrawing consent removed one cookie out of twenty-two. Not because the consent platform is bad, but because one of its settings was off, and without it the deletion queue never runs. Switching that same setting on dropped the survivors from twelve to four immediately.

Why Consent Mode failed in both directions

Google Consent Mode was enabled and still never activated. The cause was in another plugin: it opens an output buffer and rewrites the whole page HTML, renaming the data layer. The consent calls ended up in the rewritten copy, which Google does not read.

This is a good illustration of why an audit has to be measured rather than read out of the settings. In the settings everything looked correct. In the browser the consent signal never reached its destination, before consent or after it.

The hardest finding: a send that leaves no trace in the browser

A conversions API was live on the server side. Every order went straight to the ad platform with a hashed email, phone, name and date of birth attached, and no consent check stopped that path. A send like this leaves no trace in the browser, so neither the browser tools nor an audit read from HTML will find it.

That is why it was the first thing we fixed, before touching the banner or the documents. A filter reads the consent record stored on the order and sends only when consent was given. We verified it in both directions with real orders: a consenting visitor's purchase reaches the platform, a refusing visitor's does not.

What else we fixed, and what it changed in the reports

In the Tag Manager container we found seven dead Universal Analytics tags and two tags sending the visitor's email and IP as ordinary parameters, although nothing ever filled them. A second website was mixing its traffic into the same Analytics property through the shared container. We cleaned the container and separated the other site.

On the Meta side two pixels were running, and the one collecting data was the one not used for advertising. We kept one. Worth knowing upfront: after work like this the number of attributed orders in the reports goes down, because some of them had been attributed without consent. That is the correct number, not a regression.

How to check your own store

The first test takes a minute: a private window, browser tools, the Application tab, and count the cookies before touching the banner. Zero is the only correct answer. The second test: accept, withdraw, and count again.

The third needs one real order: place it and count how many purchase events reached each system and whether the amounts match. If two showed up anywhere, the reports flatter you until somebody starts allocating an ad budget on them. Audit €200 + VAT, get in touch.

End

FAQ.

Will blocking before consent reduce my conversions?

It reduces the reported number, not the sales. How much depends on your refusal rate. Until then part of the data was collected without a legal basis, so the new number is the correct one. We say this before the work, not after.

Where do we start if we cannot do all of it at once?

With the server-side sending. It is the only thing invisible in the browser and the only one you will never notice yourself. Everything else can wait a week; that cannot.

Can this be done without touching the ad campaigns?

Yes. Campaigns and budgets stay untouched. Only what sends data, and when, changes. If campaigns optimise on conversions, warn the ad team beforehand, because the numbers will move.

Next article

A cookie banner that blocks nothing: what we found and what we fixed