Server-side tracking & attribution
We rebuild your conversion data so the ad platforms optimise against what actually happened, and so the numbers you make decisions on can be trusted.
What breaks
Browser blocking eats a large share of events
Tracking prevention, ad blockers and privacy defaults mean a substantial portion of browser-fired conversion events never arrive. The platform does not report a gap — it simply optimises against the subset that survived, which skews toward a particular kind of user.
The platforms disagree and everyone picks a favourite
Meta, Google and your analytics each claim credit under different attribution models and windows. Summing them produces more revenue than the store actually took, so budget decisions end up being made from whichever dashboard is most flattering.
Duplicate events inflate everything quietly
When browser and server events are both sent without proper deduplication, conversions are double-counted. Reported return looks strong, spend increases on that basis, and the real number is discovered much later.
Consent and tracking are wired together badly
Either consent is ignored, which is a regulatory exposure in the UK and EU, or it is implemented so bluntly that legitimate first-party measurement disappears along with everything else.
Hover, tap or tab a step to see what is lost there.
Illustrative of the mechanism, not measured from a client account. Real loss varies substantially by market, device mix and consent implementation — which is exactly why it gets measured per store rather than assumed.
How we find it
Event inventory and reconciliation
Every event mapped, then reported conversions reconciled against actual orders in the store. The size of the gap is usually the finding that changes the conversation.
Deduplication check
We verify whether browser and server events are being matched correctly, which is where inflated numbers almost always originate.
Match quality review
How much identity information reaches each platform, since match rate directly determines how well optimisation can work.
Consent flow audit
What actually fires before and after consent, and whether the implementation is both lawful and functional rather than one at the expense of the other.
How we fix it
Server-side event pipeline
Conversions sent from the server rather than relying on the browser, so blocking no longer silently removes a slice of your data.
Proper deduplication
Shared event identifiers so browser and server events resolve to one conversion. This usually makes reported numbers go down, and that is the point — the smaller number is the true one.
Improve match quality
The identity signals each platform accepts, passed correctly and lawfully, so optimisation has something to work with.
Reconcile to one source of truth
A single view that ties platform-reported performance to actual orders, so decisions stop depending on which dashboard was opened first.
The operating rhythm
What actually happens, and how often. Published because “ongoing optimisation” is what everyone says and almost nobody defines.
- Week one
- Event inventory and reconciliation against real orders, so the size of the gap is a measured number both sides agree on before anything changes.
- Weeks two to three
- Server-side pipeline stood up with shared event identifiers, then deduplication verified — usually the point at which reported numbers go DOWN and become correct.
- Ongoing
- Monthly reconciliation so drift is caught early. Tracking does not stay fixed on its own; a theme update or a new app breaks it silently.
Scope
What is included
- Full event inventory reconciled against actual store orders
- Server-side conversion pipeline with deduplication and identity matching
- Consent implementation that is both lawful and compatible with measurement
- A single reconciled view tying platform-reported performance to real orders
- Monthly re-reconciliation to catch silent breakage
What we need from you
- Delegated access to ad platforms, analytics and store admin
- Developer access, or our access to a staging theme, for pipeline work
- Order data — or a report of it — so reconciliation is against reality
- A decision on your consent posture, which is a legal question for you rather than a technical one for us
What changes after
- The platforms optimise against a complete picture rather than a filtered sample.
- Reported conversions reconcile with real orders instead of exceeding them.
- Attribution disagreements resolve against one agreed source.
- Consent is handled in a way that is both lawful and compatible with measurement.
These describe the mechanism of improvement, not a guaranteed outcome. Results depend on your product, margin and market — the written guarantees are in section 7 of the Terms.
Questions
Will my reported ROAS go down?
Very possibly, and that is usually a sign the work is doing its job. Removing duplicated conversions makes the reported number smaller and correct at the same time. The revenue in your bank does not change; what changes is that you can now trust the number you are steering by, which almost always improves the decisions made from it.
Is server-side tracking legal under GDPR?
Server-side collection is a transport mechanism, not a way around consent, and we do not treat it as one. Where consent is required it is still required, and we implement it that way. What server-side does fix is the technical loss of events you are lawfully permitted to collect, which is a different problem from consent and the one most stores actually have.
How will I know it worked?
By reconciliation, not by a dashboard claim. We compare conversions reported by each platform against actual orders in your store before and after, and the measure of success is that the gap closes. That number is checked in front of you rather than asserted, and it is the same figure the performance guarantee is judged on.
Go deeper on the mechanism
Find out whether this is your bottleneck
The free diagnostic scans your storefront and tells you where the problem actually is — which is often not where it feels like it is.