Server-Side Tracking, Explained Honestly

In client-side tracking the browser talks directly to every analytics and advertising vendor you use. In server-side tracking the browser talks to one endpoint on your own domain, and your server decides what gets forwarded where. The data path is the only thing that changes; the collection itself is the same act, with the same legal weight.

• One request from the browser instead of a dozen third-party scripts, so the page carries less weight
• Your server decides what each vendor receives, so you can forward an order value to one and nothing to another
• Cookies set by your own server are first-party, which changes how long they survive
• You can enrich events with data the browser never had: order margin, refund status, lead quality from your CRM
• You can also fix or drop bad data before it reaches a vendor, instead of after it has polluted a report

There are real measurement failures behind the hype, and they are worth naming precisely rather than gesturing at 'better data'.

• Short cookie lifetimes: browser-set cookies from third-party scripts are capped aggressively, so a returning visitor looks like a new one and the attribution window is shorter than your sales cycle
• Script blocking: a meaningful share of visitors block third-party analytics entirely, and those sessions are simply missing from your reports
• Page weight: every vendor tag is another script the browser must fetch and run, which is a Core Web Vitals cost you pay on every page view
• Data you only have server-side: refunds, cancellations, offline conversions and lead quality never existed in the browser to begin with
• Vendor sprawl: when every tag talks directly to its vendor, nobody can answer what data left the site or where it went

This is the part most vendor pages leave out, and it is the part that gets companies into trouble. Moving the data path server-side changes where collection happens, not whether you are allowed to collect.

• It is not a consent workaround. If a visitor refuses tracking, you still may not track them; the obligation follows the data, not the transport
• It does not make personal data anonymous. Forwarding an email or an IP from your server is still processing personal data
• It is not a way to hide data collection from users. If your privacy policy would have to change and you would rather it did not, that is a signal to stop
• It does not fix bad measurement design. Events that were wrong client-side arrive wrong server-side, just more reliably
• It does not remove your responsibility for what vendors do with what you forward

Consent Mode is the mechanism Google tags use to be told what a visitor agreed to. Version 2 added two parameters (ad_user_data and ad_personalization) alongside the original ad_storage and analytics_storage, and since March 2024 Google has required it for EEA traffic where advertisers use audience and remarketing features. It is worth understanding precisely, because it is the piece people most often mistake for permission.

• Four signals, not one: storage for analytics, storage for ads, whether ad data may be sent, and whether it may be personalised; a visitor can allow some and refuse others
• In basic mode the tags do not load at all until consent is given, so nothing is sent from a refusing visitor
• In advanced mode tags load and send cookieless pings when consent is denied: no identifiers, no cookie, and Google uses them to model rather than to attribute
• Modelled conversions are an estimate Google produces from those pings; they are not the individual user, and treating them as such is where reporting goes wrong
• Denied still means denied. Consent Mode changes what a tag transmits, never whether you were allowed to identify someone

The honest objection to server-side tracking is not technical, it is operational. You are taking on a piece of always-on infrastructure that sits between your website and your revenue reporting, and it needs an owner.

• A server or container that must stay up: when it is down you are not collecting, and nothing on the page will tell you
• Hosting cost that scales with traffic, modest at low volume and not modest at high volume
• Monitoring, because a silent failure looks exactly like a quiet week in the reports
• Maintenance as vendor APIs change, which they do
• A named owner. The most common failure we see is a server container configured once by someone who has since left

We would rather talk you out of this than build you something that quietly rots. Server-side tracking earns its keep when measurement error is costing you real decisions, and at low volume it usually is not.

• Low traffic: if a few hundred sessions a month decide nothing, better data changes nothing either
• No decision hanging on it: if nobody would spend differently based on the numbers, the numbers are not the bottleneck
• No owner: infrastructure without a maintainer is a future outage with your revenue reporting attached
• Your real problem is elsewhere: leads arriving untracked, or nobody following up, are cheaper and more valuable to fix first
• You want it to avoid consent. That is the one reason we will decline the work