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 ones that map to your funnel. The core list runs from discovery through to post-purchase: page_view, view_item_list, view_item, add_to_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, and post-sale signals like refund, plus account events such as sign_up.

Together these roughly thirteen 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 mapping to PrestaShop hooks.

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. A 30-50% undercount is common, and it 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 deterministic transaction_id derived from the order reference prevents the duplicates, collapsing reloads and retries into a single order. But it cannot recover the events that never fired — only server-side delivery can do that.

Do it server-side

The fix for the leakage is to send your ecommerce events — especially purchase — from the server, not the browser. A self-hosted sGTM container receives events from PrestaShop and forwards them to GA4 with the right value, currency, and a stable transaction_id, immune to whatever the browser does or fails to do.

The best practice is hybrid: client-side events for behaviour, server-side events as the reliable backstop, both sharing an event_id so GA4 deduplicates them. That gives you full funnel richness and trustworthy order counts at once, rather than forcing a choice between the two.

This is also where PII handling belongs. Routing data through a server you control lets you hash email and phone before they reach Google, which keeps your setup cleaner from a privacy standpoint and gives you a single place to decide what leaves your store. Read how it works for the PrestaShop specifics.

None of this means ripping out what you have. You keep the same GA4 property, the same measurement_id, and your existing client-side tags; server-side delivery simply sits alongside them as the reliable layer that catches what the browser drops.

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 deterministic transaction_id. The measurement_id matches your reporting property and nothing else. And the critical events are sent server-side, deduplicated against the client-side version on a shared event_id.

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.