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:
- Initialize with deny-all defaults. The adapter sets a privacy-safe default state before any tracking occurs.
- Wait for consent. The platform's scripts can load, but they respect the denied state and do not collect data.
- 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.
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 type | Default state | ConsentStack category |
|---|---|---|
ad_storage | Denied | Marketing |
ad_user_data | Denied | Marketing |
ad_personalization | Denied | Marketing |
analytics_storage | Denied | Analytics |
functionality_storage | Granted | Essential (always on) |
security_storage | Granted | Essential (always on) |
personalization_storage | Granted | Functional |
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 grantPinterest 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:
| Platform | Native consent API | Blocked until consent | Signal layered on top |
|---|---|---|---|
| Yes | Yes | Consent Mode v2 state via gtag | |
| Meta | Yes | Yes | fbq consent calls |
| Bing UET | Yes | Yes | uetq consent push commands |
| Microsoft Clarity | Yes | Yes | consentv2 calls |
| TikTok | Yes | Yes | None, blocking only |
| Yes | Yes | None, blocking only | |
| No | Yes | None, blocking only | |
| Shopify | Yes | Yes | Decisions 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
- Script Blocking. How ConsentStack prevents unauthorized scripts from executing.
- Shopify Cookie Consent Banner with Customer Privacy API. How consent reaches Shopify's Customer Privacy API.
- SDK Installation. Add the SDK to your site.
- JavaScript API. Programmatic access to consent state.
Theming Override Tokens
CSS custom properties for overriding individual banner roles like toggle colors, the focus ring, and the preferences modal size.
Shopify Cookie Consent Banner with Customer Privacy API
A third-party cookie consent banner for Shopify that integrates with Shopify's Customer Privacy API and Google Consent Mode v2. Theme install, no app.