Server-Side Tracking: When First-Party Appearance Masks Third-Party Reality

Server-side tracking has become the advertising industry's primary response to browser-level privacy protections: ITP, ETP, and the deprecation of third-party cookies. The pitch is simple — route vendor pixels through your own domain, and the browser treats them as first-party. What is rarely stated plainly is that this architecture may constitute unlawful personal data processing under the GDPR, regardless of the DNS record type used to implement it.

The Three Implementation Patterns — and Their Legal Distinct Profiles

1. CNAME Cloaking

CNAME cloaking involves creating a DNS CNAME record that points a subdomain of your own domain (e.g., metrics.example.com) to a vendor's infrastructure (e.g., data.vendor-cdn.com). The browser sees only the subdomain, which shares the eTLD+1 with the publisher — and therefore receives first-party cookies. In practice, the HTTP request is ultimately resolved and processed by the vendor's servers.

The technical consequence: cookies set by the vendor via this CNAME endpoint inherit first-party scope. Crucially, ITP's CNAME Cloaking Mitigation (introduced in Safari 14) now caps CNAME-set cookie lifetimes to 7 days, and Firefox 86+ introduced CNAME uncloaking via Enhanced Tracking Protection. Chrome currently applies no such restriction — making CNAME cloaking most effective precisely on the browser with the largest market share.

From a GDPR perspective, the controller-processor boundary collapses here. The vendor's servers receive the full HTTP request including Cookie, Referer, User-Agent, and IP address headers — yet the data subject has no indication that a third party is involved. Art. 13(1)(e) GDPR requires controllers to inform data subjects of recipients or categories of recipients; Recital 60 provides contextual guidance but is not the operative provision of personal data. A privacy notice listing only "analytics" without identifying the specific vendor receiving data via CNAME is almost certainly non-compliant. The Reference EDPB Guidelines 05/2022 or Art. 13(1)(e) directly; Guidelines 05/2020 address consent validity, not recipient transparency specifically, not generic categories.

2. GTM Server-Side Containers

Google Tag Manager's Server-Side (sGTM) mode deploys a Node.js-based container — typically on Google Cloud Run, but portable to any infrastructure — at a first-party subdomain. Client-side tags fire a single request to this container endpoint (e.g., collect.example.com/g/collect), and the container then fans out data server-to-server to Google Analytics 4, Meta CAPI, TikTok Events API, and others.

The technical architecture here is more defensible than raw CNAME cloaking: the operator controls the server container and can, in principle, filter or redact data before forwarding. The X-Forwarded-For header handling becomes critical — if the sGTM container forwards the original client IP to GA4 or Meta, IP anonymization claims are void, since the full IP transits to the vendor's endpoint. Operators should verify via network-level logging whether their sGTM configuration strips IP addresses before outbound forwarding, or whether the default request.extractMacAddress() behavior leaks device identifiers.

Under Art. 26 GDPR, when both the operator and Google jointly determine the purposes and means of processing — which occurs when behavioral data from the container is fed into Google's advertising infrastructure — joint controllership applies. The CJEU's ruling in Fashion ID (C-40/17) established that embedding third-party functionality that causes data transmission makes the embedder a joint controller for that collection phase, even without access to the collected data itself. sGTM does not dissolve this relationship; it merely relocates the collection point.

3. First-Party Data Endpoint Abuse

A subtler pattern involves legitimate first-party endpoints — order confirmation APIs, login endpoints, newsletter subscription handlers — being instrumented to forward behavioral and transactional data to vendor platforms. A POST to api.example.com/checkout/complete might trigger a server-side event to Meta Conversions API enriched with hashed email, order value, and device fingerprint derived from User-Agent and Accept-Language headers.

This bypasses consent management entirely because no client-side JavaScript fires. The user has accepted "functional cookies" necessary for checkout — but the DPA's interpretation (see the DSK's Orientierungshilfe on Tracking, 2022) makes clear that server-side forwarding of transaction data to advertising platforms for conversion attribution is not functionally necessary and requires explicit consent under Art. 6(1)(a) GDPR. The legal basis does not transform based on the technical layer at which processing occurs.

Pseudonymization Claims Don't Withstand Scrutiny

Vendors frequently argue that hashed emails (SHA-256 of [email protected]) constitute pseudonymization sufficient to lower risk. This argument fails against Art. 4(5) GDPR's definition: pseudonymized data remains personal data if re-identification is possible with additional information held by any party. Meta's Custom Audiences matching process is precisely the re-identification step — the hash is matched against Meta's known hash database. The EDPB Guidelines 04/2019 on Article 25 explicitly address this: pseudonymization only reduces risk when the key remains with the controller; here, the "key" is Meta's pre-computed hash table.

Consent String Propagation Failures

TCF 2.2 consent strings are client-side artifacts stored in localStorage or cookies under the key euconsent-v2. Server-side tracking architectures systematically break consent string propagation unless explicitly engineered to forward them. An sGTM container receiving a client-side event must read the consent string from the incoming request payload and conditionally block outbound vendor calls based on TC String parsing — a behavior that requires custom implementation, not a default configuration. Operators relying on sGTM for vendor distribution without verified TC String enforcement are likely firing vendor tags in violation of IAB Europe's TCF Policies and, more importantly, in violation of the user's recorded consent choices.

Actionable Recommendations

• Audit CNAME records: Run dig CNAME metrics.yourdomain.com for every analytics/marketing subdomain. Map each CNAME target to its ultimate controller. Document in your Records of Processing Activities (RoPA) under Art. 30 GDPR.
• Inspect sGTM outbound traffic: Enable Google Cloud Run request logging and analyze outbound HTTP calls from your container. Verify that client IP addresses appear as anonymized (e.g., truncated to /24) in vendor-bound requests by checking X-Forwarded-For and True-Client-IP headers.
• Enforce TC String in sGTM: Implement a custom variable in your sGTM container that parses euconsent-v2 from the incoming client event payload and gates each tag trigger on the relevant vendor consent bit (Purpose 1, Purpose 7, etc.).
• Update privacy notices: Per EDPB Guidelines 05/2020, name specific vendors receiving data via server-side forwarding. "Third-party analytics providers" does not satisfy Art. 13(1)(e) GDPR's requirement to identify recipients.
• Reassess legal basis for server-side Conversions API calls: If your checkout or CRM system forwards transaction data to advertising platforms, document the legal basis explicitly. Legitimate interest under Art. 6(1)(f) is unlikely to survive the balancing test for advertising attribution given the sensitivity of purchase behavior data.
• DPA landscape awareness: The French CNIL has already sanctioned CNAME cloaking implementations in its 2022 cookie guidance. The Irish DPC and German LfDI Baden-Württemberg have both issued formal positions treating server-side collection without consent as equivalent to client-side violations.

The core legal reality is this: the GDPR regulates data flows, not data collection mechanisms. Moving pixels server-side does not relocate legal responsibility — it only relocates technical visibility. DPAs are increasingly technically literate, and the argument that server-side processing inherently differs in legal character from client-side processing has no basis in the text of the Regulation or in current supervisory authority guidance.

This article was produced with AI assistance and fact-checked against verified GDPR case law (GDPRhub). For legal advice, consult a qualified data protection expert.