Why your GA4 and PrestaShop order counts don’t match (and how to fix it)
If Google Analytics 4 reports fewer purchases than your PrestaShop back office, you are not imagining it. Here is what causes the gap and how to close it.
Almost every PrestaShop merchant who looks closely finds the same thing: the order count in GA4 is lower than the order count in the back office. Sometimes it is off by a few percent. Often it is off by 30-50%. Either way, it quietly breaks every decision you make on top of that data — attribution, ad budgets, conversion rates, and the revenue you report to yourself.
The back office is the source of truth. It records every order that was actually paid for. GA4, by contrast, depends on a tag firing inside the customer's browser at exactly the right moment. When that tag does not fire, the order still happens — GA4 just never hears about it.
Once you understand the handful of mechanisms behind the gap, the fix is straightforward. Let us walk through each one, then look at how to close it for good.
The browser is a hostile place to count money
Classic GA4 tracking is client-side: a JavaScript snippet runs in the shopper's browser and sends the purchase event to Google. That sounds reliable until you remember everything that can go wrong between the order confirmation page and Google's servers.
The shopper closes the tab before the page fully loads. Their connection drops on mobile mid-redirect. A script error elsewhere on the page halts execution before your tag runs. The confirmation page redirects too fast for the beacon to leave. Each of these is invisible to you, and each one is a lost purchase event.
On checkout pages — the single most important page on your store — these failures cluster, because that is exactly where third-party payment redirects, slow networks, and impatient shoppers come together. The events you care about most are the ones the browser is least likely to deliver.
Ad-blockers and ITP eat your conversions
A large share of shoppers run ad-blockers or privacy extensions that block Google Analytics outright. For these visitors, the purchase simply never registers — the request to Google is cancelled before it leaves the browser. Estimates vary by audience, but blocking rates of ~30% are common, and meaningfully higher in tech-savvy or younger segments.
Apple's Intelligent Tracking Prevention (ITP) adds another layer. On Safari and iOS, ITP caps the lifetime of cookies set by client-side JavaScript — often to as little as 24 hours or 7 days. A visitor who clicks an ad today and buys next week looks like a brand-new, unattributed session. The order may still land in GA4, but stripped of the campaign that earned it.
Because Safari and iOS dominate mobile traffic in many markets, this is not an edge case — for plenty of stores it is the majority of mobile shoppers. Our glossary explains ITP and related terms in plain language.
Session inflation makes the gap look even worse
While ad-blockers and ITP shrink your conversions, a separate problem inflates your sessions. When cookies expire early, one person across several visits gets counted as several different users in several different sessions. Your denominator (sessions) goes up while your numerator (purchases) goes down.
The result is a conversion rate that looks far worse than reality. A store converting at a healthy 2.5% might show 1.4% in GA4 — not because anything changed on the site, but because the same buyers are being split into more sessions while their purchases quietly go missing.
Merchants then “optimise” against a number that was never accurate, cutting campaigns that were actually profitable and second-guessing a checkout flow that works fine. The data problem becomes a business problem.
Tax and transaction IDs distort the revenue side too
Even when an order is tracked, the revenue figure can be wrong. Many setups send the tax-excluded subtotal instead of the amount the customer actually paid. PrestaSignal sends tax-included revenue (the real total_paid_tax_incl) so GA4 matches the money that hit your account, which matters the moment you calculate ROAS or feed conversion values into bidding.
The other quiet killer is duplicate or random transaction IDs. If the purchase event can fire twice — once on confirmation, once on a page reload or a back-button click — and each fire uses a fresh random ID, GA4 counts two orders for one sale. Now you have undercounting from lost events and overcounting from duplicates, layered on top of each other, making the true number almost impossible to reason about.
The fix is a deterministic transaction_id derived from the order reference, so reloads and retries collapse into one order, every time.
The server-side fix
Server-side tracking moves the purchase event out of the fragile browser and into your store's backend. When PrestaShop confirms an order, the event is sent server-to-server — through a self-hosted sGTM container — where ad-blockers, ITP, and closed tabs cannot reach it.
Because the event originates from the order itself, it carries the true paid amount and a stable transaction_id. There is no race against a redirect, no dependency on the shopper keeping the tab open, no extension to cancel the request.
The best setups run a hybrid model: a deduplicated client-side event for behavioural richness plus a server-side event as the reliable backstop, both sharing one event_id so nothing double-counts. See server-side vs client-side for the full comparison, or read how it works on PrestaShop specifically.
What to expect after the fix
Once server-side purchase tracking is in place, the gap usually shrinks dramatically. You will not always hit a perfect 1:1 match — a handful of differences are legitimate, such as cancelled or fraudulent orders filtered out, or test orders excluded from analytics — but the structural 30-50% undercount disappears.
The knock-on effects are what merchants notice most. Conversion rate snaps back to a believable number. Campaign ROAS stops looking artificially poor, so you stop cutting winners. Revenue in GA4 lines up with revenue in your bank, which makes every downstream report — and every conversation with an agency or a marketplace — far easier to trust.
If you want to see your own gap measured against your real PrestaShop orders, book a teardown and we will quantify exactly how much GA4 is currently missing.
Quick questions
How big is the gap between GA4 and PrestaShop usually?+
It varies by audience and setup, but a 30-50% undercount is common for client-side-only stores. Mobile-heavy and privacy-conscious audiences tend to sit at the higher end.
Will server-side tracking make GA4 match my back office exactly?+
It gets you very close. Server-side events capture orders that client-side tags miss, so the remaining difference is usually small and explainable rather than a structural undercount.
Why does GA4 sometimes show more revenue than I expect?+
Usually duplicate purchase events with random transaction IDs counting one sale twice. A deterministic transaction_id from the order reference removes the duplicates.
Does this require changing my GA4 property?+
No. You keep the same GA4 property and measurement_id. Server-side tracking changes how events reach GA4, not where they land.
Can I keep my client-side GA4 tags as well?+
Yes, and you should. The hybrid approach keeps client-side events for behavioural data and adds server-side events for reliability, deduplicated on a shared event_id.