Hi team, 👋 I come bearing another question regarding sticky bucketing. I create sticky bucket experiment with fallback attribute as visitor_id (my anon id) and once user logins, I get user_id and set the value using setAttribute(). I have a web application when user land in non-loggedin state but then logins at some point later. After going through the GB documentation i concluded I only need to call setAttribute to set user_id and then later call getFeatureValue for growthbook to pick user_id from attributes. I wanted to verify it via chat gpt, however it's always prompting me to call gb.refresh() after calling setAttribute saying gb would not recognise the updated attribute. However, gb.refresh does not exist! I checked the gb codebase as well and it seems like setAttribute does indeed calls some private refresh fn. So what it is?? Should I call a refresh fn manually or not? I am using vanilla javascript SDK and not any other SDK on top of it

The way to handle this is to configure a render function that outputs whatever you need in terms of your flag/experiment. Then, whenever you update the attribute, GrowthBook will also run that render function and the content will be updated. https://docs.growthbook.io/lib/js#re-rendering-when-features-change

Any time your evaluate a feature using

getFeatureValue

, it uses the latest user attributes present in the SDK. If you're evaluating a flag with an experiment, this is also when sticky buckets will be persisted. Subsequent calls to evaluate that same feature will receive the same persistent bucket value. RE: fallback attributes + sticky buckets: Let's say you've called

getFeatureValue()

before logging in and the user was bucketed in bucket "2" based on

visitor_id

(fallback attribute). Then they successfully logged in and got a

user_id

, and you apply this back into the SDK via

setAttributes()

. During that same session, if you call

getFeatureValue()

on the same flag for this user who has both a

visitor_id

and

user_id

, then the sticky bucket will be "upgraded" to remember that this user should be bucketed in "2" for their

user_id

.

@happy-autumn-40938 thank you clarifying this...i was caught up badly with chatgpt hallucination....I have one last question to go with it! If I want the bucket "2" to be persisted across devices/browsers for the current user_id, I will have to persist this data on my own backend, correct? and any subsequent calls to gb.getFeatureValue() on another device would entail first calling my own backend to fetch existing bucket and then if not present, use the fallback attribute by gb?

Yes it would mean you need to centralize bucketing. A few ways to do this. Choose one: 1. Host a sticky bucket API endpoint and wrap with a custom sticky bucket service 2. Move all evaluation + sticky bucketing to a remote eval server (plug and play if you use the GB Proxy) 3. Move all SDKs to the backend and only evaluate in that context There’s also a strong case for doing nothing and letting users on different devices see different variants. The experimentation unit effectively becomes a “user device” instead of a user