Prebid Server generated bidId

[bretg]

Followup to #1015

An assumption of the video/amp/sdk event tracking feature was that bidders generated reasonably unique IDs for each seatbid[].bid[].id. We've discovered that assumption to be false: bidders are all over the map with regards to that ID:

• some treat is as an incremental bid ID like 1,2,3,...
• some copy the request.id for each seatbid.bid
• some generate it uniquely

To be useful for joining truncated events back to the auction ID, we need to make sure that bidIds are unique, and it's become clear that bidder adapters aren't aligned with that goal.

The proposal to address this:

• Prebid Server gains a configuration that will cause it to generate a unique UUID for each successful bid and place it in seatbid[].bid[].ext.prebid.bidid.
• When creating event URLs, use this generated bidid instead of the bidder-created id
• PBJS would also be modified to look for seatbid[].bid[].ext.prebid.bidid and place it in the javascript bidResponse object for use in analytics adapters.
• The bidder-supplied bidid will be sent through as normal for those bidders who can use it to join back to their server logs.

[SyntaxNode]

I don't have an objection, just some follow-up questions:

An assumption of the video/amp/sdk event tracking feature

Would this apply to all bid requests or be restricted to the video/amp/sdk requests?

The bidder-supplied bidid will be sent through as normal for those bidders who can use it to join back to their server logs.

To be clear, this is stating the existing bidid will still flow through the system as it does today and PBS will only place its generated uuid in extension object?

[bretg]

Discussed in the Prebid Server meeting. Bryan brought up the interesting idea of using cache ID instead creating a new ID. We discussed this afterwards and while the idea has solid merit, it ties two concepts together that are not necessarily tied: bids aren’t always cached, and it could be confusing to have a fake cacheId in a scenario where we only needed the ID to be a bid.

Would this apply to all bid requests or be restricted to the video/amp/sdk requests?

Seems easier to just apply it to all bid requests, right? Prebid.js doesn't have to use it.

this is stating the existing bidid will still flow through the system as it does today and PBS will only place its generated uuid in extension object?

Right.

[laurb9]

Overwriting bid.id could be controlled by an adapter flag instead of an application-wide one, since this is a bidder issue.
Bidders that are known (or declared) to return unique bid ids can keep some trace continuity through PBS this way.

[bretg]

The implementation in PBS-Java is to (optionally) add a totally separate bidid (seatbid.bid.ext.prebid.bidid) that is then used as the bidid for events purposes. Traceability to bidder-specified bidids is still available in seatbid.bid.id.

Notes:

• Since 3.23, the pbsBidAdapter in Prebid.js copies seatbid.bid.ext.prebid.bidid to a place in the javascript bid response object so client-side analytics adapters can do the right thing
• Usage of the bidder-specific bid id would depend on server- and client-side analytics adapters logging them.

[ShriprasadM]

Are updates on this?

[SyntaxNode]

@ShriprasadM I've increased it's priority within the Xandr dev team. @VeronikaSolovei9 will be working on it soon.

[ShriprasadM]

Thanks @SyntaxNode for an update

[VeronikaSolovei9]

PR: #1772

[SyntaxNode]

Implemented in PBS-Go 0.155.0.