Repairing purchase tracking on Magento and Adobe Commerce
Magento breaks tracking in ways that are specific to how it caches and renders. Full-page cache serves a stored copy of the page, so a data layer rendered into the HTML gets served to every visitor with the first visitor's values — or with none at all. Add multi-store views, several payment methods with different return paths, and a checkout that may be a separate frontend, and the reliable answer is to source the purchase from the order record rather than from anything the page rendered.
Free30 minutesNo obligation
Magento / Adobe Commerce · what breaks
The situation, as it usually presents — Magento / Adobe Commerce
- 01
Purchase data missing or identical across orders
The cache signature.
- 02
Some payment methods tracked and others not
Different return paths.
- 03
Multi-store views reporting inconsistently
Different configuration per view.
Magento / Adobe Commerce · the fix
What changes — Magento / Adobe Commerce
Purchase sourced from the order record
Immune to caching.
Every payment method's return path covered
Tested individually.
Consistent behaviour across store views
One configuration, verified per view.
Magento / Adobe Commerce · architecture
Why this pattern keeps recurring — Magento / Adobe Commerce
Magento's caching and checkout architecture create failure modes that don't appear on hosted platforms.
- 1
Full-page cache serves someone else's page
A data layer baked into cached HTML carries the first visitor's values, or none. Both are silently wrong.
- 2
Payment methods return differently
Offsite gateways, iframes and redirects each land the customer somewhere different, and each needs testing separately.
- 3
Multi-store views multiply configuration
Currency, locale and tag configuration can all differ per view, and usually diverge over time.
- 4
Headless splits the checkout entirely
A PWA or decoupled frontend means the confirmation page may not be Magento at all.
Magento / Adobe Commerce · diagnose
How the root cause gets found — Magento / Adobe Commerce
In this order. Each step rules out a class of cause, so the last one usually has a single explanation standing.
- 01
Compare two orders' data layer values
Identical means cache.
- 02
Segment the gap by payment method
One method dominating names the cause.
- 03
Segment by store view
Configuration drift is common.
- 04
Check which blocks are cached
And which are private.
- 05
Match a week on increment ID
Against platform purchases.
Magento / Adobe Commerce · prove
How the work is proven — Magento / Adobe Commerce
Against the client's own records, not a dashboard turning green.
Source of truth
Magento order records, matched on increment ID
- Purchase confirmed arriving with correct per-order values, not cached ones.
- Every payment method's return path tested with a real order.
- Each store view verified individually.
- Order count reconciled on increment ID for a closed week.
- Reconciled over a fully closed window, matched on ID rather than on totals.
- Payload evidence captured from real transactions and handed over.
- The same reconciliation repeated 30 days later.
Magento / Adobe Commerce · free audit
What we check in the free audit
- Compare two orders' data layer values
- Segment the gap by payment method
- Segment by store view
- Check which blocks are cached
- Match a week on increment ID
Checked against
Magento order records, matched on increment ID
Free30 minutesNo obligation
Magento / Adobe Commerce · when not to buy
Why there are no client numbers on this page — Magento / Adobe Commerce
Most agency case studies lead with a percentage. This one doesn't, and the reason is worth stating.
- We don't publish client results we can't substantiate. An audit of this site in August 2026 found named testimonials and before-and-after figures that had never been measured — all of it was removed, and nothing has replaced it that isn't checkable.
- The results that do exist belong to clients under agreement. Publishing anonymised numbers without their sign-off would be the same problem in a thinner disguise.
- What we will commit to in writing is 95%+ conversion accuracy and 8+ Meta Event Match Quality, reconciled against your own order records. That is checkable by you, which a case study percentage never is.
- For proof from actual clients, the video testimonials on the site are real people describing their own rebuild. That is the strongest evidence we have, and it isn't a number we wrote.
Magento / Adobe Commerce · what we deliver
What the work involves — Magento / Adobe Commerce
Cache interaction diagnosed
Which blocks are cached and which are private.
Purchase moved to the order-placed observer
Server-side, from the order.
Each payment method's return tested
They differ more than on any other platform.
Store views verified individually
Currency and configuration vary.
Written guarantee
95%+ tracking accuracy
Measured against 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 the fault in your existing browser-side setup and verifies it on a live transaction. Honest about its ceiling: it fixes this instance, not the class.
- Root cause fixed, not worked around
- Verified on a live transaction
- Reconciled against your own records
- Written handover
1st-party server-side
Recommended$800One-time fee · most popular
Removes the class of failure rather than this instance. Money events sent from your order records through a first-party container on your own subdomain, so the browser can no longer lose them.
- First-party server container on your own subdomain
- Money events from your order 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, for advertisers whose spend makes an attribution leak more expensive than the build.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop
- Refunds reversed at every destination
- Monitoring so the next break surfaces in days
FAQ
Magento / Adobe Commerce 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. The caching and checkout architecture are the same, and so are the 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
Fix Magento purchase tracking at the source
WhatsAppFree30 minutesNo obligation
