Prebid.js: New prebid version doesn't show all bids in the console

[GiovanniPascoli]

Type of issue

Request

Description

Upgraded to Prebid v1.12.0 the snippet code to see all bids in the console, now show only winning or looser bids and not all like preceded version (which was also showing the no bid available responses).
Is there a way to restore the previous behavior, even by using undocumented APIs?

Test page

None

Platform details

Prebid v1.12.0 Chrome, ecc.

Other information

I follow steps on the "See all bids in the console" section on
http://prebid.org/dev-docs/toubleshooting-tips.html

[jnsprngs]

Seconding this issue.

I am testing v1.12.0-pre and not seeing any bids with a statusMessage : 'Bid returned empty or error response' instances. Instead, it looks like null bid responses are excluded from pbjs.getBidResponses().

[mercuryyy]

We all second this issue, but this is within prebid new core. @prebid Team mentioned in another thread they do not have time to address this and its open if anybody want to submit a pull.

I think getBidResponses() should return all bids, so we can see who timed out and who was within the timeout but returned no bid.

[mkendall07]

yes open for anyone to submit a pull request but I don't think the work is trivial.

[YOzaz]

This is required imho.
Google Analytics module now fails to identify which response has failed or timed out.

[dejanstrbac]

It is not really prebid that filters the zero cpm bids that previously used to come through as "empty or error response".

Prebid now tags all bids coming from the adapters as "available", even if cpm=0. It is adapters that are also now ignoring own 0 cpms.

One way to get similar data now could be by listening to bidderDone event. You can then deduct a zero cpm bid. For timeouts, you could use the same event (well, the lack of it) or the bidderTimeout event which is not reliable, but it will be impossible to get the information of the final TTR as in Prebid < 1.0.

[Tigerroad]

Is this also related to Google Analytics labels not being set for EventAction: Timeouts. I was just about to open a new Issue but it seems related?

[andyblackwell]

Here's a start at it. It's working for my needs, but I haven't fully tested. Maybe it could point someone with enough time to do a proper PR in the right direction?
https://gist.github.com/andyblackwell/8815a2b721ad82fbe450347fa221471e
diff with v1.14.0: https://www.diffchecker.com/FtVTQlet

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[andyblackwell]

bumping out of stale. Can this be labeled somehow so it doesn't get auto-closed?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[andyblackwell]

Can we get this labeled as a bug or feature, so it stops getting set to stale? @mkendall07

[tusklozeleniy]

If it marked as a feature is it a correct behavior? After reading docs I have expected to see all of the bidders in console, but get only 2 of them.

[andyblackwell]

read it as feature-request
think the change was just an oversight in the adapter spec of 1.*, so this is now a feature request to get it back to parity with pre 1.*

[mike-chowla]

I'm reviewing #3022 but wondering if makes sense to change the core to solve the problem of debugging output. Shouldn't the debug snippet just be changed to handled this case?

[snapwich]

The core of the issue is that in 1.x the adapter spec was changed so that adapters were no longer required to return NO_BIDs since we no longer do bid counting, this resulted in the bidderFactory being implemented without returning NO_BIDs, and since most adapters are created through the bidderFactory this means NO_BIDs are not sent back to the auction. I think this is correct. I also think the auction could go one step further, if it does not already, and just early return if it receives NO_BIDs, that way the auction isn't cluttered with logic handling a bunch of irrelevant bids.

I understand this hurts debugging and analytics, but debugging and analytics should not be the concern of the auction. IMO, analytics and debugging is a cross-cutting concern that in this case should be handled separately from the auction, such as with the addition of a new event in the bidderFactory for analytics adapters to pick up NO_BIDs or something to that affect. I'd rather we not start sending NO_BIDs back through the entirety of the auction again. This also relates to #3022 which is basically just going back to that old NO_BID behavior, which I think is wrong.