Table of content
Your Google Ads and Meta reports no longer match real sales, Safari wipes your cookies within days and your consent banner shrinks the data volume even further. Server-side tracking is often sold as the answer to everything. It does deliver a lot, provided you know exactly what it changes, and what it does not, under the FADP and the GDPR.
This guide answers the questions Swiss agencies and SMEs ask us most often: how it works, compliance, ad platforms, apps, CMS, CRM, hosting and costs.
In short
Server-side tracking routes your data through your own server, on a subdomain of your site, before sending it to Google, Meta or TikTok.
It makes measurement more resilient (Safari ITP, ad blockers, lighter pages) but replaces neither the banner nor consent: a refusal stays a refusal.
For compliance, its strength is control: you decide which data (IP, identifiers) goes to which tool.
Conversion APIs (Meta, TikTok, Google Ads offline conversions) rely on this server, with deduplication through an event ID.
Client-side vs server-side: what really changes
How does server-side tracking work with sGTM?
With classic (client-side) tracking, the visitor's browser loads one script per tool (Meta Pixel, gtag.js, TikTok Pixel) and sends data to each platform itself. With server-side tracking, the browser sends a single stream to your Google Tag Manager Server-Side container (sGTM), hosted on a server you control. That server acts as a sorting hub: it receives the event, cleans it, strips what must not leave, then forwards it only to authorised tools.
Why has client-side tracking become fragile?
Three shifts have reduced the reliability of scripts running in the browser:
Browsers: Safari's Intelligent Tracking Prevention (ITP) caps cookies set by JavaScript at 7 days, and even 24 hours for some link-tracking cases. On iOS, App Tracking Transparency (iOS 14.5, April 2021) requires user permission for cross-app tracking.
Ad blockers: according to GWI (Q2 2025), 30.9% of Swiss internet users run an ad blocker, which targets ad platform scripts first.
Consent: visitors who refuse cookies must not be tracked, which mechanically reduces the observed volume.
Note that Google announced in April 2025 that it would not remove third-party cookies from Chrome. The problem is therefore not an "end of third-party cookies" but these combined restrictions.
What does a first-party subdomain change?
The sGTM server runs on a subdomain of your site, for example measure.your-brand.ch. Requests stay within your own domain (first-party) and cookies can be set by your server rather than by JavaScript, which makes them less exposed to ITP's lifetime limits. Two important caveats:
Since 2023, WebKit also caps at 7 days cookies set by a server whose IP address differs significantly from the website's. Your hosting architecture therefore matters.
This is not about bypassing the visitor's choice: first-party measurement still depends on your banner. It is resilient to technical restrictions, not to refusals.
How much data can you recover?
No universal figure is honest: the gain depends on your share of Safari and iOS traffic, your banner's refusal rate, your audience (more or less equipped with ad blockers) and the starting quality of your tracking. The right reflex is to measure before and after: over a few weeks, compare the conversions reported in Google Ads and Meta with the real sales in your back office.
Does server-side tracking slow the site down?
Rather the opposite. By moving part of the ad platform scripts to the server, you leave less JavaScript for the browser to download and run. The real gain depends on how many tags you remove from the client: check it in your Core Web Vitals reports, not on promises.
FADP and GDPR compliance: what the server can and cannot do
Is server-side tracking mandatory for compliance?
No. Neither the FADP nor the GDPR prescribes a technology. They impose principles: transparency, proportionality, security and respect for people's choices. Server-side tracking is a control tool that helps you apply them. Client-side, the visitor's browser connects directly to each ad platform's servers, which receive its IP address and technical metadata along the way. With an intermediate server, you decide what leaves.
How does the server protect IP addresses and personal data?
In sGTM, every event can be filtered before it is sent: removing or truncating the IP, stripping the User-Agent, excluding URL parameters that contain an email address. For advanced matching (Meta Advanced Matching, Google enhanced conversions), emails and phone numbers are hashed with SHA-256 before transmission.
Watch out: hashing is pseudonymisation, not anonymisation. The platform can match these values against its own user accounts: they remain personal data, which require a legal basis, a mention in your privacy policy and, in the EU, consent.
Do you still need a cookie banner with server-side tracking?
Yes. The place of processing changes, not the obligation. In Switzerland, Art. 45c of the Telecommunications Act requires information and a right to refuse (opt-out); in the EU, ePrivacy and the GDPR require prior consent for non-essential trackers. And since 31 July 2024, Google has applied its EU user consent policy to Swiss traffic: without a properly fed Consent Mode v2, you lose remarketing and full ad measurement.
How does Consent Mode v2 work with sGTM?
Your CMP passes the visitor's choice to Google tags through four parameters (ad_storage, analytics_storage, ad_user_data, ad_personalization). In advanced mode, a refusal triggers cookieless pings, which the server relays without identifiers; Google uses them to model missing conversions. According to Google (2021), this modelling recovers on average more than 70% of ad-click-to-conversion journeys lost to cookie refusals. In the EU, have your DPO validate this mode: these pings remain a technical data flow. The server must also apply consent to non-Google tags (Meta, TikTok, LinkedIn), which ignore Consent Mode.
What about data transfers to the United States?
Server-side tracking does not remove transfers: if you send data to Meta or Google, it goes to those companies. It does, however, let you cut it down to what is strictly necessary. On the legal side, the Swiss-U.S. Data Privacy Framework has been in force since 15 September 2024 (the EU-U.S. framework since 10 July 2023): check that your recipients are certified and list them in your policy. For penalties and detailed obligations, see our FADP and GDPR compliance guide.
A-Track tip
Document your sGTM filtering rules (which data goes to which tool, under which consent condition) in a simple table. It is the most useful document when facing a DPO, a client or the FDPIC, and it serves as the reference for every update.
Meta, Google Ads, GA4 and TikTok: conversion APIs and deduplication
Does Meta's Conversions API replace the Pixel?
No, it complements it. The Conversions API (CAPI) lets your server send events directly to Meta. Meta recommends a redundant setup: the Pixel in the browser and CAPI on the server, for the same events. Step-by-step setup in our Facebook CAPI guide.
How do you avoid counting the same sale twice?
Each event gets a unique identifier (event_id), identical on the Pixel side and the server side. When Meta receives two events with the same name and event_id, it keeps only one. According to Meta's documentation, it generally keeps the first one received, provided the second arrives within 48 hours. Without a consistent event_id, your conversions are inflated and the algorithm optimises on wrong data.
What does the TikTok Events API bring?
A large share of TikTok traffic goes through the app's in-app browser, where scripts and cookies are less reliable. The TikTok Events API sends conversions from your server or your shop (Shopify, WooCommerce): attribution becomes more stable and the algorithm gets more signals to exit its learning phase.
What changes with GA4 server-side?
GA4 receives data through your server, which can set the _ga cookie from your own domain. Google sets its default lifetime at 2 years; set server-side, it holds up better against ITP, within the Safari rules described above. The result, if the visitor has consented: fewer visitors counted twice and better attribution of long journeys.
Mobile apps, web apps and server-to-server
How do you track an iOS or Android app server-side?
Instead of embedding one SDK per ad platform, the app sends its events to a single collection tool (Firebase, or a customer data platform SDK), relayed to your sGTM. The server then translates these events for each advertising API. On iOS, App Tracking Transparency still applies: server-side tracking does not exempt you from asking permission for cross-app tracking.
Should you still embed the Meta or TikTok SDKs?
The fewer, the better: each SDK adds weight to the app, requires updates and sends data you control poorly. Reducing third-party SDKs in favour of a server stream simplifies maintenance and your FADP documentation. Some functions (install attribution, Apple's SKAdNetwork) may still require an SDK or a mobile measurement partner: decide case by case.
What about web apps (React, Vue.js, Angular)?
In a single page application, the page does not reload on each click. You therefore push virtual page view and action events into the dataLayer, which the web GTM container forwards to sGTM. Well designed, this tagging plan does not hurt the app's responsiveness.
Can you connect web and app journeys (cross-device)?
Yes, if the user logs in. An internal user identifier (User ID), sent in pseudonymised form from both the site and the app, lets GA4 and conversion APIs reconcile sessions. This is personal data processing: it must appear in your privacy policy and respect consent.
What is pure server-to-server (S2S) tracking?
In S2S, your back end (PHP, Node.js, Python) sends the event without going through the browser. We often combine both approaches: the back end confirms the sale and sends a webhook to sGTM, which handles distribution to the ad platforms. A webhook fires when a status changes in your database (order paid, delivered): it does not depend on a tab staying open. For headless or custom architectures, it is often the most reliable method, because the event is captured at the source.
S2S must respect consent too: store the visitor's choice with the order so you know which tools may receive the event.
Shopify, WordPress, CRM: connecting your tools
Does server-side tracking work on Shopify?
Yes. Shopify restricts custom scripts on its checkout, which weakens client-side purchase tracking. Solutions go through Shopify's Customer Events (Web Pixels), an app that connects to sGTM, or order webhooks. The sale is then sent as soon as Shopify validates it.
And on WordPress and WooCommerce?
The foundation is a clean e-commerce dataLayer (often through the GTM4WP plugin) with GA4's standard events: view_item, add_to_cart, purchase. The web container then sends this stream to your sGTM, which distributes it to GA4, Google Ads, Meta or Pinterest.
PrestaShop, Magento, Webflow or Wix?
PrestaShop and Magento give full back-end access: ideal for standardising the data layer and adding S2S on key steps, with good event match quality.
Webflow and Wix are more closed but accept GTM: server-side tracking remains possible for forms and key events, with less depth.
How do you report sales closed offline (CRM)?
In B2B, this is often where server-side tracking pays off most. A prospect fills in a form, the click identifier (gclid, fbclid) is stored in the CRM, and the deal is signed weeks later. When the deal moves to "won" in HubSpot or Salesforce, a webhook sends the identifier and the amount (for example CHF 5,000) to sGTM, which forwards them to Google Ads or Meta. The algorithm then learns to look for customers, not just completed forms. Full method in our CRM offline conversions guide.
What about subscriptions or email marketing?
Recurring payments (Stripe, Chargebee) happen without a site visit: only a server webhook can report them and track customer value over time. For email marketing (Klaviyo, ActiveCampaign), sending events server-side (cart, purchase) makes automated flows more reliable, subject to marketing consent.
Hosting, costs and maintenance
Stape or Google Cloud Platform?
sGTM can be hosted on Google Cloud (GCP), but setup, scaling and monitoring require DevOps skills, and costs vary with traffic. We most often use Stape, a specialised host: a choice of servers in Europe, clear pricing and practical tools such as the Custom Loader (loading GTM scripts from your own domain). Other options exist, including hosting in Switzerland: see our comparison Infomaniak, Google Cloud or Stape.
How much does a setup with A-Track cost?
Our initial setup packages (excluding VAT, CMP licence and sGTM hosting):
Landing pages and small sites: from CHF 1,200.
Standard CMS website (leads and e-commerce): from CHF 2,400.
Custom websites (tagging plan, S2S, CRM): from CHF 4,800.
Package details and options (CAPI, CRM, API) on our Tracking and Compliance page.
Why annual maintenance?
Tracking that was right at launch can break silently: an API update at Meta or TikTok, a new Safari rule, a CMP change, a new plugin, a legal change or a new version of the IAB TCF standard. Our maintenance packages start at CHF 900 per year (small sites), CHF 1,800 (standard CMS) and CHF 3,600 (custom), excluding VAT: monitoring, fixes and regulatory watch.
What return on investment can you expect?
ROI depends on your media budget and on how many conversions are currently missing. The mechanism itself is simple: the more reliable, consented conversions the platforms receive, the better their bidding algorithms learn. Measure the gap between reported conversions and real sales before the project: that is your baseline for judging the result. For the method, see our marketing performance measurement guide.
Where does A-Track stand?
We are not a media agency: we fix and maintain the "plumbing" (CMP, Consent Mode, GTM, sGTM, conversion APIs) so that agency and advertiser campaigns run on reliable, compliant data. Based in Geneva, we start from the Swiss FADP and the GDPR, and our audits test your site against both frameworks, as well as the IAB TCF 2.3 standard when you use it.
Conclusion: where to start
Measure the gap between the conversions your platforms report and your real sales over one month.
Check your consent foundation: CMP, Consent Mode v2, firing rules for non-Google tags.
Prioritise the flows that matter: purchase or lead server-side first, then Meta and Google conversion APIs, then CRM.
Document and monitor: filtering rules, tests after every site or CMP update.
Where should your move to server-side tracking start?
A-Track maps your platforms (Meta, Google Ads, GA4, TikTok), your CMS and your CRM, then proposes a server-side migration plan that fits the FADP and GDPR.
First step: a 30-minute call with an expert.