ConsentStackDocs

Platform Integrations

ConsentStack natively signals consent to Google, Meta, TikTok, Microsoft, Pinterest, LinkedIn, and Shopify.

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 (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.

For the conceptual background, including the June 15, 2026 change that made Consent Mode the single control over Google Ads data, see the Consent Mode v2 setup guide.

How ConsentStack implements GCM

ConsentStack runs GCM in Basic Mode by default. Google tags stay blocked until the visitor consents to their category, so no request reaches Google before that. The adapter still sets the full Consent Mode v2 signal state up front, so when a tag does load it receives the correct consent state immediately instead of firing on stale defaults.

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

GCM consent typeDefault stateConsentStack category
ad_storageDeniedMarketing
ad_user_dataDeniedMarketing
ad_personalizationDeniedMarketing
analytics_storageDeniedAnalytics
functionality_storageGrantedEssential (always on)
security_storageGrantedEssential (always on)
personalization_storageGrantedFunctional

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 blocking

Google scripts are blocked until consent, exactly like any other tracker. Google Tag Manager, Analytics, and Ads are catalogued under their normal categories, and the request-blocking stub holds them at parse time until the visitor grants that category.

Consent Mode sits alongside that, it does not replace it. Running tags before consent means a request reaches Google before the visitor has agreed to anything. That request carries no identifiers, but it is still a request, and not every regulator treats it as equivalent to silence. Blocking first is the reading ConsentStack defaults to.

A per-platform opt-in that loads Google tags before the fence and lets Consent Mode govern them on its own is planned, but it is not available yet and it will never be on by default.

One exception exists today: a Google tag served from your own domain through Google Tag Gateway is a first-party request, so the fence lets it through and only the denied defaults govern it. Keep the ConsentStack snippet above that tag and turn off the CDN's automated tag setup, which Google's own gateway instructions require when you use Consent Mode. The Consent Mode v2 setup guide covers what the gateway changes and how to check whether it is on.

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 are blocked until marketing consent is granted. The fbq consent signal is layered on top of that, so the Pixel knows the visitor's choice once it is allowed to load.

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().

When GPC is honored, the adapter additionally calls ttq("limited_data_use", true). See Global Privacy Control for details.

TikTok scripts are blocked until consent is granted. Even though TikTok has a consent API, the adapter does not allow the scripts to preload.

Bing UET

The Bing UET (Universal Event Tracking) adapter uses UET's consent signaling API, which follows a pattern similar to Google Consent Mode. On initialization, the adapter pushes a deny-all default:

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

When marketing consent is granted, it pushes an update:

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

Bing UET scripts (bat.bing.com) are blocked until marketing consent is granted, with the uetq consent signal layered on top. See packages/sdk/src/platforms/microsoft.ts for the adapter source.

Microsoft Clarity

The Microsoft Clarity adapter uses Clarity's Consent API v2. The SDK calls consentv2 once with the resolved state (granted or denied) every time consent updates, ensuring preference-center revocations after a prior accept are propagated to Clarity:

clarity('consentv2', { ad_Storage: 'granted', analytics_Storage: 'granted' })

Publishers should configure their Clarity project dashboard with "cookies off by default." The dashboard default governs first-load behavior before the SDK runs; once consentv2 is called, the explicit signal wins.

Clarity scripts (clarity.ms) are blocked until consent for their category is granted, with the consentv2 signal layered on top. See packages/sdk/src/platforms/clarity.ts for the adapter source.

Pinterest Tag

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

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

Pinterest scripts 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.

Shopify Customer Privacy

On Shopify storefronts, ConsentStack reports every explicit consent decision to Shopify's Customer Privacy API via setTrackingConsent, so Shopify Analytics and sandboxed web pixels follow the banner. The adapter writes only visitor decisions, never default states, and third-party scripts stay blocked until consent regardless. The full mechanics, including the category mapping and GPC handling, are in the Shopify integration guide.

Adapters and script blocking

Every platform script is blocked until consent. What differs is whether the platform also has a native consent API that ConsentStack signals on top of that:

PlatformNative consent APIBlocked until consentSignal layered on top
GoogleYesYesConsent Mode v2 state via gtag
MetaYesYesfbq consent calls
Bing UETYesYesuetq consent push commands
Microsoft ClarityYesYesconsentv2 calls
TikTokYesYesNone, blocking only
PinterestYesYesNone, blocking only
LinkedInNoYesNone, blocking only
ShopifyYesYesDecisions recorded to the Customer Privacy API

Blocking is the primary control, and it applies to every platform in the table. A native consent API is a second layer, not a substitute: it tells the platform what the visitor chose once its script is allowed to load, and it governs behavior the platform handles internally, such as Shopify Analytics and sandboxed web pixels.

You do not need to configure script blocking rules for integrated platforms. The SDK handles this automatically based on each adapter's capabilities.

What's next