Client-side tracking is losing its grip. Ad blockers are used by over 30 percent of internet users in many markets (PageFair, "Adblock Report," 2025), Apple's Intelligent Tracking Prevention limits cookies to 7 days, and GDPR requirements are tightening. The result is that businesses relying solely on traditional browser-based tracking lose between 30 and 40 percent of their data (Stape.io, "Server-Side Tracking Data Recovery Benchmark," 2025). Server-side tracking solves these problems by moving tracking from the user's browser to your own server.
What server-side tracking is and why it has become essential
Server-side tracking means that tracking data is sent from your server instead of directly from the user's browser to third parties like Google, Meta, and LinkedIn. In traditional client-side tracking, you place JavaScript code (for example the GA4 script or Meta Pixel) on the website, and the user's browser sends data directly to the platforms. The problem is that the browser increasingly blocks, limits, or shortens these requests.
Three factors drive the need for server-side tracking. First: ad blockers. Tools like uBlock Origin, Brave Browser, and Safari block requests to known tracking domains (google-analytics.com, facebook.com/tr, etc.). Second: browser restrictions. Safari ITP limits cookies set via JavaScript to 7 days, and Firefox has similar restrictions. Third: GDPR and Consent Mode v2, which since March 2024 requires that user consent signals be sent to Google for all advertising in the EEA.
The result is a perfect storm of data loss. A business using only client-side tracking can lose 30-40 percent of its conversion data, according to benchmark studies from Stape.io and Addingwell. For advertising platforms that optimize based on conversion data, this means worse algorithm performance, higher CPA, and lower ROAS. Server-side tracking recovers large portions of this data loss.
How server-side tracking works technically
In a server-side tracking architecture, the flow is three-part: The user's browser sends data to your server (a dedicated subdomain, for example data.yourdomain.com), your server processes and enriches the data, and your server forwards the data to end destinations like GA4, Google Ads, Meta, and other platforms.
Because data is sent to a first-party domain (your own subdomain) instead of directly to google-analytics.com or facebook.com, you bypass most ad blockers. Cookies set by your server (server-set cookies) are first-party cookies and do not have the same limitations as JavaScript-set cookies in Safari — they can last up to 13 months instead of 7 days.
Additionally, server-side tracking gives you full control over the data that is forwarded. You can remove personally identifiable information, anonymize IP addresses, add consent status before data is sent to platforms, and log exactly what is sent to whom. This is a fundamental advantage for GDPR compliance compared to client-side tracking where the browser sends data directly to third parties without you being able to inspect or modify the requests.
GTM Server-Side container: Setup with Google Cloud and Stape.io
Google Tag Manager Server-Side is the most widely used platform for server-side tracking. Setup requires a Server Container in GTM (created separately from your regular Web Container) and a server infrastructure layer that runs the container code. The two most common options are Google Cloud Platform (App Engine) and Stape.io.
Stape.io is the easiest path to server-side tracking. You create an account, select server location (choose Europe for GDPR correctness), and Stape provisions the server environment automatically. Pricing starts from around 20 euros per month for low traffic volume. Stape also offers a user-friendly interface for configuring DNS settings and SSL certificates.
For Google Cloud, setup is more technical: you create a Google Cloud project, deploy the Server Container code to App Engine, configure a custom domain (subdomain of your main domain), and set up SSL. The advantage is full control and potentially lower cost at high traffic volumes. The disadvantage is that it requires technical expertise and ongoing maintenance. For most businesses, we recommend Stape.io as a starting point — you can always migrate to Google Cloud later if the need changes.
Server-side GA4 implementation
For GA4, server-side implementation is relatively straightforward. In your Web Container, you keep the GA4 Configuration Tag but change the transport URL from default (region*.google-analytics.com) to your own server-side domain (for example data.yourdomain.com). All GA4 requests are now sent to your server instead of directly to Google.
In the Server Container, you set up a GA4 client that receives the requests, and a GA4 tag that forwards them to Google's collection endpoint. The client parses the request and makes the data available as event data in the Server Container. You can then use triggers and variables in the Server Container to modify the data before it is forwarded — for example removing PII, adding server-side enrichment, or routing different events to different destinations.
An important detail is configuring server-side cookie setting. GA4's client ID is typically stored in a cookie (_ga). With server-side tracking, you can set this cookie from the server, giving it a longer lifetime in Safari (13 months vs. 7 days). Stape.io and other platforms have built-in support for this. Verify that the cookie is set correctly by inspecting the browser developer tools under Application > Cookies. For more on GA4 setup, see our GA4 setup guide.
Server-side Meta Conversions API
Meta Conversions API (CAPI) is Meta's server-side tracking solution that sends conversion data directly from your server to Meta, in parallel with (or instead of) Meta Pixel in the browser. Meta strongly recommends implementing CAPI because it provides more reliable conversion data used to optimize campaigns.
Implementation via GTM Server-Side involves setting up a Meta CAPI tag in the Server Container. The tag receives event data from the Web Container (via the GA4 request or a dedicated Meta request), enriches it with server-side data (for example hashed email address for matching), and sends it to Meta's server via the CAPI endpoint. You need a CAPI access token from Meta Events Manager.
Deduplication is critical: If you run both Pixel (client-side) and CAPI (server-side), Meta will receive the same event twice. Meta deduplicates based on event_id — ensure you send an identical event_id from both Pixel and CAPI for each event. Without correct deduplication, Meta-reported conversions will double. For a complete walkthrough, see our Facebook Pixel and CAPI guide.
Server-side Google Ads Enhanced Conversions
Enhanced Conversions in Google Ads uses first-party data (hashed email address, phone number, or name+address) to match conversions with Google users. Server-side implementation provides better data quality than client-side because you can send hashed user data from the server without exposing it in the browser.
In the GTM Server Container, you configure a Google Ads Conversion Tracking tag with Enhanced Conversions enabled. The tag receives conversion data and user data from the Web Container, hashes personal data (SHA-256) if not already done, and sends everything to Google Ads via the server-side endpoint. Google uses this data to match the conversion with a Google account, significantly improving conversion measurement.
According to Google, Enhanced Conversions can recover up to 5-15 percent of conversions that would otherwise be lost due to cookie limitations (Google, "Enhanced Conversions Best Practices," 2025). For advertisers with Google Ads budgets over 50,000 NOK per month, this is a direct improvement to ROAS reporting and campaign optimization.
Consent Mode v2: Requirements and implementation
Consent Mode v2 has been required for all Google advertising in the EEA (including Norway) since March 2024. Consent Mode is a framework where your website communicates the user's consent to Google tags, which then adjust their behavior based on consent status. Without Consent Mode, Google Ads and GA4 can lose up to 60-70 percent of conversion data for users who do not give consent.
Consent Mode v2 introduced two new consent types: ad_user_data (consent to send user data to Google for advertising purposes) and ad_personalization (consent to personalized advertising), in addition to the existing analytics_storage and ad_storage. All four signals must be sent for full functionality.
Implementation requires an approved Consent Management Platform (CMP) such as Cookiebot, CookieYes, or Usercentrics. The CMP collects the user's consent and sends the signals to GTM via the dataLayer. In GTM, you use the Consent Initialization trigger to set default values (typically denied for all) and the CMP's callback to update values after the user's choice. Server-side GTM forwards consent signals to Google, Meta, and other platforms. For a detailed walkthrough of conversion tracking with Consent Mode, see our conversion tracking guide.
GDPR compliance with server-side tracking
Server-side tracking is not automatically GDPR compliant — it gives you the tools to comply with GDPR better, but you must configure the setup correctly. The most important principle is data minimization: send only the data that is necessary for the purpose, and nothing more.
Concrete measures: Remove IP addresses or anonymize them on the server before data is forwarded. Hash personally identifiable information (email, phone) with SHA-256 before sending to third parties. Respect consent choices — do not send data to platforms the user has not consented to. Log all data transfers for audit trails. Enter into a Data Processing Agreement (DPA) with all platforms that receive data.
Privacy regulations (GDPR) also require that you inform users about server-side tracking in the privacy policy. Describe what data is collected, to whom it is sent, on what legal basis, and how long it is stored. Data protection authorities have been clear that server-side tracking does not exempt you from consent requirements — you still need consent for tracking purposes that are not strictly necessary for the service.
- Remove or anonymize IP addresses on the server
- Hash PII (email, phone) with SHA-256 before forwarding
- Respect consent choices from CMP — block tags without consent
- Enter DPA with all platforms receiving data
- Update privacy policy with server-side tracking information
- Implement logging for audit trail of all data transfers
First-party data strategy: Cookies and user identification
One of the biggest advantages of server-side tracking is the ability to build a robust first-party data strategy. Server-set cookies are first-party cookies that are not affected by Safari ITP and other browser restrictions. This means you can identify returning users over longer periods and give GA4 and other platforms better data about user journeys.
Technically, you set cookies from the server-side endpoint via the Set-Cookie HTTP header. The cookie is set with the attributes Secure, HttpOnly, SameSite=Lax, and a lifetime of up to 13 months (Safari accepts up to 13 months for server-set cookies with the Secure flag). GA4's _ga cookie and _ga_[container-id] cookie can both be set server-side for longer lifetimes.
Beyond cookies, you can build user identification based on logged-in users. When a user logs in, you send a hashed user ID to GA4 (User-ID feature) that connects visits across devices and browsers. Combined with server-side tracking, this provides a user understanding far superior to cookie-based tracking alone. At LeapJet, we build first-party data strategies that combine server-side cookies, User-ID, and CRM integration for clients who want maximum customer insight within the GDPR framework.
Cost considerations: Hosting, maintenance, and expertise
Server-side tracking has costs beyond what traditional client-side tracking requires. The primary cost categories are server hosting, implementation, and ongoing maintenance. For hosting with Stape.io, costs range from 20-100 euros per month for most businesses, depending on traffic volume. Google Cloud can be cheaper for high-volume sites but requires more technical expertise.
Implementation cost depends on complexity. A standard setup with GA4, Meta CAPI, and Google Ads Enhanced Conversions typically requires 20-40 hours for an experienced implementer. More complex setups with e-commerce data layer, multiple platforms, and advanced consent handling can require 60-100 hours.
Ongoing maintenance is often the underestimated cost. Platforms change APIs, new consent requirements are introduced, and server-side tags need to be updated. Budget 2-5 hours per month for maintenance and troubleshooting. For businesses without internal expertise, this can be outsourced. To see our offering in analytics and tracking, see our SEO and analytics services.
Migration plan: Moving from client-side to server-side tracking
Migration to server-side tracking should be done in phases to minimize risk and ensure data continuity. We recommend a six-phase plan that most businesses can complete over 4-8 weeks.
Phase 1 (week 1): Set up Server Container and server infrastructure (Stape.io or Google Cloud). Configure DNS and SSL for your server-side subdomain. Phase 2 (week 2): Implement GA4 server-side as the first tag. Run client-side and server-side in parallel for one week and compare data to verify that server-side delivers correct data. Phase 3 (week 3): Add Meta CAPI with deduplication. Verify in Meta Events Manager that the quality score is above 6.
Phase 4 (week 4): Add Google Ads Enhanced Conversions. Verify in Google Ads that conversions are registered correctly. Phase 5 (weeks 5-6): Implement Consent Mode v2 fully with server-side signaling. Test all consent scenarios thoroughly. Phase 6 (weeks 7-8): Configure server-side cookie setting for better user identification. Remove any client-side tags now handled server-side. Document the setup and establish maintenance routines. For a thorough walkthrough of GTM setup, see our GTM guide. Also see our glossary for definitions of server-side tracking, GDPR, consent mode, and first-party data.
- Phase 1: Server Container and infrastructure (week 1)
- Phase 2: GA4 server-side with parallel running (week 2)
- Phase 3: Meta CAPI with deduplication (week 3)
- Phase 4: Google Ads Enhanced Conversions (week 4)
- Phase 5: Consent Mode v2 fully implemented (weeks 5-6)
- Phase 6: Server-side cookies and cleanup (weeks 7-8)
