This message was deleted.
# experimentation
w
This message was deleted.
r
or more like 10-15%
is that just due to people's cookie blocking settings and we just ahve to deal with it?
seems like its because sticky bucketing created two separate keys
gbStickyBuckets__id||[id] (one using the fallback attribute and one using the main id attribute)
h
When working correctly, sticky buckets should automatically upgrade the identifier attribute from fallback to primary, and you'd still see both keys in the bucket docs. So for a user who started as anonymous and then logged in, you should see both of these:
Copy code
gbStickyBuckets__anonId||[anonId]
gbStickyBuckets__id||[id]
... and for the experiment(s) in question, they should show the same bucket value in both docs. From the user perspective, they should just use the highest priority sticky bucket doc matching their attributes and not both. Are you able to recreate any of the dropoff / variation hopping when testing locally? You can use our DevTools chrome/firefox extension to make the debugging here a bit easier.
r
i think the issue was that we had defaulted
id
to
anonId
when user wasn't logged in, but that meant that the
id
value was changing after login rather than falling back to anonId when logged out. i am trying to see if changing to record a new
userId
attribute will work which is allowed to be empty (as id is not allowed empty)
148 Views