Hi there, I have a question regarding the interaction between experimenting with GrowthBook and users tracking consent. Typically, when a new user (no previous tracking consent) arrives we generate a page based on the default values from the GrowthBook API and overlay this page with a tracking consent overlay. In case the users approves to be tracked, the tracking id is set and the overlay disappears. However, once the user interacts with the page, now that a tracking id is available, the page will generate elements based on the tracking id (including experiment variations). Thus this user might have a bad user experience moving from the default value to experiment variation. A reload after the overlay, which would fix this issue, is not an option. How would you takle this issue? Cheers and thank you for the help. FYI @microscopic-honey-15884 @mysterious-iron-16289

Hi Tim, That is a tough one, and depends on strict you are on reading what are essential cookies. One option is to generate the tracking id, but not persist it with cookies yet, save it locally somewhere, and then when the user opts in to essential cookies, you can save it properly. Some systems don't let you force the tracking Id like this, so that might be an issue. This will let you bucket the user correctly, but you would also have to queue up the trackingCallback() call to make sure you don't fire it without consent. One other issue is that if the user refreshes, they may get a different variant.

Thanks for the input!

I'm not sure that that offers any significant advantages. You're still setting a cookie to store a user value (what features/experiments they'll get) - it just doesn't uniquely identify a person. It also means for analysis, you'll have to map from seed id to the actual metrics/conversions that happened, so you're logging that mapping to a user_id somewhere.