Transparent adapter and alias codes in auctionEnd events

[patmmccann]

Type of issue

Feature request

Description

Third party entities using the prebid public apis eg browser extensions, publisher analytics tools, debuggers, web scrapers, and rendering libraries may often wish to know all three of the response bidder code, the adapter code, and the adapter code the adapter was aliased from. We should provide a way for these other entities to delineate all three in the auctionEnd event. One possibility is to put them in a vector where bidderCode would be of length one for normal requests, but up to length 3. Another possiblity is to bidderCode, adapterCode, origAdapterCode places in object structure.

One alternative is we could make adapterRegistry accessible via api?

related

#8129

[patmmccann]

Perhaps this could be of length 4 if the publisher aliases a known alias, eg suppose bidder code in the response is 'someentity' which is an alternative bidder code for 'tx' which is a configured alias of 'trustx' which is a known alias of 'grid' ? If so, the vector of codes approach seems preferable to the named slot 'original_original_code'

[dgirardi]

I'm curious about why / how this would with auctionEnd? those three are properties of each bid - and adapterCode is already available. Only the alias resolution is missing.

Currently it's possible to do

pbjs.onEvent('bidResponse', (bid) => {
   const {bidderCode, adapterCode} = bid;
})
pbjs.onEvent('auctionEnd', (auction) => {
   auction.bidsReceived.map(({bidderCode, adapterCode}) => ...)
   auction.winningBids.map(({bidderCode, adapterCode}) => ...)
})

is this about adding the alias resolution, or changing the arguments to the auctionEnd event?

[patmmccann]

This is about adding the alias resolution, correct

[patmmccann]

On further inspection, analytics adapters already have this info, eg

Prebid.js/modules/pubmaticAnalyticsAdapter.js

Line 201 in 6f4fb5b

function getAdapterNameForAlias(aliasName) {

[patmmccann]

result of committee discussion is we plan to make adapterRegistry accessible via api; allow publishers to suppress this public api via configuration

[jlquaccia]

Hey @patmmccann, I was thinking of taking this gh issue on next. To clarify, it sounds like the req's for this ticket would be something like the following (let me know if im off, which i might be):

• create an adapterRegistry (just like bidderRegistry & aliasRegistry here: https://github.com/prebid/Prebid.js/blob/master/src/adapterManager.js#L47)
• as the pbjs init logic runs, keep track of/populate the adapterRegistry obj like so.. { adapter1: { bidderCode, adapterCode, alias }, adapter2: { bidderCode, adapterCode, alias } }
• create a global config option to enable/disable the adapterRegistry feature. ex: pbjs.setConfig({ adapterRegistry: true })
• if adapterRegistry is set to true, then allow this info to be available within the getProperties func during the auctionEnd event (https://github.com/prebid/Prebid.js/blob/master/src/auction.js#L159)

[patmmccann]

@jlquaccia I think it is much simpler than that; I think we might just need to make the existing aliasRegistry public? The auctionEnd event seemed to be an alternative to it being public and committee discussion seemed to favor not messing with auctionEnd.

[patmmccann]

Very excited you might take this one on, thanks!

[jlquaccia]

@patmmccann ah, ok gotcha, that does sounds a bit more simple! Will create a new PR shortly around this one.