https://www.growthbook.io/
Join Slack
Hi there, I'm running into an issue getting sticky bucketing/fallback attributes to work as per the...
# ask-questions
a
Hi there, I'm running into an issue getting sticky bucketing/fallback attributes to work as per the documentation and need some help identifying if this is a bug/implementation issue or a misunderstanding. For context, I want to ensure that a user who initially sees a variation when logged out will continue to see that variation when they log in. Based on this documentation I believe I can achieve that by supplying a fallbackAttribute when the user is logged out and then providing the same fallbackAttribute with a hashAttribute when the user logs in. But when I implement this users are still seeing a different variation when logged in versus logged out, here's a loom demoing the issue: https://www.loom.com/share/bdc9d2e0ae1341029238d421433f39b6 So, have I understood this correctly, or is a different implementation required to persist variations when a user goes from logged out to logged in? Our implementation details: • Vue2 using the GrowthBookVuePlugin and LocalStorageStickyBucketService • StickyBucketing & Fallback Attribute are enabled in settings and the Fallback attribute is enabled on the experiment (confirmed working in loom above) • hashAttribute is id and fallbackAttribute is device_id ◦ *id i*s only provided when users are logged in, device_id is always sent
h
Hello Alex, thank you for the detailed reproduction. So there are a few things here. 1. There was (is) a bug in the JS SDK wherein sticky bucket assignments don't properly persists when setting attributes dynamically via 
gb.setAttributes()
rather than in the SDK constructor. Basically it will fail to load sticky buckets for anything other than the primary hash attribute "id" unless its fed into the constructor. When possible, its probably best to pass attributes directly into the constructor. 2. This is now patched in our repo; however we have not yet published the changes to NPM. Basically you caught this bug between deploys. The NPM publish will probably go out on Monday or Tuesday.
🙌 1
a
Ahh perfect thank you Bryce, will test again as soon as NPM is updated and let you know if there's still issues. Edit: A quick update, even feeding attributes directly into the constructor I run into the same issue. Will test again in v1.2.0 as confirmed above.
Hi @happy-autumn-40938 even after upgrading to 1.2.0 I'm still seeing sticky buckets not being persisted, even if I feed attributes directly into the constructor. Here's a loom: https://www.loom.com/share/e115962720804f5f907059a15cc6cfd4
h
Sorry you're running into this issue. At least we've ruled out the SDK changes. I'll do a bit more digging and see if I can reproduce the bug.
Hi Alex, I'm trying to recreate locally using 
LocalStorageStickyBucketService
and am observing the opposite: No overlap between attributes (base case): 1. 
localStorage.clear()
- clean slate 2. Eval using 
id
(hash attribute) alone returns "*control*". 
id
SB doc written to LS. 3. Eval using 
deviceId
(fallback attribute) alone returns "*variant*". 
deviceId
SB doc written to LS. Moving from fallback to hash attribute (your scenario): 1. 
localStorage.clear()
- clean slate 2. Eval using 
deviceId
returns "*variant*". 
deviceId
SB doc written to LS. 3. Eval using 
deviceId
AND 
id
returns "*variant*". 
id
SB doc written to LS. 4. Eval using only 
id
returns "*variant*". I did notice a few peculiar things in your codebase and wonder if these have any effect: • You're fetching the features portion of the SDK payload outside of the SDK and injecting that after constructor. ◦ Typically we advice that you let the SDK do the fetching itself as it handles caching for you. 
gb.init()
kicks off fetching the SDK payload or pulling it from SDK cache. • You're calling 
gb.setFeatures(json.features)
which isn't really the proper way of hydrating your SDK. ◦ Ideally use 
gb.init()
as setFeatures() is deprecated. ◦ If you must do your own SDK payload hydration, use 
gb.init({ payload: json })
(where 
json
is the manually fetched SDK payload). • For a bit more debugging info you can use 
debug: true
in the constructor (or just set 
gb.debug = true
after construction). That said, I tried to mimic your set up and still am observing correct sticky bucket behavior. Maybe try double checking your implementation based on the above suggestions, and if not send me a message and we can try to debug a bit more.
a
Thanks Bryce I'll update our implementation to reflect your feedback and let you know if I'm still seeing issues.
195 Views
Open in Slack
PreviousNext
Powered by

GrowthBook Users

Open source platform for stress free deployments, measured impact, and smarter decisions.

Powered by