17. Consent & Privacy

Every chapter so far optimized one thing: collect more, lose less. This chapter is the governor bolted onto that engine. It won't make you a lawyer (and isn't legal advice — involve one for anything load-bearing), but it will make you the person in the room who knows what the tooling actually does — which, in practice, is what most compliance conversations need.

The legal frame, in five sentences

1. GDPR (EU/UK) regulates processing personal data — and the bar is low: cookie IDs, click IDs, IP addresses, hashed emails all qualify. The practical legal basis for advertising and analytics tracking is consent; attempts to run ad tracking on "legitimate interest" have mostly died in EU enforcement.
2. ePrivacy (the "cookie law") separately requires prior consent for storing or reading anything on the device that isn't strictly necessary — cookies, localStorage, fingerprinting alike, personal data or not.
3. Together they mean: in the EU/UK (and a growing list of look-alike regimes), tracking tags may not fire — no cookies, no collect requests — before an informed, granular, freely-given opt-in. That's why Chapter 3 counted consent decliners as structural loss.
4. The US runs the other direction — opt-out regimes (CCPA/CPRA and siblings), honored via mechanisms like Global Privacy Control — different defaults, same engineering shape: a consent state that tags must respect.
5. Consent must be recorded, withdrawable, and purpose-granular — which is what a CMP is for.

The CMP and the wiring

A Consent Management Platform (Cookiebot, Usercentrics, OneTrust, CookieYes…) renders the banner, stores the visitor's choice, and broadcasts it to everything else. Since 2024, Google requires a Google-certified CMP for serving EEA ad features — the stick behind Consent Mode v2 adoption.

The GTM wiring is where Chapter 4's "earliest triggers" finally cash in:

Consent Initialization trigger        ← CMP template sets DEFAULTS here:
   gtag('consent','default',{          everything denied (EU posture)
     ad_storage:'denied',
     analytics_storage:'denied',
     ad_user_data:'denied',
     ad_personalization:'denied' })
        │
        ▼
banner shown … visitor chooses …
        │
        ▼
   gtag('consent','update',{ analytics_storage:'granted', … })
        ← tags react; queued Google tags proceed per signal

Defaults must land before any tag executes — that's the entire reason the Consent Initialization trigger exists, and the first thing to audit in any inherited container: what happens in the seconds before the banner is answered?

Consent Mode v2: what the signals do

Consent Mode is Google's machine-readable consent vocabulary — four signals that matter plus housekeeping ones:

Google's tags are consent-aware: they consult the signals at fire time and change behavior — granted means normal operation; denied means no cookies read or written. The state itself travels with every hit (the gcs/gcd parameters you saw riding the stream in Chapter 12).

Google keeps consolidating control under these four signals — as of June 15, 2026, ad_storage alone decides whether advertising data flows to Google (the old GA "Google Signals" toggle no longer gates it). One more reason the defaults in that Consent Initialization call have to be right.

Basic vs Advanced — the decision that matters

• Basic consent mode: Google tags are blocked until consent. Denied visitors send nothing. Maximum caution, maximum data loss — the conservative-counsel default.
• Advanced consent mode: Google tags load and fire regardless, but on denial they send cookieless pings — no cookies set or read, no persistent identifiers, consent state attached. Google uses these pings to feed behavioral modeling: GA4 models the missing users and Ads models the missing conversions, partially backfilling Chapter 3's consent gap with statistics instead of observation.

The trade is explicit: advanced recovers (modeled) signal but does send requests about non-consenting visitors — anonymized, cookieless, and Google-blessed, but plenty of EU privacy teams say no anyway. That's a risk-appetite decision for lawyers, not implementers; your job is to know which mode a setup runs and what that means for the numbers. (Modeled conversions are also why "GA4 says X" got fuzzier in 2024+ — some of X was inferred, not observed.)

Non-Google platforms don't speak Consent Mode. Meta, TikTok, LinkedIn tags are gated the manual way — Chapter 6's per-tag consent settings (additional consent checks) or CMP-template integration mapping banner categories to the signals. An audit that only checks Google tags is half an audit.

Server-side under consent

Now the recurring warning gets its full mechanical treatment. The pipe you built in Part 3 carries consent state end to end: the GA4 stream's gcs/gcd parameters arrive in the event data model, and the server GA4 tag honors and forwards them. Google's side behaves. The part that's on you: every other server tag.

• Gate non-Google server tags on consent state. The Meta CAPI tag does not magically know the visitor declined — you condition its trigger on the consent fields of the event (or on a consent flag you put in the data layer and carried through). Firing CAPI for a non-consenting EU visitor isn't a data-quality bug; it's the violation, moved server-side.
• Use the checkpoint as the enforcement point. A Transformation (Chapter 10) that strips identifiers (em, ph, cookies, IP) whenever consent is absent gives you one place where "denied" is implemented — versus five vendor tags each hopefully configured right. Central enforcement is the genuine privacy upside of server-side.
• Your server is now a processing site. Access logs with IPs, debug logs with payloads, retention of both — that's personal-data processing under your name, needing the same hygiene you demand of vendors (retention limits, access control, a DPA with whoever hosts it — Chapter 15's jurisdiction question made concrete).

And the final form of the rule this guide has repeated since Chapter 9, because it is the single most common server-side misconception sold to clients: moving processing to your server never converts "no" into "yes". What server-side legitimately improves: vendors see less (you minimize what leaves), the first hop can stay in-region, enforcement is centralized, and consented data is collected more completely. What it never does: collect from people who said no.

The working checklist

• Certified CMP; defaults denied at Consent Initialization, before any tag
• Consent Mode v2 signals (ad_user_data, ad_personalization) wired — EEA ads features die without them
• Basic vs advanced mode: chosen deliberately, documented, signed off
• Every non-Google tag gated — web (Chapter 6 consent settings) and server (trigger conditions / transformations)
• Server logs: retention policy, IP handling, access control
• DPAs in place with tracking-path vendors (host, CMP)
• GPC honored where US state law applies
• The data-flow spec (Chapter 5's contract sheet) extended with: what leaves, to whom, under which consent state — your audit answer-sheet

One stop left: every term this series defined, in one place — Chapter 18 — Glossary.