-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rubicon Adapter allow multi bids configuration per adUnit #496
Comments
We're looking into this. |
This issue may be related to this fix #498 |
We reproduced the problem in the enableSendAllBids() scenario. The Rubicon adapter is only registering the highest bid, which causes the platform to duplicate that bid. The 728x90 normally has the higher bid, explaining why that size is the one seen most often. A fix is underway. |
@cwbeck - how are you getting the log entries "Bid [728x90] rubicon @ $0.42 | RT: 438ms" ? We have other evidence, but we'd like to make sure the issue is fixed for you as well. |
@bretg thanks for your quick response on this. We have a custom abstraction over prebid.js. We have a layer in our own debug setup that gives us this view so our adops can see what is going on. We also colour-code the output, so we can see what is going on for each ad-unit. It's actually proved to be very useful. Console in Chrome: - |
@cwbeck |
@cwbeck I'm working with @bretg on this issue and I'm actually having a bit of a hard time recreating it. However, I think I've fixed what appears to be an issue in the registering of multiple bids from rubicon per adUnit. Can you give me more of an example of how your adUnits are configured so I can properly duplicate the issue and confirm the fix? edit - or if you would like, pull the commit linked below and re-test. |
@mkendall07 Public gist of our render.js - https://gist.github.com/cwbeck/bdea9f22ceed8af489fb047f357f77cc I'll see what I can do! |
@snapwich @bretg I'm still seeing the same issue as before: - (on all sites) Where [Object, Object] is passed directly to Result: - We form the bid requests are per prebid.js documentation - we don't do anything special here. Hope that helps! -- edit... This is how it looks before processed by |
why not just use something like function effectiveDeviceWidth() { this works well for me, then you also save on calling 2 ads you can set the min width to w/e you want or simply have it random, of course it will never out preform calling 2 ads and picking the highest bidder but for now im using this. |
@mercuryyy , thanks, but I don't think you fully understand the thread! This has nothing at all todo with screen size. This is a promo tag issue. |
Thanks @cwbeck, I've been able to recreate the issue with the adUnit config you provided. I was originally working on the assumption that you were doing one placement with two possible sizes, which apparently has an issue as well (so I'll leave my earlier fix in there). I'll see if I can discover what's going on here and provide more info / an additional fix. |
@cwbeck in the first screenshot you provided it appears that you are reusing the same That If you are attempting to run an auction with a single adUnit Let me know if I'm misunderstanding since I'm only assuming you are reusing the same @mkendall07 can probably correct me if I'm making any mistakes; I'm new to the Prebid.js world myself. |
@snapwich, thanks for looking into this. You are correct, we could provide two sizes, but that would only a be a single auction. We have deliberately forced two auctions for a promo tag as the results have proved to be better (only with certain partners). The object we build is correct as per the docs. It should allow multiple bids to come back in this way. We designed everything around this on our side. The first screenshot the data has been augmented by the prebid.js library. We don't set most of those values. -- edit - also worth pointing out, the pre-fastlane adapter used to work like this. |
That's not true in the case of the Rubicon adapter, currently there are two auctions performed, one for each size, and the bid with the higher CPM is registered with Prebid. When the pull-request I've attached to this issue is merged, both bids will be registered. Are you sure the other adapters don't behave similarly? As to whether the adUnits should accept a duplicate |
We recently merged #498 and now adapters can create bid responses with an ID that matches the bid request ID. See the Sovrn adapter in that PR for an example of passing the bid request object into |
@protonate thanks for the update. @snapwich more than happy to test your fork when ready. |
Hey all - currently reviewing this and will reply shortly. |
@protonate @cwbeck, I've updated my pull-request to allow the bidRequests to be attached to the createBid call. However, I don't think this will fix the root issue of using duplicate adUnit.code which breaks the rubicon slot definitions. On a side note, using duplicate adUnit.codes doesn't just break the Rubicon adapter. To verify, I did a quick audit of some other Prebid.js code and found other places that will break inside Prebid.js if adUnit.code values are allowed to be duplicated. https://github.com/prebid/Prebid.js/blob/master/src/bidmanager.js#L46 https://github.com/prebid/Prebid.js/blob/master/src/bidmanager.js#L74 https://github.com/prebid/Prebid.js/blob/master/src/prebid.js#L459 I didn't check if this breaks code in any other adapters. |
I'm not clear on exactly the case you would want to do this (Does it have to do with multiple sizes not being supported in a single request?) At any rate, it would be specific to bidder. The above may not be working 100% now with the recent refactors we have done to the prebid.js core, although it was never a use case we were working hard to support. |
@mkendall07 that is exact setup we use (your Rubicon example). Is this now considered deprecated? If so we can refactor, although not all adapters full support multiple size arrays last time I checked. |
@snapwich @cwbeck @snapwich |
@mkendall07 -- isn't having multiple bids in an AdUnit is functionally the same as having the same AdUnit repeated with different bids? Both scenarios require the system to keep track of disjoint bid parameters and sew them back together into a bidResponse. The examples given above have the same site ID -- just size differs, so that special case is pretty easy to handle. But if the site or zone differ, they're different auction requests - basically prompting an expansion of the definition of "ad slot" to be an array of params objects. We'll need to consider the impact of this request on the single-request feature we're in the midst of building. |
@bretg |
@mkendall07 - there is actually a case of different sites that we're aware of -- publisher cooperatives. We support that scenario in our native header bidding platform, but so far we haven't had that type of request for Prebid scenarios, unless this is one. How about I put it on our queue -- we should be able to get to it in a couple of weeks, after the current round of development drains. |
…2.0 to master * commit '40fdbed10c218a993df9e6665797b36f402ded18': (52 commits) Added new adapter for AOL analytics Fixed ES6 features which require a polyfill Updated CHANGELOG Fixed per-adapter timeouts Fixed sorting of per-adapter timeouts Added horizontal rule to delimit the original README part Link to the AOL documentation made more visible Fixed unit tests for AOL analytics Made changes required due to pull from Prebid official Updated README Updated LICENSE Reverted AOL branding restore url.js and modifcations to ajax.js (prebid#551) Log unsupported ad type only for good bids (prebid#547) use var ad instead of incorrect ads in rubicon adapter (prebid#546) Karma opens debug.html by default (prebid#540) Prebid 0.12.0 release Add tests for triplelift adapter. (prebid#531) allows multiple bids to be registered per a slot, related to prebid#496 (prebid#503) Add tests for aardvark adapter. (prebid#529) ...
FYI I've spent a lot of time implementing Rubicon with no luck. I've just switched to |
@dugwood - cheers for update. one day Rubicon will get there. |
@cwbeck I really doubt that :-) But I think I'll add a fix one day... rubiconLite or rubicon is the same in the end, as there's a fallback from one size to another, which doesn't work with custom bidCpmAdjustment function (say you set a floor higher on a size and not on the other one, you may refuse an ad without knowing the other one). I'll wait for my CEO choice before looking for a fix :-P |
I'm looking into this. Here's what I already know, on either rubicon or rubiconLite:
So I'm working on the first case, which is the simplest to me (the second is very similar but the mapper of sizes is working, so why bother). |
Narrowed down to this test: As I tried to fix it a while ago (https://github.com/prebid/Prebid.js/pull/700/files#diff-96cd0debf7b766d72d2bcf987385e960R51), there's still an issue here. I'm looking at all the changes and will provide a PR for this. Currently setting |
As I said here: #763 (comment) For example: As you can see, there's an So, for Rubicon, it depends on the setup of your account! So there's no way to detect this, on the Prebid side, as the My suggestion: add a |
@dugwood the request is going out for all the sizes but is only returning the highest value size. So as long as your sizes are listed in the array all requests will go out. This is a recent change on how the requests fire within the last couple months. |
@caseybryan this isn't a good approach either: I've setup different floor prices, so I may ignore the bid in 300x600 but I would have accepted a 300x250 with a lower CPM. |
@caseybryan I do think you're wrong. For instance, with So either your server doesn't answer correctly, or you're mistaken on your fallback system. To me, the fallback occurs only when the floor CPM is not met on the first size. Hence, I have to run 2 separate calls, and then compare these in Prebid, outside of Rubicon servers. |
@cwbeck did you found a solution for this issue? I thought my issue was that I didn't have the The |
I'm currently dealing all those bugs with Rubicon engineers. So:
Updating your account to support MAS should fix this. But there's still the issue of counting expected bids, for those who don't have MAS enabled. The rubiconLite adapter can't guess the number of bids because it doesn't know the setup of MAS. |
Rubicon team updated my setup for multiple sizes, and it's now working as expected. Note that I don't see the But requesting size 2 with alt to 57&113 answers both 3 sizes with multiple refreshes. So that's good. And there's still a bug, they working on it. We should update the documentation stating that |
@snapwich is right. To me the main issue reported by @cwbeck is fixed: MAS enabled, multiple fixes and the |
thanks all. |
This is Rubicon only, all other adapters appear to be working as expect for us. Sending out a request with two sizes (728x90 and 970x250) will result in the following:
I wonder if a deep copy is not being made somewhere it should. Both requests go out for sizeId 2 and 57, both come back in, but 970x250 is always ignored and 728x90 response is cloned.
All other adapters work correctly..
...
...
The text was updated successfully, but these errors were encountered: