Prebid.js: Rubicon adapter uses wrong size for ad returned

[dugwood]

Type of issue

The size of the ad isn't the one of the creative for rubiconLite.

Description

I had the same issue with rubicon adapter (now deprecated or soon to be), with multiple requests, the first request to get back would define the size of the ad, regardless of the wining bid (and its creative).
Same thing with rubiconLite, which only have one request, but the final ad size would be the one of the first size defined, not the one found in the bid response.

Steps to reproduce

Use an array like this one: [[1000, 300], [970, 250], [728, 90]]
If the creative isn't 1000x300, the final iframe would still be 1000x300.

Expected results

Iframe should be the same size as the creative is

Actual results

Iframe is resized to the first (valid) size in the addAdUnits() call

Platform details

Prebid 0.15.0-dev

[bretg]

@snapwich and I will take a look

[snapwich]

@dugwood I'm having a hard time recreating this issue with the test page I have using the sizes you've listed. Would it be possible for you to provide the actual adUnits you are passing to addAdUnits?

[dugwood]

@snapwich here you go:

[{"code":"sas_438","sizes":[[1000,300],[970,250],[728,90]],"bids":[{"bidder":"rubiconLite","params":{"accountId":"9314","siteId":"18370","zoneId":"54808","position":"atf"}}]}]

And an example of the url currently generated (my prebid was built from the master a few days ago):

http://optimized-by.rubiconproject.com/a/api/fastlane.json?account_id=9314&site_id=18370&zone_id=54808&size_id=113&alt_size_ids=57,2&p_pos=atf&rp_floor=0.01&tk_flint=pbjs.rapid&p_screen_res=1680x1050&rand=0.5088367886937535&rf=http%3A%2F%2Fwww.lacoccinelle.net%2Findex.html

[snapwich]

@dugwood, I don't think your version of prebid.js was built from master because the endpoint was changed to fastlane.rubiconproject.com and the tk_flint=pbjs.rapid value was changed to tk_flint=pbjs.lite before the new adapter was ever initially merged into master. I suggest rebuilding from the latest master and see if that resolves your issues.

I tried to recreate the bug using the latest adapter in master and was unable after many attempts using the adUnit you've provided, so I think that may solve your problem.

[dugwood]

@snapwich you may be right. I used a dedicated RubiconLite adapter sent by one of your engineers. I thought I pulled the latest master after testing this, but it seems I was mistaken on the git pull. I'm building it again right now.

[dugwood]

Can't test this because I don't have any ad showing up. I've built from 0.14.0 and I'll push this in production where I think I'll be able to see some.

Thanks for the time taken, I'll let you know in a few hours if it's okay (I think it will be).

By the way, does the order of sizes matter? With some tests a few weeks back on rubicon adapter (not rubiconLite) it seems that sending 1000x300 before 728x90 sends back more 1000x300 ads.

[snapwich]

Sizing could possibly matter in the 0.14.0 version of the rubiconLite adapter; in the latest version that will be cut next week (0.15.0) and for the version in master it should not matter because the sizes are automatically reordered before the request is sent. I would highly suggest using that version if you can as there was a few relevant bug fixes as well related to sizes: https://github.com/prebid/Prebid.js/pull/783.

[dugwood]

@snapwich I'm using rubiconLite, and it seems to work fine this morning on my test page. I can see 970x250 (that I barely never see), 728x90 in a frame with good dimensions. I'll update to master in a few hours, but it seems that the issue's gone. Sorry for the inconvenience.

[dugwood]

Seems good with the latest master and renamed rubicon adapter. I've reordered ad sizes from the smallest to the biggest size. I'll have reports tomorrow (because Rubicon reports are only available 24 hours later). We had a big drop in big ads displays, that why I ordered the sizes in reverse, hoping for an improvement.
Perhaps I'll add a tracker for the size (already have a tracker for winner and CPM).

Thanks for your help!

[dugwood]

@snapwich I'm getting errors from the master branch, for example with 3 slots and rubicon adapter:
[{"code":"sas_438","sizes":[[728,90],[970,250],[1000,300]],"bids":[{"bidder":"rubicon","params":{"accountId":"9314","siteId":"18370","zoneId":"54808","position":"atf"}}]},{"code":"sas_439","sizes":[[300,250],[300,600]],"bids":[{"bidder":"rubicon","params":{"accountId":"9314","siteId":"18370","zoneId":"54808","position":"atf"}}]},{"code":"sas_503","sizes":[[300,250],[300,600]],"bids":[{"bidder":"rubicon","params":{"accountId":"9314","siteId":"18370","zoneId":"363704","position":"btf"}}]}]
will send 4 calls to the bidCpmAdjustment instead of 3. And it hangs the passback... Do you have a similar scenario?
The latest call has the following info (bid):
{"bidderCode":"rubicon","width":0,"height":0,"statusMessage":"Bid returned empty or error response","adId":"47d1729c5c6d66","error":{},"requestId":"7b760114-d948-4f8c-858e-28e99c8f0c6b","responseTimestamp":1479377010294,"requestTimestamp":1479377009832,"cpm":0,"bidder":"rubicon","adUnitCode":"sas_503","timeToRespond":462}
It's the exact same adId as the last adUnit declared, and there are 3 JSON requests only (so no reason for a 4th bid).

Any clue?

[dugwood]

Just made myself a joke in my own code... as it does the same with 0.14.0. So my bad :-)

Okay, the issue was that I misspelled a variable's name, but the result are quite strange. Why would this break things? The faulty code was in the if (params && params.hb_adid) part of bidsBackHandler. I think there's a try/catch somewhere, but it should not break anything. My faulty code was after the pbjs.renderAd().