How to set up GA4 ecommerce tracking on PrestaShop (the right way)

Google Analytics 4 can be a genuinely powerful tool for a PrestaShop store — or a source of numbers you secretly do not trust. The difference is almost always in the setup. Get the ecommerce events, the revenue, and the delivery method right, and GA4 becomes a reliable picture of your funnel. Get them wrong, and you make decisions on data that quietly disagrees with your back office.

This is the practical version: what to track, how, and the mistakes that catch nearly everyone. It is written for store owners, not analysts, so you can tell whether your setup is actually doing its job.

The ecommerce events that matter

GA4 has a defined set of recommended ecommerce events, and a proper PrestaShop setup fires the full PrestaShop funnel: the journey from discovery to post-purchase — browsing and product pages, every basket move, each checkout step, the sale itself, and the post-sale and account signals that follow. The stage-by-stage grid on our module page lists every event by name. GA4 also records automatic events — session_start, first_visit, user_engagement — on its own; a healthy setup preserves them rather than fighting them, so your session and new-user counts stay right.

Together these events let GA4 reconstruct the whole journey: how many people saw a category, viewed a product, started checkout, and finished. Gaps in the middle break funnel reports and make it impossible to see where shoppers drop off.

Each event also needs the right parameters — item IDs, names, prices, quantities, and a currency — or GA4's ecommerce reports stay empty even though events are firing. The most common failure is firing purchase with no item array or no value, which makes revenue reporting useless. See our GA4 tracking page for the full picture.

measurement_id: get the plumbing right

Every GA4 data stream has a measurement_id (the G-XXXXXXX value). It tells Google which property the events belong to. Sounds trivial, but mismatched or missing measurement IDs are a surprisingly common reason data lands nowhere — or in the wrong property entirely.

Use one measurement_id consistently across client-side and server-side, and confirm it matches the property you actually report from. A classic mistake is having an old property's ID hard-coded in a theme while the new property sits empty, leaving you staring at zeros and assuming tracking is broken.

If you run staging and production stores, keep their streams separate so test orders never pollute live data. Nothing erodes trust in analytics faster than discovering your QA purchases inflated last quarter's revenue.

Send tax-included revenue

PrestaShop can report revenue in several ways, and the wrong choice silently understates your numbers. GA4 should receive the tax-included total the customer actually paid — total_paid_tax_incl — not the tax-excluded subtotal.

If your revenue in GA4 looks consistently lower than your back office by a suspiciously round percentage, a tax-excluded value is almost always the culprit. The gap matches your VAT rate.

Fixing it brings GA4 revenue back in line with the money you actually banked, which matters the moment you start calculating ROAS or feeding conversion values into Smart Bidding. Bidding on understated values means underbidding on your best customers.

Why most setups quietly lose conversions

Even a perfectly configured client-side GA4 setup loses orders. The purchase event fires in the browser, so ad-blockers, Apple's ITP, slow mobile connections, and shoppers closing the confirmation tab all eat conversions before they reach Google. The undercount is heaviest on mobile and privacy-conscious audiences.

There is also the duplicate problem in the other direction: if purchase can fire twice — say on a page reload or back-button click — with a random ID each time, GA4 counts two sales for one order. Undercounting and overcounting stacked together make the true figure nearly impossible to reason about.

A transaction_id built from the order itself prevents the duplicates, collapsing reloads and retries into a single order. But it cannot recover the events that never fired — for that, the delivery itself has to change.

Fix the delivery, not just the tags

The most important change is to stop asking the browser to report your sales at all. When PrestaShop confirms an order, PrestaSignal reports the sale from your back office to a managed tracking server we run for you, which forwards it to GA4 with the true paid amount, the currency, and a transaction_id built from the order itself. The sale is recorded exactly once — a reload can never double-count — and refunds follow with the matching transaction_id so GA4 reverses revenue correctly.

The everyday events stay in the browser, where behavioural data belongs — but they stop travelling to Google's domains. The module places a small connector on your own website address, and page views, product views and cart events are recorded through it; even the Google tag libraries load from your domain. Today's ad-blocker filter lists target googletagmanager.com and google-analytics.com, so with everything served from your own address there is no third-party analytics domain on the page for them to match.

This is one integrated design, not a mode you pick: browser events on one road, your sales on a browser-free second road, both sharing an event_id so GA4 deduplicates them. Personal data is handled where it should be, too — the module normalises and SHA-256 hashes email, phone and name inside your store before anything leaves it. Read how it works for the PrestaShop specifics.

None of this means starting over. You keep the same GA4 property, the same measurement_id, and all your history; what changes is the road your events travel, not where they land.

A short checklist

Before you call your GA4 setup done, confirm a few things. Every funnel event fires with correct item parameters and currency. The purchase event carries tax-included value and a transaction_id built from the order itself. The measurement_id matches your reporting property and nothing else. And the sale is reported from your back office rather than the browser, sharing one event_id with the browser side so nothing double-counts.

Work through that list and you will catch the issues that silently undermine most PrestaShop analytics. Skip it, and you risk building strategy on numbers that look precise but are quietly wrong.

If that feels like a lot to verify by hand, it is exactly what PrestaSignal configures out of the box. Book a teardown and we will audit your current GA4 events against your real orders, line by line.