Conversion tracking for Magento 2
Magento breaks tracking in ways specific to how it caches and renders. Full-page cache serves a stored copy, so a data layer baked into the HTML arrives carrying the first visitor's values or none at all. Add multi-store views, several payment methods with genuinely different return paths, and a checkout that may be a decoupled frontend entirely, and the reliable answer is to source purchase from the order record rather than from anything the page rendered.
Free30 minutesNo obligation
Magento 2 tracking · what breaks
What goes wrong on Magento 2
- 01
Identical values across different orders
Full-page cache serving stored HTML with a baked-in data layer.
- 02
Some payment methods tracked, others not
Offsite gateways, iframes and redirects each return the customer differently.
- 03
Store views reporting inconsistently
Currency, locale and tag configuration can all differ per view and diverge over time.
- 04
Headless frontends where the confirmation isn't Magento
A PWA or decoupled storefront changes where the event can fire at all.
Magento 2 tracking · the fix
What changes — Magento 2 tracking
Purchase sourced from the order record
Immune to caching by construction.
Every payment return path covered
Tested individually, because they genuinely differ.
Consistent behaviour across store views
One configuration, verified per view.
Magento 2 tracking · architecture
What Magento 2 actually lets you do
Magento gives you complete control and a caching layer that will happily serve someone else's page to your customer.
- 1
Full-page cache
The central constraint. Cached blocks cannot carry per-order data; private content blocks can.
- 2
Observers and events
sales_order_place_after and similar fire once per order, server-side.
- 3
Multi-store views
Separate configuration per view, which drifts unless deliberately managed.
- 4
Payment method diversity
More varied than any hosted platform, and each return path needs its own test.
- 5
Headless and PWA
The confirmation page may not be Magento at all, which forces the server-side path.
Magento 2 tracking · diagnose
Where Magento 2 tracking breaks, in diagnostic order
Each check rules out a class of cause, so by the last one there is usually a single explanation standing.
- 01
Compare two different orders' data layer values
Identical means cache, and that's the whole diagnosis.
- 02
Segment the gap by payment method
One method dominating names the cause.
- 03
Segment by store view
Configuration drift is common and invisible in aggregate.
- 04
Check which blocks are cached
And which are private content.
- 05
Match a closed week on increment ID
Against each platform's purchase count.
Magento 2 tracking · prove
The QA evidence — Magento 2 tracking
Run on Magento 2 specifically, on a live conversion rather than in preview mode.
Source of truth
your Magento order records, matched on increment ID
- Two different orders confirmed carrying different values, not cached ones.
- Every payment method's return path tested with a real order.
- Each store view verified individually.
- Purchase count reconciled on increment ID for a closed week.
- A credit memo issued and confirmed reversing.
- Reconciled over a fully closed window, matched per record rather than on totals.
- Re-checked 30 days later, and after any platform update.
Magento 2 tracking · free audit
What we check in the free audit
- Compare two different orders' data layer values
- Segment the gap by payment method
- Segment by store view
- Check which blocks are cached
- Match a closed week on increment ID
Checked against
your Magento order records, matched on increment ID
Free30 minutesNo obligation
Magento 2 tracking · when not to buy
When you don't need this on Magento 2
Worth reading before you buy anything, from us or anyone.
- If two consecutive orders produce different, correct payloads and your counts reconcile, you don't have the Magento cache problem and this page isn't describing your site.
- A single store view with one payment method is a much simpler situation than this page assumes. Reconcile first.
- Moving purchase to the order observer is standard Magento development. If you have a Magento developer, they can do it.
- Headless Magento makes server-side more obviously necessary, not more expensive — the same observer is the source either way.
Magento 2 tracking · what we deliver
The event map on Magento 2
view_item, add_to_cart
Browser-side, from private content blocks rather than cached HTML.
begin_checkout
Browser-side.
Purchase
The order-placed observer, server-side, with the increment ID as the deduplication key.
Refund
Credit memo creation.
Store view
Carried on every event, because configuration and currency differ per view.
Written guarantee
95%+ tracking accuracy
Measured against your Magento order records, matched on increment ID. 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
Repairs and verifies the browser-side setup you already have, on a live conversion. Honest about its ceiling on this platform.
- Root cause fixed, not worked around
- Verified on a live conversion
- Reconciled against your own records
- Written handover
1st-party server-side
Recommended$800One-time fee · most popular
Money events sent from your own records through a first-party container on your subdomain, so the browser can no longer lose them.
- First-party server container on your own subdomain
- Money events from your records, not the browser
- Deduplicated on a shared event ID at every destination
- First-party cookies beyond Safari's 7-day cap
- 95%+ accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid channel server-side plus the offline loop, with monitoring so the next break surfaces in days.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop
- Refunds and cancellations corrected wherever each platform allows it
- Monitoring on every destination
FAQ
Magento 2 tracking questions, answered
Full-page cache is serving stored HTML containing the first visitor's values. Order-specific data has to come from a private block or, better, from the server.
Yes. Same caching and checkout architecture, same failure modes.
The confirmation page may not be Magento at all, which makes the server-side path the only reliable one. Same fix, more obviously necessary.
Yes. Magento payment returns differ more than on any other platform, and the untested one is where the missing conversions are.
Free · 30 min
Get Magento 2 tracking done properly
WhatsAppFree30 minutesNo obligation
