Deals are not working as expected in case of aliased bidder

[Pubmatic-Supriya-Patil]

As a part of PR(#3218), new function call NormalizeBidderName is made before calling updateHbPbCatDur (pwtpb_cat_dur) and inside ReadDealTiersFromImp. In case of aliase bidder, its not working as expected. In the bid response from bidder, winning bids contains bidder name as aliase bidder and we are comparing it with core bidder name.So if the bidder is not present in core bidder name list then function is returning from that place without processing anything.

[gargcreation1992]

@Pubmatic-Supriya-Patil Requesting you to please share the sample request and response, highlighting the expected behaviour if possible.

[Pubmatic-Supriya-Patil]

As per my observation "pwtpb_cat_dur": "apnx6_50s" is the expected in the bid response under targtting but I am getting "pwtpb_cat_dur": "9.00_50s" . Bid category is not getting updated with bidder code because that aliase bidder is not in the list of corebidder.
Please refer below code where bidderFound is returning false so its not updating category with bidder name.

`func applyDealSupport(bidRequest *openrtb2.BidRequest, auc *auction, bidCategory map[string]string, multiBid map[string]openrtb_ext.ExtMultiBid) []error {
errs := []error{}
impDealMap := getDealTiers(bidRequest)

for impID, topBidsPerImp := range auc.winningBidsByBidder {
	impDeal := impDealMap[impID]
	for bidder, topBidsPerBidder := range topBidsPerImp {
		bidderNormalized, bidderFound := openrtb_ext.NormalizeBidderName(bidder.String())
		if !bidderFound {
			continue
		}
		maxBid := bidsToUpdate(multiBid, bidderNormalized.String())
		for i, topBid := range topBidsPerBidder {
			if i == maxBid {
				break
			}
			if topBid.DealPriority > 0 {
				if validateDealTier(impDeal[bidderNormalized]) {
					updateHbPbCatDur(topBid, impDeal[bidderNormalized], bidCategory)
				} else {
					errs = append(errs, fmt.Errorf("dealTier configuration invalid for bidder '%s', imp ID '%s'", string(bidder), impID))
				}
			}
		}
	}
}

return errs

}
`

[gargcreation1992]

@Pubmatic-Supriya-Patil openrtb_ext.NormalisedBidderName function loops through coreBidderNames. It may seem looking at the code that aliased bidders are not being set in coreBidderNames as it is not being set explicitly.
However, Aliased bidders are being set in the coreBidderNames on server startup when we load BidderInfos. So, the issue that you have mentioned may be unlikely due to call to NormalisedBidderName because aliased bidder names are being returned. Therefore requesting you to provide sample request and response.

[Pubmatic-Supriya-Patil]

Please refer this request.
Request.json

[pm-nilesh-chate]

@gargcreation1992 I don't think you statement holds true for soft aliases. Did we drop support for soft aliases?, If not, we would need to fix this issue

[bretg]

The video endpoint is deprecated. If you guys want to open a PR to fix an issue, fine, but the committee will not prioritize any work on this when the goal is to implement podding/etc in the main auction endpoint.

[bretg]

Discussed in committee. This is larger than the video endpoint. We agreed that the way this should look in targeting is:

• hb_bidder=ALIASCODEINORIGINALCASE
• hb_bidder_ALIASCODEINORIGINALCASE=ALIASCODEINORIGINALCASE
• hb_deal_ALIASCODEINORIGINALCASE=123

[bsardo]

It appears as though the targeting casing has always used the original casing specified in the request for core bidders and soft aliases so I don't see a problem there. However, a bug was introduced in v2.1.0 preventing deals from being applied to soft aliases.

Prior to the PBS-Go v2.1.0 release:

• Deals were applied for registered bidders (core bidders and hardcoded aliases) and soft aliases if they had a case sensitive match with the name of a bidder specified in the impression.

As of the PBS-Go v2.1.0 release:

• Deals are applied to responses for registered bidders (core bidders and hardcoded aliases) if they have a case insensitive match with the name of a bidder specified in the impression
• Soft aliases never have deals applied to them (this is a bug)

Going forward:

• Deals should be applied for registered bidders (core bidders and hardcoded aliases) if they have a case insensitive match with the name of a bidder specified in the impression
• At a minimum, deals should be applied to soft aliases if they have a case sensitive match with the name of a bidder specified in the impression (this was the original behavior prior to the v2.1.0 release). We could expand this so the match is insensitive but that could be a future enhancement as it might take a bit more work.

As of this morning, there will be a general discussion soon on the deal tiers feature to evaluate whether it is still needed, and if so, to document the expected behavior. In that case, I suggest moving forward with the case sensitive compare on soft aliases while maintaining the current insensitive compare for registered bidders.

[bretg]

Closed with #3391