Consent Mode v2, evaluated server-side

Why client-side Consent Mode is fragile

Consent Mode v2 became mandatory for EEA-targeted advertising in March 2024. Most implementations bolt it onto an existing gtag.js setup, which leaves several failure modes that are silent in the browser but obvious to a regulator auditing your stack.

Consent mapping configuration

The CMP-to-Consent Mode v2 mapping lives in your blueprint. Below is the canonical pattern: explicit value map for each category, default-deny on the wildcard, and per-vendor gates. ad_storage and analytics_storage are deliberately absent because they have no effect on server-side delivery.

# consent-mapping.yaml
# Map your CMP's category booleans to Google Consent Mode v2
# signals (and the equivalents for Meta CAPI, TikTok, etc).
# This runs server-side at the Signal Core before any
# vendor delivery. No gtag('consent', 'update') needed.

global:
  mappings:
    # Google Consent Mode v2 — only ad_user_data and
    # ad_personalization are honoured by Measurement
    # Protocol. ad_storage and analytics_storage are
    # gtag-only and have no effect server-side.
    # Reference Signal's canonical vocabulary so the same blueprint
    # works for any CMP (Cookiebot, OneTrust, Didomi, custom). The
    # customer maps their CMP categories to canonical buckets in
    # Settings → Consent.
    - source: context.consent.canonical.marketing
      target: '@root.consent.ad_user_data'
      mode: value_map
      value_map:
        'true': GRANTED
        'false': DENIED
        '*': DENIED   # default-deny on missing categories

    - source: context.consent.canonical.personalization
      target: '@root.consent.ad_personalization'
      mode: value_map
      value_map:
        'true': GRANTED
        'false': DENIED
        '*': DENIED

  # Server-side gating: events with denied marketing consent
  # are dropped before reaching ad vendors. Analytics-only
  # vendors (e.g. GA4) still receive the event with the
  # consent flags attached so reporting reflects reality.
  gates:
    google_ads:    deny_if_consent_marketing_false
    meta_capi:     deny_if_consent_marketing_false
    tiktok_events: deny_if_consent_marketing_false
    ga4:           always_send_with_consent_signals
    bigquery:      always_send_with_consent_signals

Client-side vs server-side Consent Mode v2

Consent Mode v2 can be implemented at the browser via gtag, server-side via vendor APIs, or both. The surfaces differ on what they actually enforce.

Frequently asked questions

What is Google Consent Mode v2 and who needs to implement it?

Consent Mode v2 is Google's framework for advertisers to communicate user consent state to its ad and analytics products. It became mandatory in March 2024 for advertisers serving ads to users in the European Economic Area, the UK, and Switzerland. Without a compliant Consent Mode v2 implementation, Google Ads will reject conversions and audience uploads from EEA users, and Customer Match won't function.

Why don't ad_storage and analytics_storage work server-side?

ad_storage and analytics_storage are gtag-only signals — they tell gtag whether to set cookies in the browser. They have no effect on Measurement Protocol or Meta CAPI server-side delivery. Only ad_user_data and ad_personalization affect server-to-server delivery decisions, which is why Datafly Signal explicitly excludes ad_storage and analytics_storage from outgoing payloads. Sending them is a common misconfiguration that does nothing in production but pollutes the audit trail.

How is this different from gtag('consent', 'update')?

gtag('consent', 'update') runs in the browser and depends on gtag.js loading, the CMP loading first, and the two coordinating without race conditions. In real-world conditions hits sent in the few hundred milliseconds before consent is initialised may be processed without the right state. Datafly Signal evaluates consent at the Signal Core after the event arrives, eliminating browser-side timing issues. The decision is also auditable in a database row rather than only inferable from client-side behaviour.

Which CMPs does Datafly Signal support?

Any TCF v2.2 framework plus all major non-TCF CMPs: OneTrust, Cookiebot, Didomi, Sourcepoint, Iubenda, Usercentrics, Termly, and Klaro. Mapping is declarative YAML so adding a CMP that exposes consent state in any structured form is a configuration change, not a platform change.

Can the audit log evidence consent for a specific event?

Yes. Every vendor delivery is logged with: event ID, timestamp, vendor target, the consent state at evaluation time, the gate decision (allowed or denied), and the rule that produced the decision. Searchable by event ID, user ID, or vendor. Retention is configurable and runs from a few days for high-volume pipelines up to multi-year retention for regulated industries.

What happens if my CMP fails to load?

The default-deny wildcard rule fires. If consent categories are absent, malformed, or missing, the gate denies. The fail-safe is non-delivery, which is the regulator-defensible posture. Compare this with client-side setups where a CMP load failure can leave gtag in an undefined consent state, often resulting in delivery without consent being verified.