Consent Pro v2 — Cookie scan, page exclusion & GTM Server-Side setup

Consent Pro
1

Hi Finsweet Support,

I’m currently setting up Consent Pro v2 on my Webflow site alongside a full GTM Web + Server-Side setup (via Stape.io). I have three questions:

1. Cookie Scan — Finsweet scripts categorization

When running a cookie scan in the Consent Pro manager, Finsweet’s own scripts (e.g. Consent Pro, Finsweet attributes…) don’t appear in the scan results. Are they automatically assigned to the “Essential” category? If not, how can I manually categorize them since they’re not visible in the scan interface?

2. Page exclusion from Consent Pro

Is there a way to exclude specific pages from the Consent Pro banner/solution rather than selecting which pages to include? An exclusion-based approach would be much easier to maintain as we add new pages over time — we’d only need to exclude a few edge cases rather than remember to include every new page.

For example, I’d like to exclude my legal/terms pages (e.g. /terms-of-service, /privacy-policy, /legal-notice) where no tracking scripts are loaded. More importantly, these pages contain the detailed information about cookies and data processing that users should be able to read before deciding whether to accept or reject cookies — it doesn’t make sense to block access to legal pages behind a consent banner when those very pages help users make an informed decision.

3. GTM Server-Side — companion template?

I’m setting up a hybrid tracking architecture: GTM Web container + GTM Server container (hosted on Stape.io) to manage conversion pixels (Meta CAPI, Google Ads, Pinterest, TikTok..).

I found your GTM Web template for Consent Mode initialization — it’s great. However, I’d like to know: do you provide a corresponding template or recommended setup for the GTM Server-Side container? Specifically, how should consent signals from Consent Pro propagate to server-side tags (CAPI) to ensure they only fire when consent is granted?

If there’s no server-side template, any guidance on how your Consent Mode implementation interacts with server-side forwarding (e.g. via GA4 transport) would be very helpful.

Thank you!

3

Hey @alexandreburgundcont, let me work through each of your questions.

Cookie Scan — Finsweet Scripts

This is expected behavior, not a bug. Consent Pro’s scanner is designed to detect third-party tracking scripts — things that set cookies and require user consent (analytics pixels, marketing tags, etc.). Finsweet’s own scripts don’t track users or set tracking cookies, so they won’t appear in scan results. They’re treated as Essential by nature.

Same goes for GTM — the scanner only shows a badge if it detects a tracker loaded via GTM, not GTM itself as a standalone entry.

If a custom script is being mistakenly blocked, you can dismiss it in the app or wrap it in the Consent Pro API so it runs after initialization:

window.FinsweetConsentPro = window.FinsweetConsentPro || [];
window.FinsweetConsentPro.push(['consent', (instance) => {
  // your code here, runs after Consent Pro initializes
}]);

Page Exclusion

There’s no native page exclusion feature in Consent Pro v2 — it uses an inclusion model. The cleanest workaround is adding the Consent Pro script via page-level custom code (Page Settings > Custom Code) only on pages where you want the banner, rather than site-wide. Your legal pages simply won’t have the script loaded.

If you need more dynamic control, the JS API can handle this:

window.FinsweetConsentPro = window.FinsweetConsentPro || [];
window.FinsweetConsentPro.push(['consent', (instance) => {
  const excludedPaths = ['/terms-of-service', '/privacy-policy', '/legal-notice'];
  if (excludedPaths.includes(window.location.pathname)) {
    instance.elements.banner.hide();
  }
}]);

We’re flagging this with the team to confirm if there are additional native options and will update this thread.

GTM Server-Side — Companion Template

Our docs cover the GTM Web container setup thoroughly — the .tpl template, Consent Mode v2 initialization, region-specific settings, consent-updated triggers, and per-tag consent checks. There’s no dedicated Finsweet template for a server-side GTM container currently.

For your Web + sGTM hybrid via Stape, consent signals should propagate through standard Consent Mode v2 architecture. Consent Pro pushes consent state updates to window.dataLayer, your Web container reads those and initializes the consent states (ad_storage, analytics_storage, etc.), and those signals travel with measurement hits to your sGTM container. Your server-side tags can then read consent signals and fire conditionally via the x-ga-gcs header or incoming event data.

We want to verify with the team whether anything Consent Pro-specific is needed beyond the standard flow — especially for non-Google platforms like Meta CAPI and TikTok. We’ll update here once we have a clear answer. :folded_hands:

5

Hey, thanks for the detailed answers!

Quick follow-up on the open point : you mentioned checking with the team whether anything Consent Pro-specific is needed for non-Google platforms (Meta CAPI, Pinterest CAPI, TikTok Events API) on the server side. Any news on that?

For context, here’s the architecture I ended up with (already running in production, all events validated end-to-end):

  • Consent Pro v2 pushes consent state to dataLayer
  • GTM Web uses your official Consent Pro template to initialize Consent Mode v2 (ad_storage, ad_user_data, ad_personalization, analytics_storage)
  • All web tags (Meta Pixel, Pinterest Tag, Google Ads) are gated on the consent-updated trigger + per-tag Additional Consent Checks
  • Web → Server bridge uses GA4 Event transport (Measurement Protocol) — I tested the Stape Data Tag but hit a persistent 400 error, GA4 Event works perfectly and propagates x-ga-gcs + custom params (event_id, hashed user_data, fbp/fbc/_ga cookies)
  • Server-side tags (Meta CAPI, Pinterest CAPI, Google Ads Server) use “Send data in case marketing consent given” in their Tag Execution Consent Settings

One important caveat I ran into and solved (might be worth flagging in your docs): the GA4 Client on sGTM automatically redacts any cleartext email parameter to "(redacted)" before forwarding it to downstream tags. This silently broke Google Ads Enhanced Conversions for Leads + Meta/Pinterest Advanced Matching for several days (all leads ended up with the same fake hash = SHA256("(redacted)")). Fix was to hash the email SHA-256 client-side (Web Crypto API) before the dataLayer push, then pass it through the GA4 Bridge using the standard user_data.sha256_email_address / user_data.em / user_data.external_id keys (whitelisted by the GA4 Client, no redaction). End-to-end validated. Worth a heads-up in your Consent Pro v2 sGTM guide / forum thread, since anyone using user_email cleartext as a custom param will hit this.

A few things I’d love your team to confirm:

  1. Does the x-ga-gcs consent header propagate identically via GA4 Event transport (vs Data Tag), so non-Google CAPI tags read it correctly?
  2. Is “Send data in case marketing consent given” the recommended pattern for Meta CAPI / Pinterest CAPI / Google Ads Server / TikTok Events API with Consent Pro v2, or do you recommend explicit x-ga-gcs parsing inside each server tag? (TikTok Events API not yet implemented on my side — Phase 2 — but I’d like to know in advance if the same pattern applies.)
  3. Anything Consent Pro-specific I should be aware of for the regional behavior (EU/UK opt-in vs ROW informational) when signals reach sGTM?
    1. Will updates on the non-Google CAPI question be posted on the forum thread or directly in your sGTM docs?

Tested behavior on my side:

  • Consent denied → 0 marketing event reaches any server tag (browser + server both blocked) :white_check_mark:
  • Consent granted → all 3 ad platforms fire with the same event_id (cross-platform deduplication confirmed) :white_check_mark:

Just want a final green light from your team before declaring this fully bulletproof. Thanks again :folded_hands: