Global GDPR opt-in by default with consent refactor and HubSpot/PostHog hardening#4611
Merged
Global GDPR opt-in by default with consent refactor and HubSpot/PostHog hardening#4611
Conversation
✅ Deploy Preview for flowforge-website ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for flowforge-website ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
Author
|
cc @UnicornGunnerz for visibility |
knolleary
approved these changes
Feb 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR makes GDPR-style consent the default for all users globally (no region-based branching), aligns tool behavior with consent categories, and simplifies consent handling to reduce duplication and improve reliability.
What Changed
1) Global GDPR default consent
security_storagegranted.cc_cookieon returning visits.2) Consent flow refactor (CookieConsent)
applyAnalyticsConsent(...)applyAdsConsent(...)applyFunctionalConsent(...)pushGtmJsEvent()onConsent: idempotent sync on page load (no consent event emission, no GTM repush).onFirstConsent: first explicit user decision handling (state transitions + events).onChange: subsequent preference changes only.3) HubSpot alignment with consent categories
hs-script-loader) is now gated underanalytics.analyticsconsent._hsq.push(['doNotTrack'])_hsp.push(['revokeCookieConsent'])consent.categories.functionalitynow reflects actual CookieConsent state (no forcedtrue).4) PostHog withdrawal hardening
posthog.opt_out_capturing()posthog.reset()posthog.set_config({ persistence: 'memory' })5) Cookie cleanup safety net
autoClearrules in CookieConsent for analytics category, covering:6) Consent copy updates
analytics.Why
Next steps (follow-up PR)
To make consent updates fire tags immediately without page reload for the LinkedIn tag( and avoid per-vendor code changes), we should standardize GTM triggering with a generic consent event model:
Push generic events from the site when consent is granted/changed, e.g.:
ff_consent_update(always on change, with payload)ff_ads_consent_granted, etc.) only if needed.In GTM, create reusable Custom Event triggers (once), then reuse them across tags:
Custom Event = ff_consent_updateKeep each tag’s Additional Consent Checks (
analytics_storage,ad_storage, etc.) as the hard gate.This removes the need to create one-off triggers per tool and keeps tag onboarding scalable for non-engineering teams.
Related Issue(s)
Checklist