trackbridge-consent

The CMP-wiring skill. Connects Cookiebot, OneTrust, Iubenda, or your custom consent layer to tracker.updateConsent. Includes the consent-replay-on-page-load pattern so you don’t make the user re-click on every visit.

It does not install or pick a CMP. It wires whatever you have.

Frontmatter

name: trackbridge-consent
description: Use when integrating Trackbridge with a Consent Management Platform (Cookiebot, OneTrust, Iubenda, custom CMP), implementing GDPR/CCPA Consent Mode v2, or wiring updateConsent callbacks. Covers ad_storage cookie gating and the deferred-persistence behavior on consent grant.

When it triggers

“Wire Trackbridge to Cookiebot”
“Connect my OneTrust banner to the SDK”
“Set up Consent Mode v2”
“GDPR consent for the click-ID cookies”
Adding a CMP after the SDK is already in place

Prerequisites

Browser tracker created via trackbridge-setup with consentMode: 'v2' configured.
A CMP loaded in your layout — Cookiebot script tag, OneTrust SDK, Iubenda Consent Solution, or a custom banner with grant/deny callbacks.
The CMP must load before createBrowserTracker runs, so its callbacks are available by the time the tracker initializes.

What it touches

The component or page where the CMP callbacks are wired (typically your root layout or a dedicated ConsentProvider component).
Adds tracker.updateConsent(...) calls in the appropriate event handlers.
Optionally: writes a small helper to read the CMP’s saved consent on page load and replay it.

What it asks

Which CMP? Picks from Cookiebot / OneTrust / Iubenda / custom.
Where to wire (component path).
For OneTrust: which group IDs map to ad_storage and analytics_storage (the OneTrust defaults are C0004 for Targeting and C0002 for Performance, but projects often customize).
For custom: how to read the user’s saved choice (cookie name, localStorage key, etc.).
Whether to also call gtag('consent', 'update', ...) from the same callbacks (defaults: yes, if gtag is loaded).

What it won’t do

Choose or install a CMP.
Show its own banner.
Server-side enforce consent. The skill explains: consent on the server is your application’s responsibility — if a user denied consent, don’t fire serverTracker.trackConversion from your code.
Delete existing cookies on consent revocation. The skill mentions this is up to the application; the SDK does not delete.

What it produces

For Cookiebot (in your layout or a ConsentProvider):

'use client';
import { useEffect } from 'react';
import { tracker } from '@/lib/tracker.client';

export function ConsentBridge() {
  useEffect(() => {
    function onAccept() {
      tracker.updateConsent({
        ad_storage: window.Cookiebot.consent.marketing ? 'granted' : 'denied',
        ad_user_data: window.Cookiebot.consent.marketing ? 'granted' : 'denied',
        ad_personalization: window.Cookiebot.consent.marketing ? 'granted' : 'denied',
        analytics_storage: window.Cookiebot.consent.statistics ? 'granted' : 'denied',
      });
    }
    function onDecline() {
      tracker.updateConsent({
        ad_storage: 'denied',
        ad_user_data: 'denied',
        ad_personalization: 'denied',
        analytics_storage: 'denied',
      });
    }
    window.addEventListener('CookiebotOnAccept', onAccept);
    window.addEventListener('CookiebotOnDecline', onDecline);
    window.addEventListener('CookiebotOnLoad', onAccept); // replay on return visits
    return () => {
      window.removeEventListener('CookiebotOnAccept', onAccept);
      window.removeEventListener('CookiebotOnDecline', onDecline);
      window.removeEventListener('CookiebotOnLoad', onAccept);
    };
  }, []);
  return null;
}

For OneTrust, Iubenda, and custom: structurally identical, with different event APIs. See Wiring with a CMP for the full set of patterns.

Behavior the skill makes sure you understand

Pre-grant click identifiers live in memory. A user lands on ?gclid=... before interacting with the banner. The SDK captures the value but doesn’t write the cookie. If consent is granted, the in-memory value is persisted. If denied, it’s discarded on tab close.
Replay on every page load is required. Don’t make the user re-consent every visit. The skill always wires a CMP-specific replay mechanism.
Trackbridge’s consent is separate from gtag’s. tracker.updateConsent does not call gtag('consent', 'update', ...). The skill offers to wire both from the same callback.

Example

You: I have Cookiebot installed. Wire it to Trackbridge.

Claude (router → consent): I see Cookiebot's script in app/layout.tsx
and lib/tracker.client.ts has consentMode: 'v2'.

Where would you like the wiring? I'd suggest a small ConsentBridge
component in app/layout.tsx — runs once, attaches the listeners.

You: Sure.

Claude: Creating components/ConsentBridge.tsx. It listens for
CookiebotOnAccept, CookiebotOnDecline, and CookiebotOnLoad (the
replay on return visits). Mounted in app/layout.tsx.

I'll also wire gtag('consent', 'update', ...) from the same callbacks
so GA4's cookie behavior matches.

To verify: open the site in a fresh incognito window with DevTools →
Application → Cookies open. Land with ?gclid=test123. Confirm no
_tb_gclid cookie. Click Accept on the banner. Confirm _tb_gclid
appears with value test123.

Verification (the skill walks you through this)

Fresh incognito window, DevTools → Application → Cookies.
Land on the site with ?gclid=test123.
No _tb_gclid cookie should be present (consent not yet given).
Click Accept on the banner.
_tb_gclid=test123 now appears.
Reload the page (no URL param). Cookie persists.
Repeat with Decline. No cookie is written even with ?gclid=test123 in the URL.

If step 5 doesn’t update the cookie, the CMP callback isn’t reaching updateConsent. The skill suggests adding a console.log inside the callback to confirm.