Get your PrestaShop tracking to 95%+ accuracy guaranteed in writing.
Most PrestaShop stores still rely on the legacy Meta Pixel module and a basic GA tag. There's no CAPI, no dedup, no advanced matching, and iOS users vanish on Safari. Your ad spend is propping up reports that don't match reality. We ship a server-side CAPI gateway and a proper PrestaShop module that hooks into hookActionValidateOrder so events fire reliably.
Free30 minutesNo obligation
PrestaShop · what breaks
What's broken on PrestaShop today
- 01
Meta Pixel module is the only thing firing
iOS, ad blockers and ITP eat much of those events. Your Events Manager shows half the truth.
- 02
Multi-shop bleeds events across stores
Single GTM container shared between shops causes events from Shop A to fire in Shop B's ad accounts.
- 03
Combinations break content_id
Product combinations (size/color) often fire with the wrong reference, breaking catalog matching.
- 04
Module conflicts on every upgrade
PrestaShop module ecosystem is fragile. Tracking modules break with every minor version bump.
PrestaShop · the fix
Outcomes — PrestaShop
Server-side CAPI live
Meta + Google + TikTok routed via your subdomain.
Multi-shop safe routing
Each shop gets its own ad-account routing, no bleed.
Combinations handled
Reference-aware events keep catalog match high.
Upgrade-proof module
Composer-style module that survives 1.7.x → 8.x.
PrestaShop · architecture
How a PrestaShop order should reach the ad platforms
PrestaShop gives you full server access and a hook system, which makes correct tracking straightforward — and makes duplicate modules easy to accumulate.
- 1
Click identifiers captured at first touch
Click IDs are captured at landing and persisted in the customer session, then written to the order, so attribution survives multi-shop URL structures and language redirects.
- 2
The browser sends the fast, fragile copy
Theme templates fire the browsing and cart events. The order confirmation controller is the browser-side purchase hook, and it can be reached more than once.
- 3
The order itself is the source of truth
The actionValidateOrder hook fires server-side against a real order object with a confirmed payment state. That is the truth, not the confirmation page.
- 4
A server container sends the authoritative event
A small module posts the validated order to a GTM server container on your own subdomain, keyed on the PrestaShop order reference.
- 5
Customer identity raises match quality
The order carries customer email, phone and the full invoice address. Hashed server-side, these deliver the match quality a theme-only setup cannot.
PrestaShop · events
The event set we build on PrestaShop, and where each one comes from
PrestaShop's multi-shop and multi-language structure means the same event can fire from several URL shapes, which is worth accounting for in triggers.
| Event | Fires when, on PrestaShop | Key parameters | Sent from |
|---|---|---|---|
| view_item | The product controller renders | item_id, value, currency, event_id | Browser + server, deduped |
| add_to_cart | The cart controller confirms the add, including AJAX adds | item_id, quantity, value, currency, event_id | Browser + server, deduped |
| begin_checkout | The order controller loads with a non-empty cart | value, currency, num_items, event_id | Browser + server, deduped |
| purchase | actionValidateOrder fires with a paid order state | order_id, value, currency, items[], hashed email/phone/name/address, event_id | Server authoritative |
| refund | A credit slip is generated | order_id, value, currency | Server only |
PrestaShop · normal or broken
PrestaShop faults worth separating from normal behavior
Almost every PrestaShop tracking problem is either a duplicate module or a confirmation-page trigger.
Normal, not a fault
Order states changing after the conversion fired
Payment accepted, processing and shipped are separate states. Firing on validation and seeing later state changes is normal.
Multi-shop views reporting separately
Each shop is its own context. Separate reporting is correct; merged reporting is what causes trouble.
Ad platforms report more conversions than you have orders
Meta credits a 7-day click and 1-day view; Google credits on click date. Two platforms can each claim the same sale. Compare each one to your order records separately and never add them together.
Recent days always look worse than they finish
Conversions are credited back to the date of the click, so yesterday's return on ad spend is understated and will keep improving for several days. This is attribution working, not data arriving late.
Actually broken
Two tracking modules installed and both active
PrestaShop's module marketplace makes this easy. Both fire, conversions double.
Purchase fired from the confirmation controller with no guard
The page is revisitable, so refreshes multiply the conversion.
Prices reported with tax handling that differs from the order total
PrestaShop's tax-included and tax-excluded price fields are both available and easy to mix up.
PrestaShop · prove
How we prove the PrestaShop build is correct
The tag firing proves the tag fires. These prove the numbers are right.
Source of truth
PrestaShop order records
- The purchase confirmed firing from actionValidateOrder with a paid state, once per order.
- The active module list audited so exactly one tracking path remains.
- Tax treatment verified to match the order total across every destination.
- Purchase count within a few percent of prestashop order records for a fully closed week, matched on order ID rather than on totals.
- No order ID appearing twice in any platform's event log.
- Deduplication confirmed at every destination that supports it.
- Test and staff orders excluded, with the exclusion confirmed active rather than merely configured.
- The same reconciliation repeated 30 days later, because a setup that works once and then drifts is the harder failure to catch.
PrestaShop · free audit
What we check in the free audit
- Meta Pixel module is the only thing firing
- Multi-shop bleeds events across stores
- Combinations break content_id
- Module conflicts on every upgrade
Checked against
PrestaShop order records
Free30 minutesNo obligation
PrestaShop · when not to buy
When a PrestaShop rebuild is not what you need
We would rather say this now than three weeks into an engagement.
- You run one shop, low volume, and a single correctly configured module. That may genuinely be enough.
- You are mid-upgrade between PrestaShop major versions. Rebuild after.
- You have no developer able to deploy a module safely.
PrestaShop · what we deliver
Deliverables — PrestaShop
PrestaShop tracking module
Source + license
Server-side GTM container
Subdomain or Stape
Meta CAPI + Google EC + TikTok
Dedup-clean
GA4 e-com schema
All events typed
QA + Notion runbook
Plus 30-day support
Written guarantee
95%+ tracking accuracy
Measured against PrestaShop order records. Miss it and we keep working at no cost.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
Foundation pixel install for your PrestaShop store. Honest disclosure: this is a starting point only. If you spend $1K+/month on paid media you should be on the 1st-party server-side tier — rather than quote you a recovery percentage, we'll show you how to measure your own gap: compare what the platforms reported against the orders in your backend for the same week. That ratio is the entire argument, and it's yours to check — see trackingconsulting.com/measurement-accuracy-methodology.
- One-time fee · zero monthly · zero SaaS lock-in
- PrestaShop dataLayer (clean spec)
- GA4 e-commerce events
- Meta Pixel · Google Ads tag
- TikTok Pixel · Microsoft UET
- Consent Mode v2 banner integration
- QA test orders + 7-day support
- No CAPI · no iOS recovery
1st-party server-side
Recommended$800One-time fee · most popular
The done-for-you package every PrestaShop store running paid ads should start with. We build the entire 1st-party server-side stack on your subdomain — Meta, Google, TikTok, Microsoft, LinkedIn all fed from the server. Recovers the conversions iOS, Safari ITP, ad blockers and cookie deprecation hide today. You don't lift a finger. Built in 2–4 days · accurate data in 7 days.
- One-time fee · save vs SaaS subscriptions over 5 years
- Fully recovered + built in 2–4 days · accurate data in 7 days
- Everything in browser-side starter
- 1st-party server-side GTM (your subdomain)
- Meta CAPI · full advanced matching · 8+ EMQ
- Google Enhanced Conversions (Web + Leads)
- TikTok Events API · Microsoft UET server
- Deterministic browser ↔ server deduplication
- Live EMQ verification + screenshots
- Notion runbook + 30-day support · zero recurring
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid-media channel running 1st-party server-side, end-to-end. For PrestaShop brands spending $30K+/month who can no longer afford attribution leaks. Pay once. Own everything. Includes Pinterest + Snap + Reddit + LinkedIn CAPI, Klaviyo identity stitching, BigQuery + Looker Studio.
- One-time fee · save 6-figure SaaS subscriptions over 5 years
- Everything in 1st-party server-side tier
- Pinterest · Snapchat · Reddit · LinkedIn · X CAPIs
- Klaviyo identity stitching (if used)
- BigQuery export (server logs + GA4)
- Looker Studio attribution dashboard (branded)
- Multi-region / multi-currency / EU residency
- GDPR-audit-ready Consent Mode v2 wiring
- 60-day support · optional retainer · no lock-in
FAQ
PrestaShop questions, answered
Yes. The module supports both branches and we test on the current LTS line.
Yes — per-shop tag routing is a first-class feature.
More on PrestaShop
- GuideServer-Side Tracking Explained: What It Is, How It Works, and Who Actually Needs It (2026)
- GuideServer-Side Tracking for Shopify: The 2026 Setup That Actually Works
- Free toolFree PrestaShop audit
- Free toolMeta EMQ predictor
- PrestaShop server-sideServer-side tracking for PrestaShop
- PrestaShop + GoogleGoogle Ads and GA4 tracking for PrestaShop
- PrestaShop + Meta CAPIMeta Conversions API setup for PrestaShop
