Server-side tracking: what it fixes, what it costs, and whether you need it
Server-side tracking recovers the conversions ad blockers and Safari quietly delete, but it costs money and upkeep to run. Here's what it fixes, what it doesn't, and an honest table for whether your account has crossed the line where it pays off.
Someone has told you that you need server-side tracking: an agency, a nag in Meta's Events Manager, or an ad for a hosting service you'd have to run. So here is the plain version. Server-side tracking sends your conversion events from a server you control instead of the visitor's browser. Same events, different last hop, and that one change buys durability (ad blockers and Safari's ITP can't interrupt a server), data control, and longer-lived cookies, at a real price in money and upkeep.
This page is the whether, not the how, written by a team that runs a server-side pipeline in production: Buron's first-party pixel. By the end you'll know whether your spend and audience have crossed the line where it pays off, or whether client-side still covers you, because server-side is a decision with a price, not a default. The how (standing up a server GTM container) lives in Server-side tagging with sGTM: setup, costs, and when it's not worth it; the Meta-specific version of the decision lives in Conversions API vs the Meta Pixel: what actually changes.
#The two data paths: it's about who talks to the platform
Client-side and server-side describe the last hop, not where the user is. In
the client-side model, JavaScript in the visitor's browser fires a request
directly to each platform's domain (google-analytics.com, facebook.com),
one request per platform, each visible to and blockable by the browser. In the
server-side model, the browser makes one request to a first-party endpoint
you own (say, track.yourdomain.com), and a server you control forwards the
event to each platform over their server APIs.
Three consequences fall out of that diagram. The platform hop becomes invisible to the browser, so nothing in the browser can block it. The cookie can be set by your server on your domain, which changes its lifetime under Safari. And every event passes through a point you control, where you can enrich, strip, or drop it before any platform sees it. Google's own material frames it the same way: one server container mediating between the page and the platforms (intro to server-side tagging).
#What server-side tracking fixes
Ad blockers and tracking protection stop seeing your tags. Blockers work from lists of known tracking domains and script names. A request to your own subdomain matches neither, so events that died in the browser arrive. The same applies to browser tracking protections that silently drop third-party requests.
Safari's 7-day cookie cap stops applying. ITP caps JavaScript-set cookies at 7 days, so a client-side identifier forgets a returning Safari visitor after a week, and week-two conversions become "new users" with no click to attribute. Cookies set in an HTTP response from your own server on your own domain aren't subject to that cap, which is the single biggest attribution mechanic in the server-side pitch. The full cookie-lifetime picture (what each browser does to each cookie type) is in Tracking after third-party cookies: what actually still works.
Consent-blocked scripts stop being all-or-nothing. When a consent banner blocks a platform's script, the client-side event is simply gone. A server-side pipeline still receives the first-party event and decides, centrally and per platform, what a given consent state allows: one enforcement point instead of a dozen tags each doing it differently.
The page gets faster. Every tracking script you move server-side is JavaScript the visitor no longer downloads and executes. One first-party request replaces a stack of third-party ones.
On Buron's own pipeline, the browser-visible tag and the server-side pixel disagree by a measurable margin on the same traffic, and the gap is exactly the blocked-and-capped events described above. Representative magnitudes (illustrative; the direction is universal): an overall gap in the 10% to 25% range, concentrated where blocking lives (Safari, Firefox, ad-block-heavy audiences) rather than spread evenly across visitors.
#What it does NOT fix
Consent requirements. The obligation attaches to the data, not the transport. A server forwarding events the user didn't consent to isn't resilient tracking; it's a violation with better uptime. Your server-side pipeline needs the same consent signal a client-side tag gets. See Consent Mode v2 without losing your signal for how that signal works.
Attribution gaps. Server-side delivery makes events arrive; it doesn't make them attributable. Cross-device journeys, cross-domain hops (Cross-domain tracking: the checkout-domain trap), and stripped click IDs (Click IDs: what gclid, fbclid, and wbraid do) lose attribution before transport is even a question.
Bad inputs. An event with the wrong value, a broken naming taxonomy, or a misconfigured trigger arrives at Google with perfect durability and is still wrong. Moving bad inputs to the server just ships them more reliably. Signal quality is about what you send, not just whether it lands.
#What it costs: money, then ownership
The infrastructure line is the visible cost. Google's sizing guidance for a production server-side tagging deployment starts at three server instances at roughly $40 per instance per month, or about $120/month floor on GCP before traffic scales it up (Google's server-side overview). Managed hosts run below that at low traffic: Stape's entry tier runs about $17 to $20/month for 500k requests as of July 2026. (Buron's first-party pixel is part of the product itself, so there's no separate infrastructure for you to run or budget for.)
The ownership line is the one nobody budgets. A server container is production infrastructure: someone updates it, monitors it, debugs it when a platform changes an API, and answers for it when events stop flowing at 2 a.m. That's a standing engineering commitment, not a checkout. The full cost breakdown by hosting route (GCP automatic, Cloud Run, managed) is in Server-side tagging with sGTM: setup, costs, and when it's not worth it.
#Do you need it? The honest decision table
Anyone selling you server-side infrastructure has no reason to tell you when not to buy it, so here is the table their page can't print.
| Your situation | Verdict |
|---|---|
| Meaningful ad spend + Safari/iOS-heavy audience | Yes. The 7-day cap and blocker loss are eating attribution you're paying to generate. |
| EU traffic + real consent pressure | Yes, paired with Consent Mode v2 without losing your signal: central consent enforcement is worth it on its own. |
| Spend is small, audience is Chrome/Android-heavy | Not yet. Client-side plus enhanced conversions (Enhanced conversions: what they fix, what they leak, how to turn them on) closes most of your gap for free. |
| No in-house capacity to own infrastructure | Not DIY. A managed gateway or Meta's one-click CAPI covers most of the benefit without the pager (see Conversions API vs the Meta Pixel: what actually changes). |
| Numbers already disagree platform-to-platform | Diagnose first with Why your GA4 and Google Ads conversions don't match, then decide; transport is only one of the standard causes. |
Our position: client-side-only is a sunset asset, eroded further by every browser release and consent update. But server-side is a decision with a price, not a default, and below the spend threshold the price buys you very little.
#The tool landscape
Four ways to run events through a server, in ascending order of ownership:
Meta's one-click CAPI and native platform integrations. Zero infrastructure; the platform runs the server side for you. Covers one platform at a time. Decision framing in Conversions API vs the Meta Pixel: what actually changes.
CAPI gateways and managed sGTM hosts. Stape-class services host the server piece for a subscription; you keep tag-level control without owning GCP. The middle path for most advertisers past the threshold.
Server-side GTM (sGTM). Google's server container, self-hosted on GCP or elsewhere; the standard multi-platform answer, and where practitioner canon like Simo Ahava's work lives. Setup, costs, and the exit ramps: Server-side tagging with sGTM: setup, costs, and when it's not worth it.
Build your own first-party pixel. Full control of capture, enrichment, and destinations: this is what Buron ships as a product component. Right when the pipeline is the product; wrong as a side project.
Shopify runs its own variant of this whole question, a sandboxed pixel model that changes the trade-offs, covered in Server-side tracking for Shopify: the sandbox, CAPI, and the three real routes.
#Where to go next
If you're past the threshold and Google-stack-centric, implement with Server-side tagging with sGTM: setup, costs, and when it's not worth it. If the question arrived as a Meta Events Manager nag, the pixel-vs-CAPI decision is Conversions API vs the Meta Pixel: what actually changes. If you're on Shopify, start from Server-side tracking for Shopify: the sandbox, CAPI, and the three real routes, where the sandbox changes the answer.
But notice what "yes" actually buys you: not a fix, a standing asset that decays. Client-side erodes with every browser release. Server-side breaks quietly the day a platform changes an API, and a server that stops forwarding looks exactly like a server that's working until you reconcile the counts. Whichever side of the line you land on, the real job is catching the drift before it costs you a quarter of conversions, and that's a watch nobody remembers to keep by hand.
Buron's pixel is a first-party, server-side pipeline out of the box: the architecture on this page, running, with event coverage monitored continuously so a silent drop shows up as a dated finding in your inbox instead of a hole you notice three months later.
Frequently asked questions
What is the difference between client-side and server-side tracking?
Client-side tracking sends events from the visitor's browser directly to each platform (Google, Meta, TikTok), where ad blockers, Safari's ITP, and consent-blocked scripts can interrupt them. Server-side tracking sends events from a server you control: the browser talks to your first-party endpoint once, and your server forwards events to the platforms.
Is server-side tracking legal?
Yes, the transport is legal, but what you send still isn't exempt from consent law. GDPR and ePrivacy obligations apply to the data, not the delivery path, so a server-side pipeline must honor the same consent state a client-side tag would. Server-side tracking that forwards non-consented events is a compliance problem, not a clever workaround.
What is an example of server-side tracking?
A store runs a first-party pixel: the browser sends events to track.store.com, the store's own subdomain, where a server enriches them and forwards purchases to Google and Meta over their server APIs. Ad blockers don't block the first-party request, and Safari doesn't cap the server-set cookie at 7 days.