Here is a true story. On an online shop we know well, GA4 was counting every sale twice: two purchases recorded for one actually delivered, 298 EUR displayed for 149 real. No alert, no error message. The dashboards were green. The figures were false.
The most instructive part: the shop belongs to a publisher of tracking solutions. If it happens at a specialist’s, ask yourself the question for your own shop. As consultants, it is one of the first things we check in an audit, and one of the most often broken.
In this article: why marketing measurement degrades in silence, what server-side tracking really repairs, and the method we apply to check whether a tracking setup is telling the truth.
Why your figures are wrong, and increasingly so
Three forces have been working against your measurement for years:
- Ad blockers, which stop pixels from loading.
- iOS and browsers, which shorten or delete cookies.
- The disappearance of third-party cookies, which breaks the link between the ad click and the purchase. It did not happen as announced, but what actually changed is enough to degrade attribution.
The result is always the same: advertising platforms see only part of your conversions. Your campaigns look less profitable than they are. And since the bidding algorithms at Google and Meta optimise on that incomplete data, they make bad decisions with your budget. You pay twice: in lost visibility, then in misallocated spend.
Server-side tracking, explained simply
The principle fits in one sentence: instead of relying on the visitor’s browser, and on everything that can get in its way, your shop’s server sends conversions directly to Meta, Google Ads and GA4.
A browser can block a pixel. It cannot block a server-to-server conversation. In the case mentioned above, real sales that had left no cookie behind (79 and 149 EUR) were transmitted to the platforms with their order identifiers. Without server-side, they were invisible.
An important clarification, because the subject is often sold the wrong way round: server-side is not there to get around consent. Without marketing consent, nothing should leave, full stop. It is there to make measurement reliable for visitors who did consent. We come back to this below.
The real problem: nobody watches after installation
Plenty of providers know how to install server-side tracking. But once the plumbing is laid, who checks that it keeps telling the truth?
That is the blind spot of the whole market, and where we see the most damage in audits. Broken tracking does not crash your site or send an error email. It lies in silence, sometimes for weeks, while your bids optimise on false data and your reports steer bad decisions.
The discipline goes beyond tracking, to anything that displays without erroring: we applied it to this site’s own loading speed, and two of the six fixes we deployed changed nothing at all. The measured detail is in this site went from 73 to 99.
Back to the GA4 case: the anatomy of a silent lie
Before we get to it, a useful clarification: most gaps of this kind do not come from server-side itself, but from a configuration nobody ever documented. That is the job of the tagging plan, and it is also why GA4 is badly configured almost everywhere.
Back to the story. The cause of the double counting was entirely ordinary: the purchase was sent twice, once by the browser, once by the server. And contrary to its reputation, GA4 does not deduplicate.
What caught the bug was a reconciliation table: a table comparing, day by day, what the site actually delivered against what GA4 and Google Ads recorded. The gap jumped out on first reading, and the bug was fixed the same day: one single source of truth for the purchase event, no more double counting.
The mistake that costs most Sending your conversions both browser-side and server-side, relying on GA4 to deduplicate. This configuration is extremely widespread. If nobody has ever compared your figures line by line, you do not know whether your GA4 is telling the truth.
Our audit method: the five checks that count
Here is what we look at when we audit an online retailer’s measurement, within our data and analytics expertise. It makes a good basis for self-diagnosis:
| Check | What we look at | Warning sign |
|---|---|---|
| Reconciliation | The number of real orders in your back office against what GA4 and Google Ads display, day by day | A gap that varies for no reason. A stable gap can be corrected |
| Abnormal silence | The hours with no conversion at all | Zero at 3am is normal, zero at 2pm is not. And you have to notice it the same day, not in the monthly review |
| Delivery failures per destination | The result of sends, platform by platform | A stream that works towards Meta and fails towards Google Ads. From a distance, “the tracking works” |
| Matching identifiers | The presence of hashed emails and order identifiers in your events | They become rarer: platforms attribute less and less well, without ever telling you |
| Consent | The share of your events carrying a clear consent state | The share of “unknown” rises: your cookie banner or its integration has probably degraded. A compliance risk as much as a measurement one |
The seven-day self-diagnosis Doable this week, with no tool at all: take your last seven days and compare, day by day, your real orders against the purchases seen by GA4 and by Google Ads. If the three lines do not tell the same story, you know where to dig.
Tooling: automating the watch rather than redoing it by hand
Running these checks by hand every day is not realistic for an SME. It is a tooling job, not a willpower one.
For our clients we deploy DataFirefly Server-Side. Full transparency: the tool is published by Datafirefly Limited, the sister company of our agency, and it is precisely because we know it from the inside that the GA4 case above was detected and fixed the same day. It automates exactly the method above: daily reconciliation, anomaly detection with a plain-language explanation, a fix recipe, and a signal health score. The modules install with a connection key on PrestaShop, WooCommerce and Shopware, with no server-side Google Tag Manager to host. And every sensitive action stays validated by a human, never applied automatically.
The free plan (0 EUR, no card, one site, 10,000 requests a month) is enough to plug reconciliation into your shop and check, figures in hand, whether your tracking is telling you the truth. Paid plans start at 39 EUR a month.
One last thing we appreciate as consultants: the read-only AI connector. You paste an address into Claude or ChatGPT, and your assistant answers your questions (“which destination failed most this week?”) using your real figures, without being able to change anything: reading is the only capability exposed.
That said, the method matters more than the tool: whichever one you choose, insist on a figures-based reconciliation, same-day alerts, and correct behaviour on consent. A tool that only sends events without ever watching itself reproduces the very problem it claims to solve.
Consent: what server-side must respect
The GDPR does not disappear because events leave from the server. What we check systematically:
- Deny by default: without marketing consent, nothing leaves. With no cookie banner detected, the default setting must be refusal, never the opposite.
- CMP compatibility: the tool must adapt to your existing banner, whichever it is, not require you to change it.
- Traceability: the consent state must travel inside every event, so that compliance is verifiable event by event rather than declared in good faith.
A server-side setup that “recovers” visitors who refused is not an optimisation, it is a breach. Avoid providers who sell it that way.
The same logic now extends to artificial intelligence: knowing what is running in your shop, and being able to prove it. That is the whole subject of the AI Act for an online shop, and the approach is the same as here, an inventory before anything else.
FAQ
Is server-side tracking legal in Europe?
Yes, provided consent is respected. Done properly, it sends the conversions of visitors who consented, more reliably. It must never be used to measure those who refused.
I already have GA4 and the Meta pixel. Why would my figures be wrong?
Because pixels depend on the browser, and blockers and iOS restrictions make part of them disappear. And because a configuration error, such as the browser-plus-server double send above, falsifies the figures without triggering the slightest alert.
How do I know if my tracking is broken right now?
Compare your last seven days of real orders against the purchases seen by GA4 and Google Ads, day by day. A noticeable gap deserves investigation. That is exactly what a reconciliation table automates.
Can Dotsland help with this?
Yes. Auditing your measurement, setting up server-side, building a tracking plan and following it over time. Get in touch, or start with the seven-day self-diagnosis above: it is free and often very telling.