Server-side tagging is not about beating ad blockers. It is about owning your data.

Every server-side taggingiServer-side tagging Running Google Tag Manager on a server you control. Tracking data goes from the visitor's browser to your server first, and you decide what gets forwarded to Google, Meta and everyone else. pitch I see leads with the same line: browsers are killing your cookiesiCookie A small file a website stores in your browser to recognize you on later visits. Ad tracking depends on them, and browsers and privacy laws increasingly limit them., so move the tags to a server and get your conversionsiConversion The action you want someone to take after seeing an ad: a purchase, a form fill, a booked call. Each platform counts conversions by its own rules, which is why two dashboards rarely agree. back. That is true as far as it goes. It is also the least interesting reason to do it.

The interesting reason is that it puts one pipe between your website and every ad platform, and you decide what goes through that pipe.

What actually changes

With the normal setup, every vendor tag runs in the visitor’s browser. Meta’s pixeliMeta pixel A small piece of code on your website that reports visits and actions (page views, leads, purchases) back to Meta from the visitor's browser. Blocked by ad blockers and some browser privacy settings., the Google tag, TikTok, LinkedIn, Hotjar, whatever else marketing added in 2022 and forgot about. Each one reads what it wants from the page and sends it home. You have no visibility into that traffic and no ability to shape it.

With server-side tagging, the browser sends one event to a server container you run, and the container decides what to forward. Google’s own definition is worth reading because it is plainer than most vendor copy: it lets you “measure user activity across devices and platforms by processing data on a server you control, rather than in the user’s browser” (Google, server-side tagging intro).

Inside the container, clients “receive measurement data from a device, transform that data into one or more events, route data to be processed in the container” and send the result on.

Three things fall out of that.

You can enrich before you forward. The server can look up an order value, a lead score, or a customer ID from your CRMiCRM Customer relationship management software, such as HubSpot or Salesforce, where leads, contacts and deals are recorded. Usually the only system that knows whether a lead was real. and attach it to the event before Meta or Google ever see it. Browsers cannot do that safely.

You can strip before you forward. If a platform does not need the full URL, the email address, or the page title, it does not get it. That matters more every year for privacy compliance and it is impossible when the vendor’s own script is running in the browser.

Cookies become first-partyiFirst-party data Information you collect directly from your own visitors and customers (form fills, purchases, your own site's tracking), as opposed to data collected by or bought from someone else.. Safari’s Intelligent Tracking Prevention caps script-written cookies at seven days, and at 24 hours when the visitor arrived through a link with tracking parameters on it (WebKit, ITP 2.3).

A cookie set by your own server on your own domain is not subject to that cap. That is the “recovered conversions” part, and it is real, but it is a side effect of doing the plumbing properly rather than the goal.

What it costs

Be honest with yourself about this before you start. A server container is infrastructure. It needs hosting, a subdomain, a certificate, and someone who will notice when it stops working.

Managed hosts like Stape make the hosting part a monthly line item instead of a devops project, which is the right trade for most businesses under a few million in revenue. It is still a second thing that can break.

The bigger cost is discipline. Server-side tagging only pays off if you also clean up the events. Moving twelve badly defined browser tags to a server gives you twelve badly defined server tags with better cookie lifetimes.

The order to do it in

1. Write down every event you actually need and what it means. Lead, booked call, purchase, and for each one the exact moment it fires and the value attached. This is a document, not a tag.
2. Fire those events once, from the site, into the server container.
3. From the container, forward to Google Ads, GA4iGA4 Google Analytics 4, the current version of Google's free web analytics. Reports visits, traffic sources and conversions using its own attribution rules. and Meta. Use enhanced conversionsiEnhanced conversions A Google Ads feature that sends a hashed (scrambled, one-way) version of the customer's email or phone along with a conversion, so Google can match it to a signed-in user when cookies fail. on the Google side so hashediHashing Scrambling a piece of data, like an email address, into a fixed string of characters that can't be reversed. Two systems that hash the same email get the same string, so they can match records without ever sharing the email itself. first-party data rides along (Google Ads, enhanced conversions).
4. Only then turn off the old browser tags. Run both for two weeks and compare counts first.
5. ReconcileiReconciliation Comparing what the ad platforms say they delivered against what actually happened in your CRM or payment system, and working out where the difference comes from. the platforms against the CRM monthly. If the numbers drift, the plumbing has a leak.

If step one feels like overkill, it is the step that determines whether the rest is worth doing. Most accounts I audit skipped it, and that, not Safari, is why their numbers do not match.