Why your GA4 and PrestaShop order counts don’t match (and how to fix 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 the gap is far larger. 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. Roughly 3 in 10 internet users run an ad blocker (GWI, 2025), and adoption is meaningfully higher in tech-savvy or younger segments.

Apple's Intelligent Tracking Prevention (ITP) adds another layer. On Safari and iOS, cookies set by client-side JavaScript are deleted after 7 days without a return visit — and capped at 24 hours when the visitor lands from a link decorated with tracking parameters (Apple's own WebKit policy). 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.

Safari carries a large share of mobile browsing — StatCounter tracks it month by month — so this is not an edge case; for plenty of stores it describes a big slice 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 — 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 transaction_id built from the order itself — never random — 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 entirely. When PrestaShop confirms an order, your back office reports the sale server-to-server — through a managed tracking server we run for you — on a road that doesn’t pass through the browser at all. The sale is recorded exactly once, and refunds follow with the matching transaction_id so GA4 reverses revenue correctly.

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 everyday events get their own fix. PrestaSignal records page views, product views and cart events through a small connector on your own website address, and serves the Google tag libraries from your domain too. Today's ad-blocker filter lists target Google's domains — with no third-party analytics domain on the page, there is nothing on those lists left to match. And for the ITP side of the gap, a proper server-set first-party cookie (kept for two years) preserves a returning Safari shopper's identity: Apple's 7-day deletion applies to cookies set by JavaScript, not to server-set cookies. 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 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.