Different Top Level Request ID Per Bidder

[SyntaxNode]

Background

Prebid Server requires every request to include a top level id since this field is marked as required in the IAB documentation. This id is then forwarded to bidders. However, this may be going against the intended use.

The description of this field is:

Unique ID of the bid request, provided by the exchange.

Sending the same id to multiple bidders can be viewed as in violation of the "unique id" description. Instead of acting as an ephemeral identifier for debugging purposes, the propagation of the id may be more akin to a transaction id. As such, the Publisher Committee is considering it in scope of privacy regulations (see #2727).

Solution 1

As proposed in #2727, we may need to remove this field during enforcement of the "suppressUniqueRequestIds" activity.

Solution 2

Generate new random ids for each bidder such this value cannot be traced back to the original request, thus eliminating the risk of acting as a trackable transaction id.

[patmmccann]

I don't think solution 1 can work since this is a required field for a valid request

Potential partial solution 3: pbjs uses https://github.com/prebid/Prebid.js/blob/be23ae2d8bbed1017007ea2d044801ce50507a13/src/adapterManager.js#L269 to generate a unique string for each bidder already; perhaps pbs adapter for pbjs communicates it better? If so PBS may only need to calculate new id's when it doesn't have them available.

[patmmccann]

Solution 4: append a string (eg '1', '2', '3') to $.id we have now, then hash it, resulting in a different value for each bidder but no random number generation

[bretg]

Discussed in committee. We're good with PBS scenarios for the top level $.id:

• PBJS: pbsBidAdapter will send random $.id. PBS doesn't need to do anything.
• SDK: top-level Stored Request (ext.prebid.storedrequest) triggers the generation of $.id. (assuming the config flag is enabled)
• AMP: AMP Stored Request triggers the generation of $.id. (assuming the config flag is enabled)

@patmmccann - we'd rather not do a custom $.id to each bidder if we don't have to. Has this been directly requested by the pub committee?

[bretg]

Further discussion:

• ORTB spec says response $.id needs to match the request $.id.
• But this doesn't mean that PBS can't generate new $.id for outbound requests to adapters. We should confirm that PBS doesn't utilize $.id to map bidder responses back to the originating auction in a way that would break if we changed the auction $.id.
• Analytics adapters could be spared from this complexity -- they will see the $.id that came in on the request and not the temporary $.id sent to bidders.

We should tie this to the transmitTid activity. If that activity is suppressed, then generate random $.id before sending to bid adapters. No need to do this for modules or analytics adapters.

[bretg]

This can be done separately from the transmitTid issue #2727

[bretg]

Discussed in committee.

It's not clear whether tying this to transmitTids is the right approach. We may just change the behavior globally and have a host-level config to back out just in case there's unintended side effects.

[SyntaxNode]

Discussed with the IAB.

There is no requirement for the $.id to be globally unique. Several other Ad Tech companies shared that they use a different id per recipient when fanning out requests. There's no reason PBS can't do something similar.

We should confirm that PBS doesn't utilize $.id to map bidder responses back to the originating auction in a way that would break if we changed the auction $.id.

Found nothing concerning in PBS-Go.

Analytics adapters could be spared from this complexity -- they will see the $.id that came in on the request and not the temporary $.id sent to bidders.

Agreed.

We should tie this to the transmitTid activity. If that activity is suppressed, then generate random $.id before sending to bid adapters. No need to do this for modules or analytics adapters.

Discussed. Will keep this behavior separate from the transmitTid activity.

[bretg]

Trying to push this over the finish line...

change the behavior globally and have a host-level config to back out just in case there's unintended side effects

We already defined a generate-storedrequest-bidrequest-id config setting, but now the enhancement is that each bidder gets a different top-level ID by default unless a new config value says not to. For that, the proposal is to define a new related config generate-bidrequest-id-by-bidder. If true, each bidder gets a different value for .id. If false, all bidders get the same value.

These are the definitions from #2381 modified to account for generate-bidrequest-id-by-bidder

$.id

// existing logic
if host config generate-storedrequest-bidrequest-id config is true
    if $.id is not set, generate a random value
    if the storedrequest is from AMP or from a top-level stored request (ext.prebid.storedrequest), then replace any existing $.id with a random value
if $.id contains "{{UUID}}", replace that macro with a random value

// new logic
if config generate-bidrequest-id-by-bidder is true (or empty or null), $.id must be different for each bidder. Generate a random UUID for `.id` before sending to each bidder. Analytics adapters get original `.id`. Modules receive the original `.id` for most stages, but the bidder-specific `.id` for the bidder-request and bidder-response stages.

$.imp[].id - no change. Prebid.js depends on imp.id being the adunit code. It's not unique enough for bidders to link to other requests inappropriately.

if host config generate-storedrequest-bidrequest-id config is true
    if any $.imp[].id is missing, set it to a random 16-digit string.
    if the storedrequest is from AMP **or** from a top-level stored request (ext.prebid.storedrequest), confirm that all $.imp[].id fields in the request are different. If not different, re-number them all starting from "1".