Consent modes, GPC and Google Consent Mode

This page walks a privacy owner and a front-end engineer through the consent controls of the browser collector: the mode saved for each domain, the declaration on the script tag, the four consent categories, the treatment of Global Privacy Control (GPC) and Do Not Track (DNT), and the Google Consent Mode v2 bridge. It describes mechanisms. It is not legal advice; you decide which mode fits your notices.

What it is

Availability: Evaluation access. Availability depends on your plan, role and the modules enabled for your organisation.

The core script runs on every page without consent. It issues the session token, runs the minimal security check and answers server challenges. The extensions script carries device recognition, analytics, session replay and behavioral signals, and each of those lanes needs its own consent category: analytics, replay, deviceId or behavioral.

A consent mode, saved per domain, decides how the categories get their values:

Domains created before the api default keep the mode they have.

When the mode is not not_required, the collector also enforces the decision on its own side. The loader adds an nxc parameter that lists the granted categories to collector requests, and the collector discards what you have not granted.

Prerequisites

• Workspace admin access to Backoffice → Integrations & API → Script & Consent. Without that role the settings are read-only. Saving needs a step-up MFA confirmation.
• A consent banner or consent management platform (CMP) whose decision your page can read, for api mode, or a cookie from your own domain that it writes, for cookie mode.
• The core tag installed as described in Install and Browser Runtime.
• For GPC and DNT policy changes: workspace admin access to Backoffice → Web Analytics & Privacy → Consent & Privacy, and for session replay Capture Policies.
• A decision from your privacy owner on the mode and on the legal basis. See Legal basis register and receipts and Cookies, storage and consent categories for your site.

Steps

1. Choose the consent mode for the domain

1. Open Backoffice → Integrations & API → Script & Consent.
2. Pick the domain in the Domain card.
3. Open the Consent & extensions tab.
4. Set Consent mode to one of:
   • Not required — nothing waits for a visitor decision
   • API — my page calls setConsent() (default for new domains)
   • Cookie — read my consent cookie
5. For Cookie, fill Cookie name and, if needed, Required value (optional). The name takes 1 to 64 letters, digits, ., - or _. The value takes 1 to 128 letters, digits or . _ : % + -. Leave the value empty to treat any non-empty cookie as consent. Otherwise the URI-decoded cookie value must contain your text, so a CMP string such as OptanonConsent can be matched on one group with C0002:1.
6. Select Save script & consent settings and confirm the MFA prompt.

The tab also holds the switch Load the extensions script automatically once consent is granted (immediately in Not required mode). In Not required mode it loads the extensions for every visitor, including those who declined your own banner, and the Backoffice shows a warning when you turn it on in that mode.

gcm is a client-side declaration, not a saved mode. The Backoffice rejects it.

In cookie mode the loader reads the cookie when it starts and again on visibilitychange and focus, so a decision made in your banner applies when the visitor returns to the tab. The cookie must be readable by script; an HttpOnly cookie is invisible to the loader.

2. Declare the mode on the tag (optional)

The saved mode reaches the browser with the session token. Until then, a client without a declaration behaves as not_required. If your decision reaches the page by API, declare the mode so the client is strict from its initial line of code:

<script
	src="https://collect.noxtica.com/collector/noxtica-collector-core.js"
	data-site-key="pk_prod_your_site_key_here"
	data-consent-mode="api"
	data-auto-init
	data-auto-check-once
	async
></script>

The Snippets tab adds this attribute with the switch Add data-consent-mode=“api” to the core snippet. The shorthand data-consent-cookie="<name>" or data-consent-cookie="<name>=<value>" declares a cookie mode. An invalid declaration is ignored.

A declaration is a client-side measure. A domain that must be enforced on the server needs the mode saved in the Backoffice.

getConsent() and the noxtica:consent-changed event carry modeResolved. It is false until the saved mode arrived with the token, and true afterwards. Wait while it is false. A loader older than 3.8.1 does not send the field, so undefined means “keep using mode”.

3. Connect your banner to the four categories

A granted category still depends on the features enabled for your domain. Consent never switches on a feature your configuration leaves off. For the legal classification of each feature, see Install and Browser Runtime.

Call setConsent from your banner. Each value is the string 'granted' or 'denied'; omitted keys keep their value:

function applyChoices(choices) {
	const state = (allowed) => (allowed ? 'granted' : 'denied');
	window.noxticaClient.setConsent({
		analytics: state(choices.statistics),
		replay: state(choices.statistics),
		deviceId: state(choices.preferences),
		behavioral: state(choices.marketing),
	});
}

// Run when your decision is known and the client exists.
document.addEventListener('noxtica:ready', () => applyChoices(readMyChoices()), { once: true });

Then load the extensions, unless Load the extensions script automatically once consent is granted or data-extensions="auto" does it for you:

const result = await window.noxticaClient.loadExtensions();
if (!result.ok) console.warn(result.reason, result.code);

Legacy forms keep working: setConsent('granted' | 'denied') sets analytics, and setReplayConsent(true | false) sets replay.

What a denial does:

• deviceId denied: the persistent device stores are deleted and the device id stays in memory and sessionStorage.
• analytics denied: the tracker and RUM stop and the buffered analytics events are purged.
• replay revoked while recording: the recorder detaches.
• A repeated call with the same values changes nothing and fires no noxtica:consent-changed.

In Not required mode a grant is not needed: an explicit denied is the sole value that blocks a category. When persistent device recognition is switched off for the domain, a gated mode never writes the persistent device id, even after deviceId is granted.

A page check that your banner has not yet allowed is skipped, not failed. noxtica:collected then carries skipped: 'consent_required', and the check runs by itself when deviceId is granted later on the same page.

4. Decide how to treat GPC and DNT

The browser reports the signal in getConsent().privacySignal: 'gpc' when navigator.globalPrivacyControl is true, 'dnt' when navigator.doNotTrack is '1' or 'yes', otherwise null. The field is a local flag; the loader adds it to no request body. Browsers also send Sec-GPC or DNT request headers, and the collector reads those.

The domain policy decides what the signal does:

Set the policy in Backoffice → Web Analytics & Privacy → Consent & Privacy. The page lists domains that still need a consent or privacy decision. For each one, set Legal basis, Requires consent and DNT/GPC policy. Documented override needs an approved legal basis and the checkbox Acknowledge documented override. Saving needs step-up MFA.

Session replay has its own DNT/GPC policy, with the same two values, in its replay policy under Backoffice → Web Analytics & Privacy → Capture Policies. See Session replay.

The collector backs the client up. With policy Honor and a request that carries Sec-GPC: 1 or DNT: 1:

• POST /client/tracker answers 200 with { "ok": true, "eventsProcessed": 0, "reason": "dnt_gpc_honored" }, and nothing is stored.
• Console-log upload is refused with console_logs_dnt_gpc_honored.
• For replay, the replay policy call answers { "ok": false, "enabled": false, "reason": "replay_dnt_gpc_honored" } and no upload capability is issued.

The loader does not read the signal in the core steps: the session token, the minimal security check, the anti-automation counters and protected actions.

5. Bridge Google Consent Mode v2 (optional)

Use the bridge when your CMP already drives Google Consent Mode. Turn it on in one of four ways:

<script
	src="https://collect.noxtica.com/collector/noxtica-collector-core.js"
	data-site-key="pk_prod_your_site_key_here"
	data-consent-mode="gcm"
	data-auto-init
	async
></script>

noxtica('consent', 'gcm'); // command queue; also client.enableGoogleConsentMode() or createClient({ consentMode: 'gcm' })

What the bridge does:

• It reads Google’s consent state from window.google_tag_data.ics, listens for changes to analytics_storage and ad_storage, and picks up a decision made before the collector loaded. If Google’s state is not on the page yet, nothing is granted, and the bridge checks once a second for about five minutes.
• analytics_storage maps to the analytics category and to nothing else. replay, deviceId and behavioral keep needing your explicit setConsent. ad_storage is read and ignored.
• It can tighten and cannot loosen. On a domain saved as api or cookie, Google can deny what your decision allowed, and can never grant what the saved mode withholds. On a domain saved as not_required, a tag that declares gcm makes the client behave as gated until Google says granted.
• getConsent().mode reads gcm while the bridge is on, and each real change fires one noxtica:consent-changed.

Google Consent Mode is a signal format. It is not a legal basis, and mapping it to a single category keeps a Google analytics_storage grant from being read as consent to replay or device recognition.

6. Test the result

1. Load the page in a clean profile with your banner unanswered. In DevTools → Network you see the core script and POST /client/token. localStorage holds no nox_ keys, and sessionStorage holds the token.
2. Read the effective mode after the token arrived:

document.addEventListener('noxtica:collected', () => {
	const consent = window.noxticaClient.getConsent();
	console.assert(consent.mode === 'api', 'unexpected consent mode', consent);
});

3. Answer the banner with consent. Expect noxtica:consent-changed, then noxtica:extensions-loaded, then a noxtica:collected with a fingerprintId. Collector requests now carry nxc= with one letter per granted category: a analytics, r replay, d deviceId, b behavioral.
4. Withdraw a category and confirm the matching storage disappears.

Once the extensions are loaded, the events noxtica:consent-rejected and noxtica:consent-reset on window purge the durable analytics buffer. Dispatch one from your banner when a visitor rejects or resets consent and you want that purge: window.dispatchEvent(new CustomEvent('noxtica:consent-rejected')).

Verify it works

• getConsent() shows the mode you saved and modeResolved: true.
• Before consent in a gated mode, the page makes no call to Noxtica other than the core script and POST /client/token, and noxtica:collected reports skipped: 'consent_required'.
• After consent, the extensions load, nxc appears on collector requests and noxtica:collected carries a fingerprintId.
• For a visitor with GPC on and policy Honor, privacySignal is 'gpc' and no tracker or RUM request leaves the page.

Troubleshooting

Related

• Install and Browser Runtime: install, storage disclosure and the legal classification table.
• Client API, events and the command queue: setConsent, getConsent and the consent events.
• Script attributes and client options: data-consent-mode, data-consent-cookie and data-extensions.
• Protected actions: the minimal security check that runs without consent.
• Cookies, storage and consent categories for your site: what to disclose in your cookie notice.
• Legal basis register and receipts: recording the basis behind a DNT/GPC override.
• Cookie policy: Noxtica’s own cookie notice.