👋 Question about cookie consent and experimentation. My stack : GTM + server side GTM / GA4 -> export to BigQuery. Everything with GB server side controlled. ( no client SDK or integration all driven server side ). My question applies to users who deny our consent banner. When this happens, i do not have a

_ga

cookie and no consistent ID to stitch experiment_view events with the goal metric (ex. "purchase" or "sign_up") (

experiment_viewed

and other events are all dispatched server side). Is there a recommendation here so i don't violate CCPA / GPDR consent rules yet I'm able to properly measure non consented users? Current logic is just default these users to control ( but they won't even show up in my control results on GB either ). Thoughts or any docs about ways to handle this? Thank you! Only thing that i was able to find was this and this guidance is kind of suggesting that there's nothing we can do, but exclude. docs.growthbook.io/kb/google-analytics/google-tag-manager-gtm-troubleshooting > Delay initializing the GrowthBook SDK and firing the

trackingCallback

(which will send the

experiment_viewed

event) until after the user has granted consent. This ensures that analytics and experiment exposure events are only sent when it is legally and technically permitted.

Hello 👋 Thank you for reaching out. Short answer: what you're already doing (exclude non-consented users) is the correct approach, not a workaround. Why there's no clean fix: Without a persistent cookie/ID, there's nothing to join experiment_viewed to a later purchase event on. While processing GA4 data in a GDPR zone, you can't use unconsented data for GrowthBook, if consent mode anonymizes the user ID, GrowthBook can't use that data for calculation. So exclusion isn't a limitation of the docs you found. It's the expected behavior. Some options: 1. Keep excluding. Check what % of traffic this is — if it's large, that's a business/stats caveat to flag, not something to code around. 2. Session-only ID, never persisted. GrowthBook's guidance for pre-consent bucketing is to create an ID for the user without persisting it, so the experiment still runs. If they consent, persist the cookie. You could extend this idea to stitch exposure → conversion within a single session only (in-memory, never written to a cookie/BigQuery). Catches same-session conversions only, and whether this qualifies as "strictly necessary" functional processing (vs. requiring consent) is a legal call, not a technical one (you might want to check with legal counsel) I hope this helps.

Thanks @wooden-pillow-75591. yeah ... i was thinking of maintaining experiemtn view / conversion in session cookie... and then if a conversion happens .. fire off an anon generated user_id => experiment_viewed => and then "purchase" event with the same fake generated user_id ... then my BigQuery will just have the two events it can stitch together. .. i'll have legal take a look as well. Thank you. Just wanted to make sure I wasn't missing anything.

Glad we can help. Please feel free to reach out anytime if you have any other questions. 🙂

things get a bit fuzzy because the same attribute can be used for functional uses, like enabling features for users, or for AB testing purposes. So things depend on your position about what kind of cookie you want to use.

I guess, have people been able to defend A/B testing as functional and NOT a statistics consent?

yes

k .. i have a feeling our legal team will say .. just don't do it heh

ya, legal is there to avoid risk