seeing lower bids winning on Video

[spormeon]

we are using a mix of client and s2s bidders for video, we are seeing, that when all bidders bid the client side bids are winning above the s2s bids, even if the s2s bids are much bigger. We have the params setup on the client bidders such as :var pubmaticBid = {
bidder: 'pubmatic',
params: {
publisherId: 'vvvvvvvv',
adSlot: 'hhhhhhhhh',
video: {
playerWidth: 640,
playerHeight: 480,
minduration: 5,
//maxduration: 30,
api: [1, 2],
protocols: [1, 2, 3, 4, 5, 6],
playbackmethod: [2],
linearity: 1,
//position: 2,
placement: 1,
mimes: ['video/x-ms-wmv', 'video/mp4', 'video/webm', 'video/3gpp', 'video/mpeg', 'application/javascript']
}
}
};

and the s2s bidders params are setup on the adunit level, e.g:
mediaTypes: {
video: {
playerSize: [640, 480],
w: 640,
h: 480,
context: 'instream',
mimes: ['video/x-ms-wmv', 'video/mp4', 'video/webm', 'video/3gpp', 'video/mpeg', 'application/javascript'],
placement: 1,
position: 2,
startdelay: 0,
playbackmethod: [2, 6],
minduration: 5,
maxduration: 30,
protocols: [1, 2, 3, 4, 5, 6, 7, 8],
linearity: 1,
api: [1, 2]
}
},

has anyone else seen this sort of behaviour? using prebid 4.21.0

[bretg]

@spormeon - so far I haven't been able to reproduce this issue. Are you using enableSendAllBids:false? Any target-limiting options?

[spormeon]

@bretg i am using enableSendAllBids:false. I use display and video on 'seperate" prebids, display has useBidCache set at true/ false depending on time of day, would useBidcache: true persist over the 2 prebids even if the video prebid is set to false?

[bretg]

Tried my test page with enableSendAllBids:false and still not seeing client winning over server. Cant' see bidCache with multiple instances of Prebid.js being a factor, since adunit.code is the primary key there.

1. Is it possible there are deals involved and you have alwaysIncludeDeals set?
2. Could there be a timeout situation? I have seen scenarios where the s2s response comes just a little too late, missing the ad server call, but there in time for the analytics.

[spormeon]

no alwaysIncludeDeals set

both my timeouts are set to 2000, that should be way enough?
timeout: 2000,
bidderTimeout: 2000,

its only seems to be on the first couple of page loads, and mainly on the 1st page load, after that it seems to go to "ok"

[spormeon]

here is actually an example: oneVideo & pubmatic are our client side, the rest S2S

and its oneVideo parsed in the vmap and also we can see it in the buildVideoUrl send to dfp (but not got a screenshot of that)

[spormeon]

i've extended timeout to 3500 and i think this has got it working again. seems a very long timeout to me though. On prebid server, what does tmaxrequest: 3500 & responsetimemillis actually mean? i see:
responsetimemillis: {33across: 169, appnexus: 165, districtm: 14, emx_digital: 209, gumgum: 138, ix: 10, openx: 307,…}
33across: 169
appnexus: 165
districtm: 14
emx_digital: 209
gumgum: 138
ix: 10
openx: 307
rhythmone: 288
smaato: 19
tmaxrequest: 3500

are these timing, time for server to respond with initial request, or is it time to send back a responce? could there be appnexus: 165, but a sent back responce not be until 2500?

when i had timeout: 2000, its was getting thrown out as back in 2500?

[bretg]

what does tmaxrequest: 3500 & responsetimemillis actually mean

tmaxrequest is just an echo of the incoming tmax. responsetimemillis is how long this bidder took to respond

i've extended timeout to 3500 and i think this has got it working again

Which timeout did you extend? There are several as described in https://docs.prebid.org/features/timeouts.html

I would agree that 2000 should be more than enough for s2sConfig.timeout.

In your screenshot... why does adId 1268185 show up for three separate adunits? (video1, video2, and video3) That shouldn't be possible unless you're doing some funky stuff. What I notice from this list of bids is that this same adId won all 3 adunits. Maybe there's something possible wrong with the way you're managing bids here?

e.g. say you're manually copying the bid with adId 1268185 to the auction for all 3 video adunits and it legitimately wins the 3rd one. Unclear to me what Prebid.js will do if a bid flagged as a winner in one auction exists in others as well.

[spormeon]

i extended:
timeout: 3500, ( for s2s)
bidderTimeout:3500,
the multiple adid is only for oneVideo, i've already asked them about this, they say its right, their one of the client side bidders and just bidding on the video slots in the same mechanism as the other bidders

[bretg]

I'm pretty certain that multiple bids with the same adId is a part of the problem here. Adding @adam-browning to comment on why OneVideo is setting the bidResponse.adId. I suspect it's just a misunderstanding, because several other BidAdapters also set adId.

The intention was that PBJS-core sets adId -- there's no need for Bid Adapters to set it, and in fact maybe we need to disallow it.

Here's at least part of the confusion:

• When markWinningBidAsUsed() is called, it keys on the adId. So if OneVideo wins any bids at all, EVERY one of their bids is flagged as having won.
• That may or may not be an actual problem when it comes to what's sent to GAM, but it is certainly misleading when it comes to debug output. For instance, say that OneVideo wins the 'video3' slot, but direct-sold ads win 'video1' and 'video2'. Since the "status" column is tied to the adId, the debug output will indicate that OneVideo seemed to have won 'video1' and 'video2' when in fact it didn't.

I can't tell from the getWinningBids code whether a duplicate adId could be a problem in determining the auction winner, but if you're willing to experiment, you could try removing this one line of code from oneVideoBidAdapter.js:

adId: bid.adid,

However, this doesn't explain why raising the timeout seems to change behavior. My suggestion is that the s2sConfig timeout should be lower than the setConfig({bidderTimeout}) by a safety margin. e.g. try setting s2sConfig timeout to 1000 and setConfig({bidderTimeout: 2000})

Prebid Server should not need more than 1000ms -- give it a short leash so it response well in advance of the GAM request.

[spormeon]

ok, i got it, i think that all pretty much explains whats happening, i just hadn't joined the dots like you have. it might also start pointing/explain why my stats for onevideo are like 50% out.

in simple terms a "random" adid, is going to be best for anyone running more than 1 pre-roll in effect

[spormeon]

confirm, this is what's happening, seen it this morning, if oneVideo wins video 3, video 4, 5 etc get marked "rendered" and "mess" everything up in effect. Its most prevalent on the first page load or two as this seems to be when oneVideo bids most before "dropping off on bidding" and goes back to normal/ right. I'm going to try taking off markWinningBidasUsed as we don't actually "refresh" in effect

[adam-browning]

Sorry for the late reply. We were not aware of that logic in pbjs. I believe that this was done in the past to see if the correct adId is coming from VSSP. It is defiantly not necessary since we can review the bid-resposne. I will fix the oneVideo bid adapter accordingly. Thanks in advance, Adam

…

On Wed, Mar 3, 2021, 13:12 spormeon ***@***.***> wrote: confirm, this is what's happening, seen it this morning, if oneVideo wins video 3, video 4, 5 etc get marked "rendered" and "mess" everything up in effect. Its most prevalent on the first page load or two as this seems to be when oneVideo bids most before "dropping off on bidding" and goes back to normal/ right. I'm going to try taking off markWinningBidasUsed as we don't actually "refresh" in effect — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6329 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEXKMNIXALQXJJWNPFTV66DTBYKSTANCNFSM4X2NNSGQ> .

[ChrisHuie]

closing with merge of #6382 and now tracking at #5381

[spormeon]

we're still getting this funky weird lower bids winning, even with "random" adId's, it seems to have moved from always being oneVideo that was winning, to now "randomish" when a good spread of bids come in: