Server-Side Tracking Architecture, Explained

Every analytics setup you have ever used probably works the same way. A visitor loads your page. A JavaScript tag fires inside their browser. That tag sends data to Google Analytics, Meta, or whatever platform you are measuring with.

This is client-side tracking. It has been the default for over a decade. And it is quietly falling apart.

Not because the concept is flawed. Because the environment it depends on, the visitor’s browser, is no longer a reliable place to collect data. Scripts get blocked. Cookies get shortened. Consent requirements prevent tags from firing at all. The numbers that land in your reports represent a filtered, incomplete version of what actually happened on your site.

Server-side tracking moves data collection off the browser and onto a server you control. The mechanics are straightforward. The implications for your data quality, your ad platform performance, and your ability to make decisions based on accurate numbers are not.

This article goes deep. It covers how the architecture works, what actually breaks when you rely on client-side alone, how incomplete data quietly wrecks your ad platform bidding, what it takes to build a server-side setup, the mistakes that trip up most implementations, and how to choose a hosting provider. If you run paid media or rely on analytics to make business decisions, it’s worth your time.

What happens in a standard client-side setup

When someone visits your site, the browser loads your page and then runs JavaScript tags, typically managed through Google Tag Manager. Each tag sends a request from the visitor’s browser directly to a third-party domain: google-analytics.com, connect.facebook.net, analytics.tiktok.com.

These are third-party requests. The browser is reaching out from your visitor’s device to servers belonging to companies your visitor has no direct relationship with.

Three things routinely interfere with this process.

1. Scripts get blocked before they execute.

Browser extensions and privacy-focused browsers prevent analytics and advertising scripts from loading. This is not limited to ads. GA4 tags, Meta pixels, and conversion scripts are all affected. When a script is blocked, that visitor’s session disappears entirely from your data. Not undercounted. Gone.

2. Cookies get cut short.

Apple’s Intelligent Tracking Prevention, built into every WebKit browser (which includes Safari on every Apple device), caps JavaScript-set cookies to 7 days. If a visitor clicks an ad and lands on your site with tracking parameters like gclid or fbclid, that cookie is capped to 24 hours. A visitor who clicks your Google Ad on Monday and converts the following Wednesday is treated as a brand new user. The original click gets no credit.

This matters because Safari is not a niche browser. According to StatCounter, Safari holds roughly 18% of global browser traffic and over 25% on mobile. In the US, it accounts for about 32% of all browser usage. If a third of your American visitors are on Safari, a third of your attribution data is being degraded by default.

Safari 26, released September 2025, goes beyond cookie restrictions. It now strips click identifiers like gclid and fbclid from URLs before the page even loads. Not expired.. but removed. Private Browsing, Mail, and Messages all do this by default.

The parameters never reaches your site. There’s nothing for the cookie to store because the value was gone before checkout started. Normal browsing still passes these through for now (incognito doesn’t), but users can enable protection for all sessions manually.

And if Apple’s release notes are anything to go by, this filtering is likely expanding. We’ve been helping teams implement backup parameters and server-side recovery for this. Book a call if you want us to walk you through it.

3. Consent requirements prevent tags from firing.

Under GDPR, CCPA, and similar regulations, you often need explicit consent before executing tracking scripts. Visitors who decline get no tags fired at all. Depending on your market and how your consent banner is configured, this can quietly eliminate a meaningful chunk of your measurable audience.

The net effect: what you see in GA4 or in your ad platform dashboards is not what happened on your site. It is what happened where tracking was permitted and functional. The gap between those two numbers is growing every year.

What a single purchase event actually looks like (and where it breaks)

To really understand why this matters, try tracing what happens when one person buys something on your site.

Client-side – the purchase event journey

1. A visitor completes checkout. Your site’s JavaScript fires a “purchase” event via the dataLayer.
2. Google Tag Manager picks up that event from the data layer and triggers three tags simultaneously -> GA4, Meta Pixel, Google Ads Conversion Tracking.
3. Each tag makes a separate outbound request from the visitor’s browser. GA4 sends to google-analytics.com. The Meta Pixel sends to connect.facebook.net. Google Ads sends to googleadservices.com.
4. Each request carries a payload -> transaction ID, value, currency, items purchased, plus user identifiers like cookies and click IDs (gclid, fbclid, etc.).

Now here’s where it falls apart.

If the visitor is on Safari, the cookie that was supposed to connect this purchase back to the original ad click may already be gone. If they have an ad blocker, the requests to connect.facebook.net and googleadservices.com get blocked outright. GA4 might also be blocked depending on the extension. That purchase happened. You got paid. But as far as your ad platforms are concerned, it didn’t exist.

If the visitor declined consent through your cookie banner, none of the tags fired in the first place. The purchase is invisible to every platform.

The part that people miss is that these failures are silent unless you detect them yourself. No error message and no warning in your dashboard. The event just never arrives.

Server-side – the same purchase, different path and outcome

1. The visitor completes checkout. Same purchase event. Same data.
2. Instead of three separate third-party requests like the client-side setup, GTM sends one request to your server-side endpoint (e.g., collect.datamentari.com). This is a first-party request. Ad blockers don’t typically intercept it.
3. Your server receives the full event payload. It now has the transaction data, the user’s IP, user agent, and any hashed email or phone number you collected during checkout.
4. Your server forwards the event to GA4 via the Measurement Protocol, to Meta via the Conversions API, and to Google Ads via Enhanced Conversions. These are server-to-server requests. They happen outside the browser entirely.
5. Each forwarded event carries a shared event_id. If the browser also managed to send the event directly (some visitors don’t have blockers), the platforms use that event_id to deduplicate. One purchase, counted once, matched correctly.

The difference is structural. In client-side tracking, the browser is the single point of failure, and it fails regularly. In server-side tracking, the browser still kicks off the event, but the server handles delivery. Whether that delivery succeeds is no longer dependent on what extensions the visitor installed or what privacy settings their browser enforces.

	Client-side	Server-side
Request type	Third-party Each tag sends a separate request from the browser to google-analytics.com, connect.facebook.net, etc.	First-party One request goes to your subdomain. Your server decides what gets forwarded where.
Ad blocker resilience	Low These domains are on every block list. When blocked, the event is gone. Not undercounted. Gone.	High Requests go to your own domain. Most blockers are not configured to intercept first-party requests.
Cookie persistence on Safari	7 days, or 24 hours with click parameters JavaScript-set cookies. ITP enforced on every WebKit browser.	Months Server-set via HTTP response header. Requires matching IP since Safari 16.4.
Data enrichment	Limited to what the browser has GTM can manipulate data layer values and run JavaScript variables, but cannot reach your backend or CRM.	Full Your server can append CRM data, hash emails for platform matching, and attach backend fields before forwarding.
Deduplication required	No Each tag fires once from the browser.	Yes Shared event_id needed across browser and server so platforms do not double-count the same event.
PII control	None Data goes straight from the visitor’s browser to third parties. You have no inspection layer.	Full Data passes through your server first. You strip, hash, or block anything before it leaves your infrastructure.

How server-side tracking changes the architecture

Server-side tracking redirects the data flow. Instead of the browser sending requests to Google, Meta, and every other platform individually, it sends one request to a server endpoint on your own domain, something like collect.yourdomain.com. Your server receives that request, processes it, and then forwards the data to each destination.

[DIAGRAM: Server-side tracking architecture. Visitor's browser makes one first-party request to your subdomain. Your server sits in the middle, forwarding to GA4, Meta Conversions API, TikTok Events API, Google Ads. Caption: "One first-party request replaces multiple third-party calls. You control what gets forwarded, what gets stripped, and what never leaves your infrastructure."]

Three things change.

Requests look first-party.

When the browser sends data to a subdomain of your own site, it is making a first-party request. Most blocking tools are configured to intercept known third-party tracking domains, not requests to the site the visitor is already browsing. More events reach your server than would ever reach third-party endpoints directly.

Cookies last longer.

When your server sets a cookie via an HTTP response header from your own domain, the browser treats it as a legitimate first-party cookie. Safari’s ITP is less aggressive with server-set cookies than JavaScript-set cookies. The practical result is that user identity persists longer, which means attribution works across longer time windows.

One important detail: since Safari 16.4, Apple also checks whether the IP address of the server setting the cookie matches the IP of the site itself. If your tracking server runs on a different IP range (which happens with basic cloud setups), Safari can still cap the cookie to 7 days. A proper implementation needs to account for this. It is a detail that a lot of “quick setup” guides skip over.

You control what leaves your infrastructure.

With client-side tracking, data goes directly from the visitor’s browser to third parties. You have no opportunity to inspect, filter, or modify it in transit. With server-side tracking, data passes through your server first. You can strip personally identifiable information, hash email addresses for platform matching, enforce consent rules centrally, filter bot traffic, or enrich events with backend data before anything is forwarded. This is not just a performance benefit. It is a governance layer that many businesses need for regulatory compliance.

How missing conversion data quietly wrecks your ad platform performance

This is the part most articles about server-side tracking skip entirely. They tell you that you’re losing data. They don’t explain what that lost data actually does to the systems making decisions about your ad spend.

Here’s the thing. Google Ads, Meta Ads, and every other major platform now run on automated bidding. Smart Bidding on Google. Advantage+ on Meta. These systems use machine learning to decide how much to bid on each individual auction, in real time, based on patterns they’ve learned from your conversion data.

Key phrase – “from your conversion data.” The quality of what these algorithms learn is entirely determined by the quality of what you feed them.

The learning phase problem

Google’s Smart Bidding strategies need roughly 30 to 50 conversions per month at the campaign level to optimize effectively. Target CPA needs at least 30 conversions in 30 days. Target ROAS needs 50 or more. Below those thresholds, the algorithm doesn’t have enough data points to distinguish signal from noise. Bidding behaviour becomes erratic, costs fluctuate, and performance stays unstable.

Now think about what happens when a portion of your conversions are invisible because of client-side tracking failures. The exact percentage varies depending on your audience. If you have a high Safari share, high ad blocker prevalence, or significant European traffic with consent decline rates, it could be anywhere from 10% to 30% of your actual conversions going unreported. Even at the lower end of that range, it’s enough to keep campaigns below the conversion thresholds they need to exit the learning phase.

A campaign that actually generated 45 conversions in a month might only report 35. The algorithm sees 35 and stays in a semi-learning state. It never hits the threshold it needs to optimize properly. You look at the numbers and think the campaign is underperforming. In reality, the campaign is fine. Your measurement is starving the algorithm.

The algorithm learns the wrong patterns

It gets worse. The conversions that go missing aren’t random. They’re disproportionately from specific user segments.

Safari users (cookie restrictions). Privacy-conscious users (ad blockers). European visitors (higher consent decline rates). Mobile users (higher Safari share). These aren’t fringe audiences. They’re often your highest-value segments.

When the algorithm can’t see conversions from these groups, it doesn’t just have less data. It has skewed data. It learns to optimize toward the segments it can see, which are typically desktop Chrome users who accepted all cookies. It starts bidding more aggressively for profiles that look like those users, and less aggressively for everyone else.

You end up in a situation where the algorithm is actively under-bidding on audiences that are converting but invisible, and over-bidding on audiences that are visible but may not be your best customers. That’s not a data quality problem anymore. That’s budget misallocation, driven by your measurement infrastructure.

What this looks like in Meta specifically

Meta has something called an Event Match Quality (EMQ) score. It’s rated 0 to 10, and it measures how effectively Meta can match your server events to actual Facebook and Instagram user accounts. Higher EMQ means better attribution, better audience building, and better campaign optimization.

Client-side-only setups often land in the 3 to 6 range for key conversion events. Server-side implementations with properly enriched user data (hashed email, phone, IP, user agent) typically reach 7 and above. The exact score depends on the event type. Purchase events naturally score higher because you have the customer’s email and address at that point. PageView events will always score lower because the user hasn’t provided personal data yet.

The practical impact is real. Better EMQ means Meta’s algorithms make targeting decisions with better-matched data. They build more accurate lookalike audiences. They retarget people who actually engaged, not just the subset whose events made it through the browser.

How to tell if this is happening in your account

One way to spot the gap

Compare your backend transaction count against what Google Ads or Meta reports. Pull the number of actual purchases from your payment processor or CRM for the last 30 days. Then pull the conversion count from your ad platform for the same period. If the platform is consistently reporting 15-30% fewer conversions than your backend, that’s the measurement gap in real numbers. That’s revenue your algorithm can’t see, can’t learn from, and can’t optimize toward.

The performance improvement from recovering that signal usually doesn’t show up as a dramatic spike. It shows up as a gradual, sustained reduction in cost per acquisition over 4 to 8 weeks as the algorithm recalibrates against a more complete picture of who your customers actually are.

What server-side tracking does not do

It does not bypass consent requirements. If a visitor does not consent to tracking, you should not be tracking them, regardless of where your server sits. Server-side tracking gives you better infrastructure for respecting consent, not for ignoring it.

It does not eliminate all data loss. If JavaScript is completely disabled in the browser, the initial request to your server will not fire either. The recovery is significant but not total.

It adds cost and complexity. You need to host and maintain a server container. The most common approach uses Google Tag Manager’s server-side container, typically hosted through a managed service like Stape.io or directly on Google Cloud Run. Hosting costs run anywhere from $20 to $100+ per month depending on traffic, plus the time investment for configuration and ongoing maintenance. There’s a more detailed cost comparison in the hosting section below.

And deduplication matters. If you send the same event from both the browser and the server, you can double-count conversions. Every destination needs a shared event ID so platforms can recognise and merge duplicates. This is solvable, but it requires careful implementation.

Server-side tracking and Google Consent Mode v2

If you run Google Ads or GA4 and have any audience in the European Economic Area, this section is for you. Consent Mode v2 is not optional. Google enforced the requirement in March 2024. Without it, Google stops processing advertising data for EEA users entirely. No remarketing audiences. No conversion data flowing into Smart Bidding. No ad personalisation.

Consent Mode v2 introduced two additional consent parameters beyond the original ad_storage and analytics_storage: ad_user_data (consent for sending user data to Google for advertising) and ad_personalization (consent for personalised advertising). Your consent management platform needs to pass all four signals to Google tags.

Here’s where server-side tracking intersects with this, and where a lot of implementations go wrong.

How consent signals flow from client to server

In a client-side-only setup, your CMP updates consent state in the browser and Google tags read that state directly. Straightforward.

In a server-side setup, consent state needs to travel from the browser to your server container, and your server needs to respect those signals before forwarding anything. The GA4 client in your server-side container reads the consent parameters from the incoming request. If consent was denied, the server-side tags shouldn’t fire, and no data should be forwarded.

The critical point

Your server-side container doesn’t have its own relationship with the visitor’s consent. It inherits consent state from the client-side request. If your client-side implementation doesn’t correctly pass consent signals to the Server Container URL (the request going to your server), the server has no way to know what the visitor agreed to.

This creates a specific failure mode that I’ve seen more than once. Everything looks correct in your client-side GTM preview. Consent Mode fires properly. Tags respect consent. But the server-side container receives requests without consent parameters attached, and forwards data it shouldn’t be forwarding. You’re compliant on the client side and non-compliant on the server side, and you won’t notice until someone audits the outbound requests from your server.

Advanced mode vs Basic mode in a server-side context

Quick refresher. Google Consent Mode has two modes. Basic mode doesn’t load Google tags at all until the visitor grants consent. Advanced mode loads tags immediately but sends only cookieless, aggregated pings if consent is denied. Google then uses modelling to estimate the conversions it can’t directly measure.

When you add server-side tracking into the mix with Advanced mode, you get a layered setup that’s actually quite powerful: Google’s behavioural modelling fills gaps from consent-denied visitors, while server-side tracking fills gaps from ad blockers and cookie restrictions on consent-granted visitors. They solve different problems. Together, they give you the most complete picture available under current privacy constraints.

But this also means you need to validate both layers independently. Modelled conversions show up in your GA4 and Google Ads reports with specific indicators. Server-side conversions show up as direct measurements. If you don’t understand which is which, you can misread your data.

A sudden jump in conversions might be Google expanding its modelling, not an actual increase in purchases.

The practical takeaway

If you’re implementing server-side tracking and operating in markets where Consent Mode v2 applies, don’t treat them as separate projects. They need to be configured together, tested together, and validated together.

The consent signals your CMP generates on the client side must flow intact through your server-side container and be respected at every forwarding point.

When it becomes a clear priority

Not every business needs server-side tracking right now. But there are situations where the case is straightforward.

1. You spend meaningfully on paid media.

If you run Google Ads, Meta Ads, or any platform that uses conversion data for bidding optimisation, the quality of your conversion signal is directly tied to your return on ad spend. Missing conversions mean the bidding algorithm is working with incomplete information.

Ian Lewis, head of data and analytics at Launch, put it plainly in The Drum -> without server-side tracking, businesses routinely miss more than 10% of overall sessions.

For campaigns with real budget behind them, recovering that signal changes performance.

2. Your audience includes Safari or mobile-heavy traffic.

If you operate in the US, UK, Australia, or parts of Asia, Safari represents a substantial share of your visitors. Every one of those visitors is subject to ITP cookie restrictions that degrade your attribution. Server-set first-party cookies mitigate this directly.

3. You need centralized data governance.

Instead of relying on each individual browser-side tag to check consent status independently, server-side tracking gives you one enforcement point. Data that should not be forwarded never leaves your server. For businesses operating under GDPR or similar frameworks, this is a much cleaner architecture than trying to manage consent across dozens of client-side tags.

4. Your sales cycle runs longer than a week.

If your typical customer takes more than 7 days from first visit to conversion, Safari’s cookie cap is breaking your attribution by default. The original traffic source is lost. Server-set cookies can persist for months, preserving the connection between the first click and the eventual conversion.

When you can wait

If your ad spend is minimal and most business comes through referrals or word of mouth, the return on a server-side investment is harder to justify.

If you have not yet set up proper client-side tracking, fix the foundation first. That includes custom events, key event marking, data retention settings, attribution configuration. Server-side tracking amplifies the quality of your measurement. If the underlying measurement is incomplete, you are amplifying incomplete data through better pipes. That is not where you want to start.

We wrote about how to check your GA4 setup if you want to start there.

How it gets built

The most common path for businesses at this stage uses Google Tag Manager’s server-side container. The process looks like this.

You provision a server-side GTM container and host it on a platform like Stape.io, which handles the infrastructure, or directly on Google Cloud Run if you want full control. You map a subdomain (e.g., collect.datamentari.com) to point to that container. Use a subdomain name that doesn’t scream “tracking.” Avoid “tracking.yourdomain.com” or “analytics.yourdomain.com.” Some ad blockers maintain lists of common tracking subdomains, so a neutral subdomain reduces the chance of being flagged. DNS propagation takes 24-48 hours.

Your existing client-side GTM container is then reconfigured. Instead of tags sending data directly to GA4, Google Ads, or Meta, they send it to your server endpoint. Inside the server-side container, you create tags for each destination: GA4, Google Ads Conversion Tracking, Meta Conversions API, TikTok Events API.

You configure deduplication using shared event IDs, validate data parity by running both client-side and server-side in parallel, and then cut over once you confirm the server-side setup is capturing at least as much data.

This is not an afternoon project. A proper implementation typically runs 1-3 weeks depending on the number of platforms, the complexity of your existing tracking, and how thorough your testing needs to be.

Common implementation mistakes (and what to look for in your sGTM setup)

Server-side tracking isn’t inherently complicated, but it has a longer list of things that can silently go wrong compared to client-side setups. Client-side issues usually surface quickly because you can preview tags in your browser. Server-side issues hide. The data disappears between two systems, and neither system tells you something is missing.

These are the mistakes I see most often when auditing server-side GTM implementations.

1. Not forwarding user-agent and IP address

When events travel from the browser to your server to the destination platform, certain headers from the original request need to be preserved. User-agent is critical for device and browser reporting in GA4. IP address is used for geographic reporting and, in Meta’s case, for event matching (it contributes to the EMQ score).

If your server-side GA4 tag isn’t forwarding the original visitor’s IP and user-agent, your geographic and device data in GA4 will reflect your server’s location and identity, not the visitor’s. You’ll see a suspiciously high concentration of traffic from whatever region your server is hosted in. That’s a common tell that something is misconfigured.

The GA4 client in the server-side container should automatically extract these headers from the incoming request and map them to the ip_override and user_agent event data fields. But if you’re using a custom client or have overridden defaults, verify that those fields are being populated correctly in the server-side preview mode.

2. Deduplication failures

This is the most common issue, and the most damaging.

If your client-side tags and server-side tags both send the same event to the same platform without a shared event_id, the platform counts the event twice. Your conversion count doubles. Your cost per acquisition halves on paper. Everything looks fantastic in your reports. And all of it is wrong.

The fix: generate a unique event_id on the client side (typically in a GTM variable), include it in both the browser-side tag and the request to your server endpoint, and make sure the server-side tag passes it through to the destination. Meta, Google, and TikTok all support deduplication via event_id.

How to check: in Meta Events Manager, look at the “Overview” tab for your pixel. If you see “Browser” and “Server” sources for the same event and the total count is roughly double what your backend transaction count says, deduplication is broken. Go fix it before you do anything else.

3. Misconfigured Server Container URL

The Server Container URL is the endpoint your client-side GTM container sends data to. It should point to your server-side container’s subdomain.

One common mistake I noticed auditing sGTM setup is that the Server Container URL is set correctly in the GA4 Configuration tag but not in the GA4 Event tags, or vice versa. Some events go to your server, others go directly to Google. You end up with a mix of server-side and client-side data with no consistent deduplication, and partial data quality improvement that’s hard to diagnose.

Go through every GA4 tag in your client-side container. The Server Container URL should be consistent across all of them. Every single one.

4. Consent state not passing through

Covered this in the Consent Mode v2 section above, but it’s worth repeating here because it shows up in audits and they usually fail constantly.

Consent parameters need to travel from the browser to the server container. If they don’t, your server may forward data for visitors who didn’t grant consent. It’s not just a compliance issue but it also causes data discrepancies between your client-side and server-side reporting because events are being counted in different contexts.

In the server-side GTM preview mode, inspect the incoming requests. Look for consent-related parameters (analytics_storage, ad_storage, ad_user_data, ad_personalization). If they’re missing or always set to “granted” regardless of what the visitor chose, the consent pass-through is broken.

Remember it has to pass the consent state when user updates the consent state at any given time. Not just the beginning.

5. Not using server-side GTM’s preview mode

This one isn’t a configuration mistake. It’s a process gap. And it’s everywhere.

Server-side GTM has its own preview and debug mode, separate from the client-side preview. Many teams validate everything on the client side, deploy, and never check what the server is actually receiving and sending.

The server-side preview mode shows you every incoming request, what the server container does with it, and what it sends outbound. It’s the only way to confirm that events arrive intact, that consent is respected, and that outbound requests carry the correct payloads. Use it. Before launch, during parallel testing, and whenever you make changes.

6. Cookie domain mismatches on multi-subdomain sites

If your main site runs on www.yourdomain.com and your tracking endpoint is on collect.yourdomain.com, cookies set by your server need to be scoped to .yourdomain.com (the root domain) to be readable across both subdomains. If the cookie domain is set too narrowly (to just the tracking subdomain), the browser won’t send those cookies back on requests to your main site, and user identity breaks.

This gets worse if you have multiple properties: shop.yourdomain.com, app.yourdomain.com, blog.yourdomain.com. The cookie scope needs to cover all of them, or you lose cross-subdomain user identification. That defeats one of the main benefits you set this up for in the first place.

Comparing sGTM hosting options

Choosing where to host your server-side GTM container is one of the first decisions you’ll make, and it affects cost, maintenance, compliance, and what happens when things go wrong.

I’ll walk through the most common options.

Option 1: Google Cloud Run (self-hosted)

This is Google’s recommended approach if you want full control. You deploy the sGTM container image directly to Google Cloud Run, configure scaling, set up a custom domain with SSL, and manage everything yourself.

Best for teams with DevOps capability who want complete control over infrastructure, logging, and scaling. Also works if you have specific data residency requirements you need to verify at the infrastructure level.

Tradeoffs: you manage uptime. You manage scaling. You manage SSL certificate renewals. You handle debugging when the container won’t start or starts dropping requests under load. If you don’t have someone comfortable with cloud infrastructure, this adds real operational overhead. Costs are usage-based through GCP, which makes them unpredictable when traffic spikes. For most small to mid-size businesses, this is more control than they need.

Option 2: Stape.io

Stape is the most widely used managed hosting provider for sGTM. They handle infrastructure, scaling, and maintenance. You configure your container through GTM as normal; Stape runs it for you.

Best for most businesses and agencies getting started with server-side tracking. It’s the lowest friction path from “no server-side” to “server-side running.”

Pricing starts at around €20/month for 500,000 requests. Important detail: Stape counts both incoming and outgoing requests. If one incoming event gets forwarded to four platforms, that’s five requests against your plan. At multi-platform setups, the actual cost can be higher than the headline price suggests. Use their pricing calculator with realistic routing scenarios before committing.

Stape holds SOC 2, ISO 27001, and HIPAA certifications. They offer a “Custom Loader” power-up that helps bypass ad blockers on the client-side GTM script itself, and a “Cookie Keeper” feature for extending cookie persistence against Safari ITP. Stape Academy provides free training on server-side implementation. Support is via email and chat.

Option 3: Addingwell

Addingwell positions itself as a more premium, managed option with a strong focus on European data residency.

Best for European businesses where GDPR data residency is a hard requirement, and companies that want a white-glove approach with less self-management.

Pricing starts at €90/month for 2 million queries. Here’s the key difference: Addingwell counts only incoming requests. That same event routed to four platforms counts as one request, not five. At high volumes with multi-platform routing, this billing model can actually work out more favourable than Stape’s despite the higher starting price. Run the numbers for your specific setup.

EU-hosted infrastructure. Support includes video calls, not just chat and email. They work through a partner network for implementation rather than offering it in-house. Currently does not hold SOC 2 or HIPAA certifications. That matters if you operate in regulated industries like healthcare or fintech.

Option 4: TAGGRS

TAGGRS builds its own infrastructure independent of Google’s servers. That appeals to companies wanting to reduce dependency on Google’s ecosystem.

Offers a Meta CAPI Gateway dashboard with built-in EMQ score monitoring. ISO 27001 certified but not currently SOC 2 or HIPAA certified. Pricing starts lower than Addingwell with a similar feature set. Worth evaluating if Google infrastructure independence matters to your setup.

Other options

Tracklution, Tag Concierge, and others exist in this space. The market is maturing fast. New entrants appear regularly, existing providers add features quarterly. The comparison above covers the providers most commonly encountered in 2026, but check current pricing and features before committing. These change.

What to actually evaluate

When comparing providers, these are the criteria that matter in practice.

Billing model

incoming-only vs incoming + outgoing makes a big difference when you route to 3-5 platforms. Model your actual scenario, not the minimum tier.

Data residency

If you need EU-only data processing, verify the provider offers EU-hosted infrastructure and can confirm data doesn’t transit through non-EU servers.

Compliance certifications

SOC 2, ISO 27001, and HIPAA matter for regulated industries. Ask for documentation, not just claims on a landing page.

Scaling behaviour

What happens during a traffic spike? Does the container auto-scale?

Is there a request queue, or do events get dropped? Understand the failure mode before it happens.

Support depth

When your server-side container stops forwarding events at 2am, who responds and how fast?

What happens if your tracking server goes down

Nobody really talks about this until it happens.

In a client-side setup, if Google Analytics has an outage, your Meta Pixel still works. If Meta goes down, your TikTok tracking still fires. Each platform fails independently.

In a server-side setup, everything routes through your server. If that server has an outage, you lose all measurement across all platforms simultaneously. Every event that fires during the outage goes to your server endpoint, gets no response, and is lost. Not queued. Lost.

This isn’t hypothetical. Cloud services have outages. Managed hosting providers have outages. SSL certificates expire. Auto-scaling hits limits. You have to have a plan when that happens.

1. Run multiple instances

Run your server-side container across at least two instances. Most managed providers do this by default on paid plans, but verify. Google Cloud Run scales to zero by default, which means the first request after a period of inactivity incurs a cold start delay. For tracking, that delay can cause timeouts.

2. Set up health monitoring

Set up uptime monitoring on your server-side endpoint. Services like UptimeRobot or similar can ping your endpoint and alert you within minutes of downtime. Don’t rely on noticing a gap in your GA4 real-time report. By the time you notice that, you’ve already lost hours of data.

3. Consider a lightweight client-side fallback

Some implementations keep a basic client-side GA4 tag running alongside the server-side setup. It fires only as a backup when the server endpoint is unreachable. This introduces the possibility of some duplicate events (handled by deduplication), but ensures you never have a complete measurement blackout. Whether this tradeoff makes sense depends on how much data loss you can tolerate.

The goal isn’t to build a bulletproof system. It’s to make sure a routine infrastructure hiccup doesn’t create a 6-hour hole in your conversion data on the day your biggest campaign is running.

Where the overall industry is going

JENTIS published the first industry-wide Server-Side Tracking Report in 2026, tracking adoption across regions and company sizes. Their data shows that northern European markets (DACH, Nordics) are leading adoption, larger enterprises are moving fastest, and mid-market companies are accelerating as the tooling becomes more accessible. The US, despite being the largest ad market in the world, is still catching up.

The direction is clear. Browser restrictions are not loosening. Privacy regulations are expanding. Every major ad platform has released a server-side API (Meta CAPI, Google Enhanced Conversions, TikTok Events API) because they recognise that browser-side signals alone are no longer enough for their algorithms to function properly.

The question for most businesses is not whether. It is when. And the earlier you move, the more first-party data you accumulate, the better your cookie persistence, and the stronger your measurement foundation becomes for everything built on top of it.

If you want to know where your current tracking setup stands and whether server-side infrastructure would make a real difference, we can take a look. We review from the outside and walk you through what we find.