Platform Integrations

ConsentStack automatically signals your visitors' consent choices to the advertising and analytics platforms you already use. Enable an integration in your dashboard, and the SDK handles the rest -- no extra code, no manual wiring.

This is especially important for platforms like Google that require real-time consent signals to comply with regulations like the EU Digital Markets Act. Without proper signaling, your ad measurement and remarketing data degrades or stops entirely.

How integrations work

When a visitor makes a consent choice (or arrives with a saved preference), the SDK notifies every enabled platform using that platform's native consent API. Each platform adapter follows the same lifecycle:

1. Initialize with deny-all defaults. The adapter sets a privacy-safe default state before any tracking occurs.
2. Wait for consent. The platform's scripts can load, but they respect the denied state and do not collect data.
3. Update on consent change. When the visitor grants or revokes consent, the adapter calls the platform's consent API with the new state.

This means platforms with native consent APIs can load their scripts immediately -- they handle consent natively and do not need to be blocked. Platforms without a native API (like LinkedIn) rely on script blocking instead.

Google Consent Mode v2

Google Consent Mode v2 (GCM) is the most important integration for most sites. It signals consent state to Google Tag Manager, Google Analytics 4, Google Ads, and all other Google tags.

How ConsentStack implements GCM

ConsentStack runs GCM in Advanced Mode. This means Google tags load immediately and receive consent signals through the gtag('consent', ...) API, rather than being blocked until consent is granted.

On initialization, the adapter sets deny-all defaults for all consent types:

The adapter also enables ads_data_redaction (strips ad click identifiers when consent is denied) and url_passthrough (preserves ad click info in URLs without cookies, improving conversion measurement in cookieless scenarios).

wait_for_update behavior

The default consent state includes a wait_for_update window of 500 milliseconds. This tells Google tags: "Hold off -- a consent update is coming." If the visitor has a saved consent preference, the SDK fires the update within this window. If no saved preference exists (first visit), the defaults remain until the visitor interacts with the banner.

This avoids a race condition where Google tags fire with denied defaults before the SDK has time to restore a returning visitor's granted state.

Script blocker bypass

Because Google tags respect consent signals natively, ConsentStack does not block Google scripts. Google Tag Manager, Analytics, and Ads scripts load normally and respond to the consent state set via gtag. This is the correct behavior for GCM Advanced Mode.

Meta (Facebook Pixel)

The Meta adapter uses the fbq('consent', ...) API built into the Facebook Pixel.

On initialization, the adapter revokes consent by default:

fbq('consent', 'revoke')

When a visitor grants marketing consent, it calls:

fbq('consent', 'grant')

If the visitor later revokes consent (through the preferences panel), it switches back to revoke. The Facebook Pixel respects these signals and adjusts its data collection accordingly.

Meta scripts bypass the script blocker because the Pixel has a native consent API.

TikTok Events API

The TikTok adapter uses TikTok's built-in consent methods on the ttq object.

On initialization, the adapter holds consent:

ttq.holdConsent()

When marketing consent is granted, it calls ttq.grantConsent(). If revoked, it calls ttq.revokeConsent().

TikTok scripts are not bypassed in the script blocker -- they are blocked until consent is granted. Even though TikTok has a consent API, the adapter does not allow the scripts to preload.

Microsoft (Bing UET & Clarity)

The Microsoft adapter covers both Bing UET (Universal Event Tracking) and Microsoft Clarity. It uses UET's consent signaling API, which follows a pattern similar to Google Consent Mode:

uetq.push('consent', 'default', { ad_storage: 'denied' })

When marketing consent is granted, it pushes an update:

uetq.push('consent', 'update', { ad_storage: 'granted' })

Microsoft scripts bypass the script blocker because UET has a native consent API.

Pinterest Tag

The Pinterest adapter uses the pintrk('setconsent', ...) API:

pintrk('setconsent', false)   // default: denied
pintrk('setconsent', true)    // on consent grant

Pinterest scripts are not bypassed in the script blocker -- they are blocked until consent is granted.

LinkedIn Insight Tag

LinkedIn does not offer a native consent API. The Insight Tag either tracks or it does not -- there is no way to tell it "load but do not collect data."

Because of this, ConsentStack manages LinkedIn entirely through script blocking. When marketing consent is denied, the Insight Tag script is blocked from loading. When consent is granted, the script is unblocked and loads normally.

Adapters and script blocking

Not all platforms handle consent the same way. The table below summarizes how each integration interacts with the script blocker:

Platforms that bypass the script blocker have mature consent APIs that reliably prevent data collection when consent is denied. Platforms that do not bypass it are blocked as an extra layer of protection -- even if they have a consent API, ConsentStack blocks the script to be safe.

What's next

• Script Blocking -- how ConsentStack prevents unauthorized scripts from executing
• SDK Installation -- add the SDK to your site
• JavaScript API -- programmatic access to consent state