Consent mode tracking

This is the exact file agents read, including the credit header and licence notice. Save it as consent-mode-tracking/SKILL.md.

---
name: consent-mode-tracking
description: Configures consent-aware, privacy-safe measurement so analytics and advertising tags respect the user's consent choice, the numbers stay explainable, and the legal decision is left to a human. Covers the Consent Mode v2 signals, setting the consent default before any tag, basic versus advanced mode, regions, persistence and withdrawal, and passing consent to a server container. Use when the request mentions consent mode, Consent Mode v2, cookie consent, a CMP, ad_storage, analytics_storage, ad_user_data, ad_personalization, the gcs parameter, "traffic dropped after the cookie banner", or consent modelling. Do NOT use to decide whether or how you must collect consent or to write banner legal text (a lawyer or DPO), to build the container (gtm-container-management), to configure the GA4 property (ga4-measurement-setup), to validate that tags fire (analytics-qa-validation), ad-platform conversions (conversion-tracking-capi), or to analyse the collected data (funnel-analysis, cohort-retention-analysis).
license: CC BY 4.0. Free to use and adapt with credit to Afeez Adebayo.
metadata:
  author: Afeez Adebayo
  website: https://afeezadebayo.com
  linkedin: https://www.linkedin.com/in/afeez-adebayo/
  source: https://afeezadebayo.com/skills-md/data/analytics-tracking/consent-mode-tracking/
  category: data
  subcategory: analytics-tracking
  version: 1.0.0
  created: 6 November 2026
  updated: 6 November 2026
---

# Consent mode tracking

Consent turns measurement into a question of order and honesty. Set the consent default after the tag and the first page view fires before the user has chosen. Pick the wrong mode and a change in how many people accept cookies looks like a tracking crash. Treat consent as only a banner and the analytics quietly over-counts or under-counts for every visitor who declined. This skill makes an AI agent configure consent so tags respect the choice, the numbers stay explainable, and the legal decision stays with a human.

The job is the consent signals and privacy-safe collection, not the law and not the plumbing. Whether you must collect consent, and the wording of the banner, are legal questions for a qualified adviser. The container that holds the tags, the analytics property they feed, and the proof that they fire each belong to a sibling skill. This skill configures the consent layer to a legal decision someone else has made, and it says so plainly rather than pretending the choice is technical.

This is not legal advice. Whether and how you must collect consent depends on your markets and your legal basis, which is a question for a qualified adviser or your data protection officer. Treat every regulatory claim here as something to confirm with them, not as a ruling.

## When to use this skill, and when not to

Use this skill to configure consent mode, decide between basic and advanced mode, order the consent default before tags, handle regions, persistence and withdrawal, pass consent to a server container, and explain a change in the numbers that consent, rather than a bug, caused. It fires on consent mode, Consent Mode v2, cookie consent, a CMP, `ad_storage`, `analytics_storage`, `ad_user_data`, `ad_personalization`, the `gcs` parameter, "traffic dropped after the cookie banner", and consent modelling.

Do not use it to decide whether you need consent or to write the banner's legal copy, which is a job for a lawyer or data protection officer. Do not use it to build the container that holds the tags, which is `gtm-container-management`, though the two work together on ordering. Do not use it to configure the GA4 property, which is `ga4-measurement-setup`. Do not use it to prove the tags fire correctly, which is `analytics-qa-validation`. Do not use it for ad-platform conversions, which is `conversion-tracking-capi`. If there is no legal decision about which markets require consent, stop and get one before configuring anything.

## Inputs the agent must have before starting

Ask for these in one message, and do not assume them:

1. The markets or regions you operate in, and the legal basis for tracking in each, from legal or your DPO. This skill configures to that decision; it does not make it.
2. The consent management platform (CMP) in use, and whether it is synchronous or loads asynchronously, because that changes the timing settings.
3. Which tags need which consent: analytics, advertising, functional, so each is gated on the right signals.
4. Whether you want basic or advanced consent mode, or need the trade-off explained before deciding.
5. Whether a server-side container is in use, because the server has no built-in consent mode.
6. Where consent choices are stored and how long they last, so return visits and withdrawal are handled.

If this is a request to explain a drop rather than to configure, scope it to that: check whether consent explains the change before proposing any tag work.

## Workflow

### Step 1. Get the legal basis from a human first

Confirm which markets require consent and on what legal basis, from legal or the DPO. Everything below configures the technical layer to that decision. If no decision exists, stop and get one, because building a consent setup with no legal basis is guessing at compliance.

### Step 2. Map the consent signals to your tags

Consent Mode v2 has four signals you will set most often: `ad_storage`, `analytics_storage`, `ad_user_data` and `ad_personalization`. Three more exist for other purposes: `functionality_storage`, `personalization_storage` and `security_storage`. Decide, per tag, which signals gate it. Analytics tags gate on `analytics_storage`. Advertising tags gate on `ad_storage` together with `ad_user_data` and `ad_personalization`. A tag that is gated on the wrong signal either leaks data the user declined or loses data the user allowed.

### Step 3. Set the default before any tag, update on the choice

The consent default must run before any command that sends measurement data, and before the Google tag loads. Set it to denied for the signals that require consent. Then, when the user chooses, send a consent update that changes the state.

- Use `wait_for_update` with a millisecond value when the CMP loads asynchronously, so tags wait for the update rather than firing on the default. A common value is a few hundred milliseconds; tune it to the CMP.
- Set region-specific defaults with ISO 3166-2 codes, and remember that the more specific region wins, so a state default overrides a country default.
- Decision rule: if the consent code runs out of order, the defaults do not apply at all, so ordering is the first thing to confirm, before anything else in this list.

### Step 4. Choose basic or advanced mode, deliberately

The two modes behave differently when consent is denied, and the choice has real trade-offs.

- Basic mode blocks Google tags until the user consents. When consent is denied, no pings are sent at all, and recovery relies on generalised modelling.
- Advanced mode loads the tags immediately in a denied state. When consent is denied, cookieless pings are still sent, which feeds advertiser-specific modelling and GA4 behavioural modelling.

Decision rule: if strict compliance and a simple setup matter most, and you can accept losing the data of users who decline, use basic mode. If you want to recover modelled measurement from users who decline, and you have the expertise to maintain it, use advanced mode, which requires basic mode in place first. State the limit either way: platform modelling only activates above sustained volume thresholds, so below them there is no modelled recovery and the raw drop is what you see. Verify the current thresholds against the platform's documentation rather than quoting a fixed number.

### Step 5. Persist, restore, withdraw and version the choice

Consent Mode does not store the user's choice. Your site must save it, in a first-party cookie or storage, and reapply the consent update on every later page before any tag needs it. Build the three paths that are easy to forget:

- Restore: on each page load, read the saved choice and send the matching update before tags fire.
- Withdraw: a reject path that sets the signals to denied and clears the stored choice, so a user can change their mind.
- Version: when the privacy policy or the vendor list changes materially, re-ask rather than relying on a stale consent.

When `ad_storage` or `analytics_storage` is denied, two settings help preserve measurement without cookies: URL passthrough, which passes click identifiers such as `gclid` in the URL instead of a cookie, and ads data redaction, which redacts ad data and takes effect only while `ad_storage` is denied.

### Step 6. Pass consent to the server, then verify

A server-side container has no built-in consent mode. It depends on the web container passing the consent state, through the GCS parameter (`G100` denied, `G111` granted), a consent event, or a consent-state object on the request. The CMP custom event is the more reliable signal, because the GCS value can miss a consent granted after the page has loaded. Consent checks on server tags are obligatory, the same as on the web.

Then verify: in a tag assistant, no consent-gated tag fires before consent; the consent parameters on outgoing Google requests change from denied to granted after acceptance; a return visit restores the saved choice; and the reject path sets denied and clears storage. When the numbers move with no code change, check whether a consent-rate or mode change explains it before calling it a bug. Deep instrumentation QA belongs to `analytics-qa-validation`.

## Worked example

An EU site sees analytics traffic fall about 35% the week it launches a cookie banner, and the team assumes tracking broke.

The agent checks ordering first and finds the consent default was added but fires after the Google tag, so on the first page view the tags ran before the default applied, leaking data for visitors who would later decline. It also finds the site uses basic mode with no advanced mode, and sits below the modelling threshold, so denied sessions send nothing and there is no modelled recovery. Most of the 35% is consent, not breakage.

The fixes: move the consent default ahead of the Google tag, add `wait_for_update` for the asynchronous CMP, persist the choice so return visits do not re-trigger the default, and add a reject path. Whether to move to advanced mode for modelled recovery is raised with the client as a decision for their DPO, because it changes what is collected from users who decline. The agent states plainly that whether advanced mode is lawful for them is a question for their adviser, and annotates the analytics so the drop is not read as a product failure.

## Templates you can use verbatim

Consent default and update (default runs before the Google tag):

```
window.dataLayer = window.dataLayer || [];
function gtag(){ dataLayer.push(arguments); }
gtag('consent', 'default', {
  ad_storage: 'denied', analytics_storage: 'denied',
  ad_user_data: 'denied', ad_personalization: 'denied',
  wait_for_update: 500
});
// on the user's choice, from the CMP callback:
gtag('consent', 'update', {
  analytics_storage: 'granted', ad_storage: 'granted',
  ad_user_data: 'granted', ad_personalization: 'granted'
});
```

Per-tag consent mapping:

```
tag: GA4 (analytics)          -> requires analytics_storage
tag: Google Ads (remarketing) -> requires ad_storage, ad_user_data, ad_personalization
tag: functional widget        -> requires functionality_storage (or ungated if strictly necessary, per legal)
```

Verification checklist:

```
[ ] Legal basis and markets confirmed by a human (not decided here)
[ ] Each tag gated on the signals that match its purpose
[ ] Consent default runs before the Google tag; wait_for_update set for async CMPs
[ ] Basic vs advanced chosen deliberately; modelling thresholds verified, not assumed
[ ] No consent-gated tag fires before consent (checked in a tag assistant)
[ ] Consent signals flip from denied to granted after acceptance
[ ] Choice persisted first-party, restored on return, withdrawable, re-asked on policy change
[ ] Server container reads consent passed from the web container, if used
[ ] No PII in any consent signal; legal questions routed to a human
```

Legal line to include in any handover: "This configures consent to a legal decision you have made. Whether and how you must collect consent is a legal question for your adviser or DPO, not a technical one."

## Failure modes and anti-patterns

1. Consent code out of order. You spot it when tags fire before the user chooses, so the first page view leaks data. Fix it by setting the consent default before the Google tag and adding `wait_for_update` for asynchronous CMPs.
2. Reading a consent-driven drop as a tracking bug. You spot it when the numbers fall with no code change and the fall tracks the banner launch or a consent-rate shift. Fix it by checking the consent rate, the mode and the modelling thresholds before touching any tag.
3. No persistence or withdrawal path. You spot it when the banner re-asks on every page, or a user cannot change their mind. Fix it by storing the choice first-party, reapplying it on each page, and adding a reject path that sets denied and clears storage.
4. Assuming the server respects consent. You spot it when server-side tags fire for users who declined. Fix it by passing the consent state from the web container to the server and checking it on every server tag.
5. Treating consent as a purely technical task. You spot it when a setup is built with no legal basis, or when regulatory requirements and dates are stated with confidence and no source. Fix it by getting the markets, legal basis and banner wording from legal or the DPO, and labelling this work as configuration, not advice.

## Quality bar for the consent setup

Before handing over, confirm every item:

- The legal basis and the markets that require consent were confirmed by a human, not decided here.
- Each tag is gated on the consent signals that match its purpose.
- The consent default is set before any Google tag, with `wait_for_update` for asynchronous CMPs.
- Basic or advanced mode was chosen deliberately, with the trade-off stated and the modelling thresholds verified against current documentation rather than assumed.
- The choice is persisted first-party, restored on return visits, withdrawable, and re-asked when the policy changes materially.
- For a server-side container, the consent state is passed from the web container and checked on each server tag.
- It was verified that no consent-gated tag fires before consent, and the signals flip from denied to granted after acceptance.
- No personal data appears in any consent signal, and every legal question was routed to a qualified adviser.

## Tool-specific appendix

```
Google Consent Mode v2 specifics (version-dependent: verify before relying on them)
- Signals: ad_storage, analytics_storage, ad_user_data, ad_personalization (set most often); plus
  functionality_storage, personalization_storage, security_storage. No values are set by default.
- Commands: gtag('consent','default',{...}) sets the initial state and must run before the Google tag and
  any config/event; gtag('consent','update',{...}) changes it after the user acts. Out-of-order code means
  the defaults do not apply.
- wait_for_update: a millisecond value gives an asynchronous CMP time to call update before tags fire.
- Regions: ISO 3166-2 codes in the default; a more specific region (e.g. US-CA) overrides a broader one (US);
  a default with no region covers everyone else.
- url_passthrough: set true before config to pass gclid, dclid, gclsrc, _gl and wbraid in the URL when
  storage is denied. ads_data_redaction: set true to redact ad data; it takes effect only while ad_storage
  is denied.
- Basic vs advanced: basic blocks Google tags until consent and sends no pings when denied (generalised
  modelling); advanced loads tags immediately and sends cookieless pings when denied (advertiser-specific
  and behavioural modelling). Advanced requires basic first. Modelling needs sustained volume above
  platform thresholds; below them there is no modelled recovery.
- Server-side: no built-in consent mode; the server reads consent passed from web GTM (GCS G100 denied /
  G111 granted, a consent event, or a consent-state object). A CMP custom event is the more reliable signal.
```

## Sources

- Google, Consent Mode guide (the consent signals, default versus update, default must run before the Google tag, wait_for_update, region ISO 3166-2 codes and specificity, url_passthrough parameters, ads_data_redaction only when ad_storage is denied, out-of-order defaults). Last verified 6 November 2026; consent parameters are version-dependent, so re-check the documentation.
- CookieYes, basic versus advanced consent mode (basic blocks tags and sends no pings when denied with generalised modelling; advanced loads tags and sends cookieless pings when denied with advertiser-specific modelling; advanced needs basic first). Last verified 6 November 2026.
- Consent Mode v2 implementation guide (denied-by-default ordering, wait_for_update, storing the choice and reapplying it on return visits); this skill improves on it by covering advanced mode, the withdrawal and versioning paths, and routing the legal decision to a human. Last verified 6 November 2026.
- Stape, consent settings for server-side GTM (no built-in consent mode on the server; consent passed via the GCS parameter G100/G111, a Data Tag consent state, or a CMP custom event, with the custom event the more reliable). Last verified 6 November 2026.
- Consent and modelling thresholds are platform-set and version-dependent; re-check the platform documentation before relying on specific numbers.
- Related skills: gtm-container-management (ordering the consent step in the container), ga4-measurement-setup (the property the consented data feeds), analytics-qa-validation (telling a consent effect from a tracking fault), conversion-tracking-capi (ad-platform conversions), event-tracking-plan (the event spec).