What does server-side tracking NOT fix, even after a full and correct implementation?

What does server-side tracking leave broken after a correct build?

A correct server-side build leaves eight things broken, because consent, the ad platforms and your own data set each one, not the route an event travels. They are the other half of what moving to server-side tracking does recover.

Why do Google's consent-mode modelling thresholds bite mid-market brands?

Google's consent-mode modelling thresholds bite mid-market brands because they count daily traffic and consent mix, which a server hop cannot change. Google Analytics 4 (GA4) models the behaviour of shoppers who decline analytics cookies only when a property clears two bars (Google Analytics Help, October 2026). It must collect "at least 1,000 events per day with analytics_storage='denied' for at least 7 days". It must also have "at least 1,000 daily users sending events with analytics_storage='granted' for at least 7 of the previous 28 days". Google tags must load "in all cases, not only if the user consents." Even past both bars, Google warns that "it's possible that even the additional data won't be sufficient for Analytics to train the model."

Google Ads sets its own, separate bar for modelled conversions: "a daily ad click threshold of 700 ad clicks over a 7 day period, per country and domain grouping" (Google Ads Help, October 2026). So a brand doing meaningful revenue on modest traffic can miss both bars for good, and server-side tracking moves neither. What that means for a $10M brand with a high order value works through the arithmetic.

How does the 48-hour deduplication window inflate conversions?

The 48-hour window inflates conversions whenever a browser event and its server copy arrive more than two days apart, because Meta and TikTok only deduplicate inside it. Meta says events "are only deduplicated if they are received within 48 hours of when we receive the first event with a given event_id" (Meta for Developers, October 2026). TikTok merges or deduplicates matching Pixel and Events API (application programming interface) copies "after 5 minutes and within a 48-hour window from the first event" (TikTok Business Help Center, October 2026).

So any architecture that can send the server copy late double counts: a delayed batch job, a retried queue, an offline conversion upload joined days later. Meta's fallback method matches on its browser cookie ID (fbp) or your own customer ID (external_id). That method adds a second trap: "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."

That means an implementation error here does not produce missing data, which is visible. It produces inflated data, which looks like success.

What should you settle about each limit before the build starts?

Settle the limits server-side tracking leaves before the build starts, because each has a fix outside the route an event travels and needs an owner:

• Consent: measure the decline rate and treat it as a planning input, 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 all of them to Shopify order data.
• Deduplication: send event_id from both sides, verify it in each platform's events manager, and re-verify after every theme or app change.
• Incrementality: run a holdout. It is the only method on this list that answers whether the spend caused the revenue, and a holdout design that separates recovered conversions from lift shows how.