What does server-side tracking NOT fix, even after a full and correct implementation?
Server-side tracking does not fix consent, attribution windows, or the platform's own model. Google Ads no longer supports first click, linear, time decay or position-based attribution; data-driven is the default (per Google, September 2026). Deduplication windows stay fixed at 48 hours on both Meta and TikTok, and a declined consent signal still suppresses the event.
The list, with the documented reason for each
| Still broken | Why a server hop cannot help | Source |
|---|---|---|
| Declined consent | Consent mode tags "do not store cookies" and send "cookieless pings" when denied; the event is suppressed by design, not by transport | Google, Sep 2026 |
| The attribution model | Google Ads has retired first click, linear, time decay and position-based models; data-driven is the default for most conversion actions. You do not own the model | Google, Sep 2026 |
| Deduplication windows | Meta deduplicates only "within 48 hours of when we receive the first event with a given event_id"; TikTok deduplicates identical event and event_id pairs "after 5 minutes and within a 48-hour window" | Meta and TikTok, Sep 2026 |
| Cross-device and logged-out journeys | The identity you send is the identity you have. Server-side does not create one | |
| Walled-garden self-reporting | Each platform reports conversions it believes it caused, under its own window. Feeding all of them the same events does not make their totals reconcilable, or add up to your Shopify revenue | |
| View-through measurement | Impression-based credit stays entirely inside the platform | |
| Modelling gaps below threshold | GA4 behavioural modelling needs at least 1,000 events per day with analytics_storage='denied' for 7 days and at least 1,000 daily users with it granted, for 7 of the previous 28 days | Google, Sep 2026 |
| A wrong event | A duplicated, mis-valued or mis-timed purchase event is wrong in both transports |
The one most likely to bite a mid-market Shopify brand
The modelling thresholds. Google states them precisely: the property must collect "at least 1,000 events per day with analytics_storage='denied' for at least 7 days" and have "at least 1,000 daily users sending events with analytics_storage='granted' for at least 7 of the previous 28 days" (per Google, September 2026). Google adds that even meeting the threshold may not be enough: "it's possible that even the additional data won't be sufficient for Analytics to train the model."
A brand doing meaningful revenue on modest traffic can miss that bar permanently. Server-side tracking does not move it, because the bar is about volume and consent mix, not transport.
The one the industry keeps quiet about
Deduplication is a 48-hour promise on both Meta and TikTok. Any architecture where the browser event and the server event can be more than two days apart, a delayed batch job, a retried queue, an offline conversion upload joined later, will double count. Meta also warns that with the fbp method "server events will not be discarded if a browser event has not been received in the past 48 hours, even if an identical browser event arrives after the server event" (per Meta, September 2026).
That means an implementation error here does not produce missing data, which is visible. It produces inflated data, which looks like success.
What to do about each, since the answer is not the transport layer
- Consent: measure the decline rate and treat it as an input to planning, not a defect. Report consented conversions and total orders side by side so nobody mistakes one for the other.
- Attribution model: stop comparing platforms to each other. Compare each platform to itself over time, and compare all of them to Shopify order data.
- Deduplication: send
event_idfrom both sides, verify in the platform's event manager, and re-verify after every theme or app change. - Incrementality: run a holdout. It is the only method on this page that answers whether the spend caused the revenue.
The Deploi point of view
Our own position, from building on Shopify. Separate from the facts above.
- Our take: Write the not-fixed list into the project charter before the build starts, and have the channel owners sign it. Nearly every disappointment we see with a server-side project is a scope expectation that was never stated, not an implementation defect. The build does what it says. The brief said more than the build could.
- What we’ve seen: Across seven analytics and dataLayer instrumentation engagements, the item on this list that surprises teams most is deduplication. A 48-hour window sounds generous until someone adds a nightly retry for failed server events, and the purchase count quietly rises.
- Times we’ve shipped this: 7 builds delivered.
- Where we disagree: Vendors frame server-side tracking as recovering lost conversions, which invites the reader to imagine revenue appearing. What it recovers is reporting fidelity for events that already happened. Those are different claims, and only one of them survives a finance review.
- What this page adds: the specific documented ceilings, the 48-hour deduplication windows on both Meta and TikTok, Google's retirement of the rule-based attribution models, and GA4's 1,000-event and 1,000-user modelling thresholds, which together explain why a correct implementation still leaves a gap.
Reviewed by Martin Dejnicki, Director of SEO & AI Search. Facts verified 2026-09-14.
Where we worked this out
Our decision records