Getting alias bidder name in the bid.ext.prebid.meta.adaptercode instead of corebidder

[Pubmatic-Supriya-Patil]

As a part of PR(#3100),

        if bidResponse.Bids[i].BidMeta == nil {
	    bidResponse.Bids[i].BidMeta = &openrtb_ext.ExtBidPrebidMeta{}
	}
	bidResponse.Bids[i].BidMeta.AdapterCode = bidderRequest.BidderName.String() 

code is removed and added

        if prebid.Meta == nil {
		prebid.Meta = &openrtb_ext.ExtBidPrebidMeta{}
	}
	prebid.Meta.AdapterCode = adapter.String()

With this change, there is change in bid response where adaptercode is expected as corebidder but from response we are getting aliase bidder name which is not expected.

Example: Suppose pubmatic is the core bidder and pubmatic-1 is aliase bidder so in the bidresponse we should get pubmatic as a adapter code but we are getting pubmatic-1 as a adapter code.

Another point is that with this PR, adapter name is only set in case of seatbid so not sure this is expected or not.

[bretg]

@Pubmatic-Supriya-Patil - the original issue in question is #2174 -- here's where we defined:

We extend the metadata object to include an adaptercode field, but have PBS-core fill it rather than relying on the adapter. PBS-core fills seatbid.bid.ext.prebid.meta.adaptercode with the biddercode as defined in imp[].ext.prebid.bidder.BIDDERCODE. Even if it's an alias, that's fine.

So I'm against changing this without a deeper understanding of why it's causing you a problem? What piece of code upstream is "not expecting" the aliased biddercode?

[pm-nilesh-chate]

@bretg Wasn't the initial intention of the adaptercode to discern which bidder produced the bid response? With the introduction of alternatebiddercodes, there's a possibility of receiving bids from a bidder lacking adapter integration in PBS. For instance, the PubMatic adapter might present bids from the GroupM bidder, and initially, using meta.adaptercode=pubmatic provided a straightforward means to identify which adapter/bidder generated a specific bid. However, due to the recent modification, GroupM bids now carry meta.adaptercode=groupm, suggesting that the GroupM adapter was responsible for these bids. This seems incorrect to me.

[bretg]

What you're saying makes sense, but it's an important change to something that was discussed and approved by the committee a year ago. We will have to go back to the committee to discuss and approve the change.

Here's the proposed new wording:

We extend the metadata object to include an adaptercode field, but have PBS-core fill it rather than relying on the adapter. PBS-core fills seatbid.bid.ext.prebid.meta.adaptercode with the base adapter code, not any aliases. The biddercode for the entity actually bidding should be in seatbid.seat. For example, seatbid.bid.ext.prebid.meta.adaptercode might be "pubmatic" while seatbid.seat is "groupm".

Sound ok?

[pm-nilesh-chate]

sounds good to me

[bretg]

Discussed in committee. We need to define the use cases and expected results.

@patmmccann pointed out that there's an additional related field, which is seatbid.bid.ext.prebid.meta.demandSource. It's not clear to me that this field is useful in a Prebid Server context because I think it should always be the same as the ORTB seatbid.seat, right?

Here's a cut at the use cases:

1. bidder params call for pubmatic, the account allows "alternate bidder codes", and the adapter returns with "groupm".

   • seatbid.seat should be "groupm"
   • seatbid.bid.ext.prebid.meta.adapterCode "pubmatic"
   • seatbid.bid.ext.prebid.meta.demandSource should be "groupm"

2. bidder params call for pubmatic, the account doesn't allow "alternate bidder codes", and the adapter returns with "groupm".

   • bid is rejected

3. bidder params call for pubm_ss, pubm_ss is aliased to pubmatic, the account allows "alternate bidder codes", and the adapter returns with "groupm".

   • seatbid.seat should be "groupm"
   • seatbid.bid.ext.prebid.meta.adapterCode "pubmatic" // right now this is set to pubm_ss. It would be a change.
   • seatbid.bid.ext.prebid.meta.demandSource should be "groupm"

Pubmatic team -- if we need both the base biddercode and the aliased biddercode, please help us understand why.

[Pubmatic-Supriya-Patil]

Current behaviour:

Prebid Version	AdapterCode	Seat
0.275.0	pubmatic	groupm
v2.1.0	groupm	groupm

Expected behaviour:

Prebid Version	AdapterCode	Seat
0.275.0	pubmatic	groupm
v2.1.0	pubmatic	groupm

Current behaviour (alias):

Prebid Version	AdapterCode	Seat
0.275.0	pubmatic-2	groupm
v2.1.0	groupm	groupm

Expected behaviour (alias):

Prebid Version	AdapterCode	Seat
0.275.0	pubmatic-2	groupm
v2.1.0	pubmatic-2	groupm

Suggested change (alias) - @bretg

Prebid Version	AdapterCode	Seat
0.275.0	pubmatic-2	groupm
v2.1.0	pubmatic	groupm

For Alias, we're ok with the orginal behaviour (<v0.275.0) as well as the one suggested by Bret but for non-alias, adapterCode should be pubmatic and not groupm since groupm adapter does not exist in PBS. We use all these data for reporting purposes.

[bretg]

Discussed in committee.

This topic has gotten complicated with various features:

• soft aliases vs hard aliases
• bidder case insensitivity (Bidder names should be case insensitive #2400)
• alternate biddercodes (Conventions and controls for adapters responding with multiple biddercodes #2174)
• generic bid adapter
• DemandSource - Note that DemandSource and alternateBidderCodes are basically different ways of doing the same thing - bid adapters supplying demand from a different business unit.

Here are the definitions and source for each field:

• adapterCode - this is always the actual (or hard alias) bid adapter code.
• seat - this is normally what's in the imp[].ext.prebid.bidder.BIDDER field, but can be set by the adapter if thealternateBidderCode feature allows it to be something else.
• meta.DemandSource - purely determined by the bid adapter and not utilized or recognized by Prebid Server or Prebid.js.
• hb_bidder value (and the hb_bidder_X attribute)

Here's a table that outlines all the combinations.

Scenario	adapterCode	seat	hb_bidder value	meta.DemandSource
baseline adapter=bidderA no aliases reqBidder=bidderA no demandSource	bidderA	bidderA	bidderA	n/a
demand source adapter=bidderA no aliases reqBidder=bidderA demandSource=altBidder	bidderA	bidderA	bidderA	altBidder
case only adapter=bidderA no aliases reqBidder=BIDDERA no demandSource	bidderA	bidderA	BIDDERA	n/a
soft alias adapter=bidderA soft alias ba=bidderA reqBidder=ba no demandSource	bidderA	ba	ba	n/a
soft alias+case(*) adapter=bidderA soft alias ba=bidderA reqBidder=BA no demandSource	bidderA	BA	BA	n/a
hard alias (not generic) adapter=bidderA hard alias ba=bidderA reqBidder=ba no demandSource	bidderA	ba	ba	n/a
hard alias with DemandSource adapter=bidderA hard alias ba=bidderA reqBidder=ba DemandSource=altBidder	bidderA	ba	ba	altBidder
hard alias (generic) adapter=generic hard alias ba=bidderA reqBidder=ba no demandSource	ba	ba	ba	n/a
alt bidder adapter=bidderA no aliases reqBidder=bidderA no demandSource alt codes allowed	bidderA	bidderX	bidderX	n/a
alt bidder+case adapter=bidderA no aliases reqBidder=BIDDERA no demandSource alt codes allowed	bidderA	bidderX	bidderX	n/a
alt bidder+soft alias adapter=bidderA soft alias ba=bidderA reqBidder=ba no demandSource alt codes allowed	bidderA	bidderX	bidderX	n/a
alt bidder+hard alias adapter=generic hard alias g1=generic reqBidder=g1 no demandSource alt codes allowed	g1	bidderX	bidderX	n/a
alt bidder+case+soft alias adapter=bidderA soft alias ba=bidderA reqBidder=BA no demandSource alt codes allowed	bidderA	bidderX	bidderX	n/a

(*) Found that aliases are not case insensitive in PBS-Java, at least when using storedresponses.

[bretg]

Updated the table to include DemandSource.

[bsardo]

👍 I agree with the table presented above by @bretg. @Pubmatic-Supriya-Patil, in that case, because PBS-Go does not currently have a generic adapter, PBS-Go will always set AdapterCode to the adapter as opposed to a soft or hard alias or an alternate bidder code.

[bsardo]

PBS-Go is now correctly setting the adaptercode for all scenarios except for the hard alias case. In that scenario adaptercode is currently set to the hard alias just like the seat. PBS-Go will address this in a separate PR in the near future.