usersync_if_ambiguous -> default_value. require default_value to be configured by host.

[Jobeso]

Hey Prebid Team,
I updated our self hosted prebid-server from 0.138.0 to 0.153.0. Since that change I see an impression drop of 80%. Rolling back this update seems to be a temporary fix.

The drop is not os related and is an issue on iOS and Android. Also, it's not EEA related, also happens for countries outside of the EU. All bidders are effected except for OpenX.

I checked the changelogs between the versions but didn't see any breaking changes. Did I miss anything there? How would you approach debugging this?

Thanks in advance for your help.

[SyntaxNode]

HI @Jobeso,

That's no good. We didn't intend to introduce a breaking change, but it seems something slipped by us. Sorry for that. Let's figure it out and fix it.

These sort of issues are almost always related to privacy policies. We tweaked some of the GDPR settings at the start of the year to better align with the specs. I suspect one of these changes had unintended side affects.

To start, what are your GDPR settings? Specifically: gdpr.enabled, gdpr.host_vendor_id, and gdpr.usersync_if_ambiguous.

[Jobeso]

Hey @SyntaxNode,
thanks for the quick answer. I suspect that whatever is breaking might only be for our setup so I suppose rather a mistake from our side.

We run a rather basic setup with no huge modifications of the default values. This is true for your above mentioned flags as well, we do not set them explicitly, default values seem to be the following and they did not change from 0.138.0 to 0.153.0.

gdpr.enabled: true
gdpr.host_vendor_id: 0
gdpr.usersync_if_ambiguous: false

It's a bit hard for me to find documentation on these to understand what's missing from our end. I found your comment and this discussion that explains this kinda but I'm still struggling with understanding what we should change here.

With our prebid-server we only enable bidding for our own app (iOS & Android). We gather the consent with a cmp and the consent string is automatically added with prebid-mobile to the requests.

I really appreciate the work you and your team are doing and thanks for your help with this issue.

[SyntaxNode]

Thank you sharing your GDPR configuration. I've identified the issue as an unintended side effect of this change.

Prior to this change, Prebid Server would not enforce GDPR if the host vendor id was left at the default 0 value. If that's the functionality you want, the modern equivalent is setting gdpr.enabled to false (the default is true). I suspect this was the result of an over emphasis on the cookie syncing aspect of GDPR regulations. We've been focusing this year on correcting those missteps.

So, what does this have to do with requests which don't include GDPR information? There is another setting gdpr.usersync_if_ambiguous which defaults to false. The name is absolutely misleading and it's on our list to fix (or we always welcome community PRs). When left at the default value of false, Prebid Server will assume regs.ext.gdpr = 1 if the regs.ext.gdpr field is omitted on the bid request. This feature was intended for European data centers during the initial rollout of GDPR before we added geo fenced behavior.

If you want to enforce GDPR when its present on the request (and only then), set gdpr.usersync_if_ambiguous to true.

Based on this issue, we clearly don't have the default settings correct. I propose we leave gdpr.enabled set to true and flip the gdpr.usersync_if_ambiguous default. Thoughts?

[SyntaxNode]

It's a bit hard for me to find documentation on these to understand what's missing from our end.

Agreed. There is very little documentation currently on configuration settings, and even then they're buried in code. I intend to fix this when the team has bandwidth. Right now we're focusing on feature catch up.

I really appreciate the work you and your team are doing and thanks for your help with this issue.

Thank you for the support. Sorry for the impact this change had on your servers.

[bretg]

We met in committee on Friday and agreed to move forward with these related changes:

1. drop usersync_if_ambiguous in favor of gdpr.default-value
2. Make gdpr.default-value a required config value - instead of having an overall default, host companies will need to explicitly choose a value.

[SyntaxNode]

Implemented in PBS-Go 0.164.0.

Starting with this release, usersync_if_ambiguous is replaced with default_value and requires a host (or dev) provided value for PBS to start.

[bretg]

PBS-Java never supported the usersync_if_ambiguous flag, and already supported/documented default_value. Closing this issue.

[SyntaxNode]

We met in committee on Friday and agreed to move forward with these related changes:

1. drop usersync_if_ambiguous in favor of gdpr.default-value
2. Make gdpr.default-value a required config value - instead of having an overall default, host companies will need to explicitly choose a value.

This issue was kept open and tagged with PBS-Java to address item 2 of your notes from April 19, quoted above.

[bretg]

PBS-Java 1.71 requires gdpr.default-value