Hey Team! Question about BrowserCookieStickyBucket...
# ask-questionsm
most-iron-81885
09/26/2024, 10:29 AMHey Team! Question about BrowserCookieStickyBucketService. Should the fallback id and sticky bucket cookies be set to never expiry? On default they are session persistent.
h
happy-autumn-40938
09/26/2024, 11:42 PMGreat question, this is something we could provide better examples for. You should set the expiry long enough to conclude your experiment with buffer. Typically over a month. Something like this would be prudent:
Copy code
new BrowserCookieStickyBucketService({
jsCookie,
cookieAttributes: { expires: 90 }, // 90 days
})m
most-iron-81885
09/27/2024, 8:18 AM@happy-autumn-40938 thanks for confirming!
most-iron-81885
09/30/2024, 7:02 AM@happy-autumn-40938 extra question for you here. I have a situation where users can log in and have unique id attached to them. In case of inactivity they will get logged out. From your perspective would it be good to save their authenticated user id once they log in to a long expiry cookie and then use that instead of fallback id when they come to the site next time? I'd imagine the only rare edge case is when another user uses the same device and logs in to a different account, but in such case the cookie would be overwritten with the new auth id.
h
happy-autumn-40938
09/30/2024, 5:46 PMWe're really talking about session management at this point, and there are many ways to skin the cat. In terms of how we intend hash and fallback attributes to work for registered users: usually the hash attribute is a permanent user id, and the fallback attribute is a short-lived session uuid. Usually its best to forget that the user exists (from a cookie perspective) once they log out. If you are worried about double bucketing and generally you're looking at 1 user per device, then you could set the session cookie to be longer lived.
👍 1
41 Views