Hey, all. I searched through the questions here, but couldn't find an answer exactly pertinent to my situation. I'm implementing sticky bucketing through the JS SDK. I've followed all the steps and my localStorage is successfully saving/retrieving the data; however, it seems like I either don't understand the fallback attribute or it's not working as expected. I created an experiment with these settings:

{
  "changeId": "33ebe0084e37e6d4ebc64a320b2f00510291115ec92178e81b61125a1bd40b83",
  "status": "running",
  "hashVersion": 2,
  "hashAttribute": "customerNumber",
  "urlPatterns": [
    {
      "include": true,
      "type": "simple",
      "pattern": "<http://localhost:4200/home>"
    }
  ],
  "meta": [
    {
      "key": "0",
      "name": "Control"
    },
    {
      "key": "1",
      "name": "Variation 1"
    },
    {
      "key": "2",
      "name": "Variation 2"
    },
    {
      "key": "3",
      "name": "Variation 3"
    },
    {
      "key": "4",
      "name": "Variation 4"
    },
    {
      "key": "5",
      "name": "Variation 5"
    }
  ],
  "filters": [],
  "seed": "sticky_test4",
  "name": "sticky_test4",
  "phase": "0",
  "coverage": 1
}

customerNumber

is my logged-in id, so it won't always be present in my user attributes. I also have an anonymous id (

anonId

) that always appears in the user attributes and is being used as my fallback attribute. My understanding is that if

customerNumber

isn't present (aka the user is logged out), my

anonId

will then be used to evaluate the experiment; however, I'm getting this error message in my Debug Log: > > Skip because missing hashAttribute After reading the docs, my expectation is that the fallback attribute would take the place of the hash attribute and I shouldn't get this error. Something else to note is that if I create an experiment using the

anonId

as the primary attribute instead of the

customerNumber

, the experiment works fine, so it's not an issue with setting the user attributes incorrectly. Any help would be appreciated because I can't find any information about this error or that the fallback can't be used as a hash attribute.

Does your experiment have a

fallbackAttribute

defined anywhere? I'm not seeing it in the definition you pasted above

I definitely selected the

fallbackAttribute

when setting up the experiment. I had a coworker sanity check me while I did it. At one point,

fallbackAttribute: ''

showed up in the settings, but then it went away shortly after. It seems buggy and random if it shows up and I've never had it show up similar to the

hashAttribute

where it should be

fallbackAttribute: 'anonId'

ok. sounds like there could possibly be a regression or a conflict which is clearing your fallback attribute. We'll follow up and get this sorted out

let me know if you'd rather i start a new thread but i just joined to ask a similar question about sticky bucketing... spent most of yesterday trying to figure it out and failing. but on latest react sdk it seems to me like sticky bucketing is broken... (both local storage and browser cookie) what i'm seeing: • have anonymousId as primary targeting attribute. userId as fallback. • If no userId is present the anonymous id is used correctly and an entry to local storage or cookie is written. • As soon as I log in and the userId attribute is also present, it seems non deterministic which attribute will get used. • I can see cookies stored for both userid and anonymous id (in the browser cookie case) that have different variation values • If I refresh the page a few times I can see track events come through with either variation. I think that since the track events are getting sent at all the configuration is fully loaded and since both cookies are present I should deterministically see whichever cookie was created first. Anyway, I'm curious if there were any findings as part of this thread as it sounds possibly like a similar case. Before I dive further at least or email support.

hi @powerful-journalist-78283, can you also confirm whether your experiment definition (in your payload) has a

fallbackAttribute

defined?

yeah. from the devtools:

@powerful-journalist-78283 wondering how you are loading the GB SDK. Is it manually imported into a bundle, included via script tag, etc?

just pulled in via npm. using the react sdk with next.js

can I ask how you're invoking/creating the sticky bucket service? There's a small bug in the React SDK now that doesn't export the service correctly

i can see the cookies for sure

do you import

BrowserCookieStickyBucketService

from

@growthbook/growthbook

?

yes to first and yes to client component

how many assignment docs do you have in your cookies?

image.png

and as far as you can tell, is it random which of these 2 cookie docs actually end up inside your SDK?

the non fallback key (anonymous_id) in my case seems to generally be the winner...

I wonder if you get the same behavior using LocalStorage. Wondering if its a cookie thing or a general bug

i played around with local storage yesterday as well and behavior seemed the same. i can test some more on monday probably

can you tell me whether both the hashAttribute and fallbackAttribute are present in the current SDK (user) attributes?

image.png

yep, that would definitely explain it. the SDK filters SB assignment docs that are potential matches during constructor, so if you're missing an attribute at that point it will never pick it up. This is "by design", but I think we could relax these constraints and pick up new docs when attributes change.

Sounds like it. We set our anonymous id right at the beginning synchronously and then when the user logs in, use

setAttributes

to set the customerNumber.

Thanks for confirming. FYI, here is the PR I'm working on to address this and other related concerns. Shouldn't be too much longer before we can ship the fix: https://github.com/growthbook/growthbook/pull/2770

Excellent! Would you still recommend recreating the SDK?

depends on how urgently you need this fixed I suppose. It will probably be a few days, possibly up to a week before the SDK PR is live

Sounds good. Thanks, Bryce!

@happy-autumn-40938 does the fix apply to the JS SDK as well?

yes: JS, React, and HTML Script tag

@happy-autumn-40938 any idea when this might go live?

probably next week. sorry about the delay

@happy-autumn-40938 thanks for doing that! I see that the changes got merged. How long does a release generally take to go out once it's merged?

We have yet to publish the SDKs to NPM, which is when the SDKs officially become available. Meanwhile, we are testing their functionality sandboxed in the GB app (hence the merge to main). Assuming no obvious regressions, we'd likely widely release the SDK changes on Monday