LocalStorage Problem with ID hashes

[mikemangas]

Problem:

Since the release of Prebid.js Pull Request #13556
(Version 10.3.0), we have observed an issue affecting both CriteoId and ID5.
This issue has led to a measurable decline in revenue.

Specifically, the ID5 API is being called even when an ID is already available in localStorage and has not expired. This behavior did not occur in versions prior to Prebid 10.3.0, where ID generation was functioning as expected.

[dgirardi]

Could you share your userId configuration, or link to a page with the issue?

[mikemangas]

Before Testing you need to do 3 Steps:
0) (Disable Adblocker if turned on :-))

1. Visit https://web.de and click on Accept at the permission banner.
2. Login with following credentials:
   mail: ****
   pass: *****
3. After logging in, Logout

Then try those 3 TestUrls:

A) Compare this (bad behaviour):
https://web.de/?prebidversion=57&pbjs_debug=true (Prebid Version: 10.10.0)

B) vs this (good behaviour):
https://web.de/?prebidversion=58&pbjs_debug=true (Prebid Version: 10.2.0)

C) vs this (good behaviour:
https://web.de/?prebidversion=55&pbjs_debug=true (Prebid Version: 9.50.0)

If you are done with testing, i will remove the test-user credentials from here.

[dgirardi]

I have found a issue but I should confirm it's the one you see as well.

I see no difference between "good" and "bad" versions, both load the cached ID, e.g.

However, when you switch between versions all IDs will be refreshed. I think this is what logging in and out does, on the second page load it behaves normally for me (loading the cached ID).

This is because 10.3.0 included #13490 which (unfortunately) changed how the consent hash is calculated, so when comparing with one from the other version Prebid thinks consent data changed and forces a userId refresh.

Does this sound like your issue?

I'm thinking we should undo that change, but that would fix the issue for you only if you avoid using any of the versions between 10.3 and the one containing the fix.

[patmmccann]

This issue has led to a measurable decline in revenue.

It seems instead of revenue being worse in the new version, there is a bit of transition pain to the simplified consent hash. Do you want to test keeping return btoa(bytes.join()); and see if that resolves? What do you thin k we should do? A revert would cause transition pain the other direction

[mikemangas]

From my understanding, most publishers worldwide are still using Prebid 9.x.x rather than 10.x.x. Within our publisher network in Germany, many are hesitant to upgrade to Prebid 10 due to challenges like this issue.

In our opinion, reverting the change would be the best approach. We conducted a test over a two-week period, and the results showed a significant revenue decline in the test group. This "transition pain" would be quite huge, if we would decide to fully rollout.

[dgirardi]

Is that a confirmation that this is your issue? as in, you only see this problem if you take some action to switch versions, as in logging in from a page without the prebidversion parameter? If so you can remove the login info.

[mikemangas]

Yes, this is confirmed.
The issue occurs when switching between Prebid versions 10.2.0 (or earlier) and 10.10.0.

[patmmccann]

@mikemangas would a option to set this string return btoa(bytes.join(''));

to
',' instead of '' work for you?

we could call it consentHashJoinString and you could set it to , to keep the behvaior in 9 or empty string to get the more compact storage and no one would need to incur transition pain involuntarily