Server-side tracking is a set-up where the tags that send data to Google Analytics, Google Ads, Meta and the rest run on a server you control instead of in the visitor’s browser. The page sends one request to a subdomain of your own site. The server decides what each platform receives, sets cookies from the server rather than from JavaScript, and forwards events to the ad platforms in the form they match best.
It is sold hard, usually with the line that cookies are going away. Some of that is true and some of it is out of date, so this post separates the two. We reconcile and fix conversion tracking for businesses whose GA4, ad platform and CRM disagree, and we do not run ads, so we have no reason to sell you a server you do not need. What follows is what it fixes, what it does not, how the set-up runs, and what Google Cloud and Stape charge for it in September 2026.
In the usual set-up, Google Tag Manager runs in the browser. Every vendor you add, GA4, Google Ads, Meta, LinkedIn, Hotjar, loads its own script on the page, sets its own cookies, and sends its own requests to its own servers. The browser, and anything installed in it, can see and block each one.
Server-side tagging adds a second container that runs on a server. Google describes it as a way to “measure user activity wherever it happens” with the server running “in your own Google Cloud Platform project, or in a different environment of your choosing”, and the point that matters for data control: “only you have access to the data in the server until you choose to send it elsewhere.” The web container sends a single stream of events to that server, on a subdomain such as data.yourdomain.com, and tags inside the server container forward them to each vendor. The vendors’ scripts never load on the page.
That is the whole mechanism. Everything else, the cookie lifetimes, the ad-blocker resistance, the cleaner data, follows from where the request comes from and who sets the cookie.
Safari is the reason most of this started. WebKit’s tracking prevention policy blocks all third-party cookies with no exceptions, deletes cookies created by JavaScript after seven days without a visit, and, when a visitor arrives through a link carrying a click identifier, caps those cookies at 24 hours. Since most analytics and advertising cookies are set by JavaScript, an iPhone visitor who clicks an ad on Monday and converts the following Tuesday is a new visitor by then, and the ad platform never learns it worked.
Chrome went a different way. After years of announcing that third-party cookies would go, Google said in April 2025 that it would not roll out a new prompt and would leave the choice in Chrome’s settings, and in October 2025 it retired most of the Privacy Sandbox technologies that were meant to replace them. So third-party cookies still work in Chrome for anyone who has not changed the default. The loss is concentrated in Safari, in iOS, and in browsers with blockers installed, which for a consumer business can be a large share of the traffic that matters.
Then there are the blockers themselves. A blocker that stops the Meta script from loading stops the Pixel; a request to your own subdomain looks like part of your site. That is where the “server-side gets around ad blockers” claim comes from, and it is partly right, which is the honest version.
Fixes, in rough order of value. A share of the events that blocked scripts and flaky connections were losing now arrive, because there is one request to your own domain instead of six to other people’s. Cookies set by the server in the HTTP response last longer in Safari than cookies set by JavaScript, with a caveat below. You decide what each vendor receives, which matters if you are in health, finance or law and would rather Meta did not see the form fields. The page loads fewer scripts. And the ad platforms get their preferred inputs, enhanced conversions and Conversions API events, from a reliable source.
The caveat is Safari’s rule on cloaked hosts. WebKit “detects third-party CNAME cloaking and third-party IP address cloaking requests and caps the expiry of any cookies set in the HTTP response to 7 days.” A tagging server on Google Cloud or Stape answers on your subdomain but from their servers, so Safari can still cap the cookie at seven days. Hosts sell workarounds; Stape’s is called Cookie Keeper and needs its Business plan. The cookie gain is real, but it is not the ninety-day cookie the sales page implies.
Now the list it does not fix, which is the list that costs businesses more. It does not remove consent. It does not make a form that fails to reach the CRM reach the CRM. It does not stop internal test submissions counting as leads. It does not change how HubSpot attributes by click time, or stop an attribution tool deleting a lead when it becomes a deal. It does not let Safari track a visitor across other people’s sites. And it does not decide, for you, which of three systems is the source of truth for a number.
These are the two things a server is most useful for, and they are often confused with it.
Google’s enhanced conversions for web send a hashed version of the first-party data the visitor typed into your form, “email addresses, name, home address, and/or phone number”, hashed with SHA-256 and matched to Google accounts that were signed in when they saw the ad. Google’s stated purpose is to “improve the accuracy of your conversion measurement and unlock more powerful bidding.” It can run from the browser; from a server it runs whether or not the Google Ads script loaded.
Meta’s Conversions API is the server-to-Meta channel. Meta’s own guidance is to “use the Conversions API in addition to the Meta Pixel, and share the same events using both tools”, because the API catches events “the Pixel may lose due to network connectivity issues or page loading errors.” To stop double counting, both must use the same event_name and carry either an event_id or an external_id with the browser cookie. Meta scores each event’s customer information as Event Match Quality, and only matched events are used for attribution and delivery optimisation; unmatched ones support basic measurement and nothing else. That is why the fields you send matter more than the channel you send them through.
Neither needs a tagging server. Enhanced conversions can run in the web container; Conversions API events can be sent from a CRM when a lead is created, which is how we usually do offline conversions. What the server adds is one place where both are configured, with the same event IDs, from a request the browser could not block.
If the gaps are test submissions, a form that never reaches the CRM, or an attribution tool deleting leads, no server will fix them. In our experience those gaps are usually bigger than the cookie gap, and cheaper to close. Build the server for the loss that remains.
Cloud Run gives you the logs and the bill; a host gives you a dashboard and a lower price at small volumes. Either way the account should be in your name, not the agency's. Google's own words: only you have access to the data in the server until you choose to send it elsewhere.
That is what turns every vendor's third-party request into one first-party request, and what lets the server set cookies in the HTTP response rather than from JavaScript. Safari still caps cookies from a subdomain that resolves to another company's IP range at seven days, so the cookie gain is real but smaller than most vendors claim.
The GA4 client in the server container receives the browser's events, and the GA4 tag in the server sends them on. Consent mode parameters travel with the request, so a denied analytics_storage still results in cookieless pings rather than a cookie.
Enhanced conversions send a SHA-256 hash of the email or phone the visitor typed, which Google matches to signed-in accounts. Meta's Conversions API sends the same events the Pixel sends, with a shared event_id so each is counted once. Both can run without a tagging server; the server is what makes them reliable.
The consent banner still gates analytics and advertising storage. The consent state is forwarded to the server container, and server tags read it. A server that ignores consent is not a compliance strategy, it is a liability with a subdomain.
The number that should move is matched conversions in Google Ads and Meta, and the share of GA4 sessions that keep their source. If the lead count itself jumps, check for double counting before celebrating.
Two practical notes. The subdomain is the piece people skip: without it the server is a third party too, and you lose most of the benefit. And keep the web container. Server-side tagging does not replace it; the web container is what sends the events to the server in the first place, and it is where consent is collected.
The monthly hosting is the small part. The larger costs are the set-up, the reconciliation on either side of it, and the time someone spends keeping the container current when a vendor changes its tag.
| Option | Monthly cost, 2026 | What you get | Watch for |
|---|---|---|---|
| Stape Free | $0 | 10,000 requests a month, global CDN, setup wizard | Enough to prove the set-up, not to run a site |
| Stape Pro | $17 billed annually ($200 a year); more billed monthly | 500,000 requests, 3-day logs, standard Cookie Keeper, bot detection | One container per subscription. Requests are not GA4 events: a page view can be five to ten requests once scroll, consent and CAPI forwards are counted |
| Stape Business | $83 billed annually ($1,000 a year) | 5 million requests, multi-zone infrastructure, 10-day logs, custom Cookie Keeper, up to 20 domains | The tier you need for the Safari cookie workaround, whatever your volume |
| Stape Enterprise | $167 billed annually ($2,000 a year) | 20 million requests, account manager, up to 50 domains, log export | Downgrades go through support |
| Google Cloud Run | About $45 per instance; Google recommends at least two | Runs in your own project; Google says two to ten servers handle 35 to 350 requests a second | Logging, egress and a load balancer are billed separately. Set a billing alert on day one |
| Done for you | A one-off set-up, then hosting in your name | Reconciliation before and after, the server, subdomain and DNS, GA4, enhanced conversions, Conversions API with deduplication, consent wired through | Ask who owns the accounts when the engagement ends; the answer should be you |
For most small and mid-sized businesses the hosting line is $17 to $83 a month. The set-up is the real spend, and it is worth doing once, properly, with a reconciliation on either side so you can see what it recovered.
Send us what GA4 says, what the ad platform says and what the CRM says for last month. We come back with why they differ, whether a server would help, and a fixed price to make them agree.
See How We Fix TrackingA set-up where the tags that send data to Google Analytics, Google Ads, Meta and other platforms run on a server you control instead of in the visitor's browser. The browser sends one request to a subdomain of your own site, and the server decides what each platform receives. Google Tag Manager's server container is the most common way to run it.
Partly. A blocker that stops vendor scripts loading cannot stop a request to your own subdomain, so the events reach your server. Blockers that filter by URL pattern or by the analytics request itself can still catch it, and Safari caps cookies from a subdomain that resolves to another company's servers at seven days. Treat it as recovering a share of lost events, not all of them.
Yes. The UK regulator's 2025 guidance says the rules on storing or reading information on a device apply whatever the technology, and analytics and advertising are not exempt. Google's consent mode passes the visitor's choice from the web container to the server container, and tags in the server behave accordingly. Moving the tag does not move the obligation.
At 2026 prices, a hosted server container on Stape is free up to 10,000 requests a month, then $17 a month for 500,000 requests, $83 for five million and $167 for twenty million, billed annually. Running it in your own Google Cloud project on Cloud Run is about $45 per instance a month, and Google recommends at least two, so roughly $90 before logging and traffic peaks. Set-up is a separate, one-off cost.
No. Server-side tagging is where your tags run. The Conversions API is Meta's channel for receiving events from a server, and Google's enhanced conversions are the equivalent idea for Google Ads. You can send Conversions API events from a CRM without a tagging server, and you can run a tagging server without Meta. The two work best together: the server sends the same events the Pixel sends, with a shared event ID so Meta counts each once.
No. GA4 works from the browser. A server container helps when Safari and ad blockers are losing a share of your events, when you want to control which fields each vendor receives, or when you want the ad platforms to get enhanced conversions and Conversions API events reliably. If your gap is a form that does not reach the CRM, fix that first; it is cheaper and bigger.
Sources: WebKit Tracking Prevention Policy (third-party cookie blocking, the 7-day and 24-hour caps, CNAME and IP cloaking); Google, An introduction to server-side tagging; Google, Set up server-side tagging with Cloud Run ($45 per instance, minimum of two, 35 to 350 requests a second); Stape pricing, checked 4 September 2026; Meta, Conversions API and Conversions API best practices (redundant set-up, deduplication, Event Match Quality); Google Ads Help, About enhanced conversions for web; Google, Next steps for Privacy Sandbox and tracking protections in Chrome, 22 April 2025, and Update on plans for Privacy Sandbox technologies, 17 October 2025; ICO, Guidance on the use of storage and access technologies; Google, Consent mode. The three tracking findings are from Apexure client work in July and September 2026, with the clients unnamed. All prices in US dollars before promotions.
As CEO and Founder of Apexure, Waseem Bashir's decade-old experience in building high-converting landing pages extends to collaborations with Fortune 500 leaders and over 1000 clients from SaaS, B2B, and B2C domains. Waseem brings a unique blend of technical expertise and a deep understanding of business needs to boost conversion rates for SaaS Sales Funnels and Landing pages. Read more
Three Lead Counts and None of Them Agree? Send Us Last Month’s Numbers and We Will Tell You Why
See How We Fix Tracking“I launched 3 new landing pages yesterday and within 24 hours the Cost Per Lead and all other performance metrics have improved drastically. The process to getting there was efficient.”
James Baldry, Marketing Director, AHR Private Wealth
A website redesign checklist exists for one reason: a redesign changes everything at once, and the things that...
Website maintenance is the ongoing work of keeping a live site updated, secure, fast and correct: platform and...
Get quality posts covering insights into Conversion Rate Optimisation, Landing Pages and great design
