Is your PrestaShop tracking actually working? A 5-minute self-check

Most broken tracking does not announce itself. There is no error message, no red banner — just numbers that are quietly wrong, leading to decisions that are quietly bad. The only way to know whether your PrestaShop tracking is healthy is to check it deliberately.

The good news is that a meaningful health check takes about five minutes and needs no special tools beyond your GA4 dashboard and your PrestaShop back office. Run the five checks below. If you pass them all, your setup is probably in good shape. If you fail even one, you are likely losing conversions and should dig deeper.

Check 1: Compare GA4 purchases to real orders

This is the single most revealing test. Pick a clean date range — last month is ideal — and pull two numbers: the count of purchase events in GA4, and the count of valid orders in your PrestaShop back office over the same dates.

Now compare. A healthy setup lands within a few percent, with small, explainable differences (cancelled orders, test orders, fraud filtered out). If GA4 is 20%, 30%, or more below your back office, you have a structural undercount — the classic symptom of client-side-only tracking losing events to ad-blockers, ITP, and closed tabs.

Do the same with revenue, not just order count. If GA4 revenue is well below the money you actually took, the gap is real and it is costing you accurate bidding and reporting. We cover the causes in depth under server-side vs client-side.

Check 2: Look at your iOS and Safari share

Your exposure to tracking loss depends heavily on your audience. In GA4, look at the breakdown of sessions by operating system and browser, focusing on iOS and Safari.

The larger your iOS and Safari share, the more Apple's Intelligent Tracking Prevention and App Tracking Transparency are eroding your client-side data. A store where most mobile traffic is iOS is far more exposed than one dominated by Android, because ITP aggressively caps client-side cookies on Apple devices.

This check does not produce a pass/fail on its own, but it tells you how much the other checks matter. A high iOS share means even a small visible gap probably hides a larger real one, and it raises the urgency of moving key events server-side.

Check 3: Hunt for unassigned and direct traffic

Open your traffic acquisition report and look at how much traffic is classified as "unassigned", "(direct)", or "(not set)". A small amount is normal. A large or growing share is a warning sign.

When tracking cookies expire early under ITP, returning visitors who originally arrived from an ad or a campaign come back looking like brand-new, source-less sessions. That attribution does not vanish quietly — it piles up in the unassigned and direct buckets, inflating them.

If a suspiciously large slice of your conversions is credited to direct or unassigned, your channel reporting is unreliable and you are almost certainly under-crediting paid campaigns. That misattribution leads directly to cutting budgets that were actually working.

Check 4: Test your key events live

Numbers in aggregate can hide gaps; a live test confirms the plumbing. Open GA4's real-time or DebugView, then walk through your own store as a customer: view a product, add to cart, begin checkout, and complete a test purchase.

Watch for each event to appear: page_view, view_item, add-to-cart, begin_checkout, and finally purchase. Confirm the purchase carries the right value — the tax-included total you actually paid — and a sensible transaction_id.

Now repeat the purchase check with an ad-blocker enabled, or on an iPhone in Safari. If the event vanishes under those conditions, you have just reproduced, with your own eyes, the exact loss happening across a large share of your real traffic. That is the most persuasive evidence there is.

Check 5: Check for duplicates and wrong values

Loss is one failure mode; inflation is the other. While testing, reload the confirmation page or click the back button and forward again. If a second purchase appears in real-time, you have a duplication problem — usually a random rather than deterministic transaction_id.

Also sanity-check the revenue figures. If GA4 shows tax-excluded subtotals instead of the amount customers paid, your ROAS and value-based bidding are working from understated numbers. Both duplicates and wrong values corrupt the data that Smart Bidding learns from.

A setup that double-counts can actually look healthier than reality on the order count while being just as broken. The fix is a deterministic identity from the order reference, the same principle we apply across GA4 tracking and Meta CAPI.

When to get a proper teardown

If you passed all five checks, well done — your tracking is in better shape than most. Re-run the comparison every quarter and after any theme, checkout, or module change, since updates routinely break tracking silently.

If you failed one or more, the checks have told you where the problem lives but not always how deep it goes. A 30% GA4 gap, a high iOS share, bloated unassigned traffic, or events that vanish under an ad-blocker all point to the same answer: your most important conversions are not reliably reaching the systems that depend on them.

That is the point at which a structured audit pays for itself. Book a teardown and we will measure your real gap against your PrestaShop orders, identify every leak, and show what recovering it is worth. You can also read about the module that closes it.