Prebid.js client side loss notifications, adding info to future events or own event?

[senaev]

Type of issue

question

Description

There was a question about lose notification in 2020 https://github.com/prebid/Prebid.js/issues/5960#issue-741503747

Has something been changed since then? Does bidder have a possibility to get feedback in case of lost auction (for example like lurl in OpenRTB)

[patmmccann]

This isn't currently a feature, partial dupe of #4493

[patmmccann]

We have rules against obtaining information on other parties

eg "Bidder modules must not obtain bid information from or about any other party in the auction. E.g., they cannot listen to ad server events and forward information naming other bidders back to their endpoint - that is the job of an analytics module."

Currently the plan is to develop either #4493 or add loss notifications to future bid requests or to a fetch with keepalive which outlives the page.

[patmmccann]

We can pass in the future bid request a json with the following four fields as a new top level object on request, or somewhere in an ext.

{ bidderRequestId: 123, auctionId: imp.ext.tid, -- might be null minBidToWin, the bid needed to win this auction. rendered: 1/0 -- did prebid render a bid on this auction }

[senaev]

We can pass in the future bid request a json with the following four fields as a new top level object on request, or somewhere in an ext.

How can I subscribe to updates about this feature request? Is there any thread?

[patmmccann]

we'll keep this one open

[pm-harshad-mane]

Each SSP should be able to mention how they want to receive these notifications, either in following requests or fired immediately to their end-points. Both approaches need different implementations...

• to send the data in following requests we will need to store dat in first party
• to send data asap, we can use JS Beacon API

Why JS Beacon? The Beacon API is used to send an asynchronous and non-blocking request to a web server. The request does not expect a response. Unlike requests made using XMLHttpRequest or the Fetch API. The browser guarantees to initiate beacon requests before the page is unloaded and to run them to completion. https://developer.mozilla.org/en-US/docs/Web/API/Beacon_API

[jlquaccia]

Created a PR for this ticket. I created a new "lossNotifications" module in core that can optionally be used internally within bid adapters. When enabled, the module supports 2 methods for issuing out loss notifications to bidders:

1. By default, loss notifications will be sent out to respective bidders in subsequent auctions within a bidders outgoing bid request (for example, bidder A and bidder B are participating in auction 1. bidder A wins. during auction 2 (or next auction that bidder B is involved in), bidder B will receive the loss notification within their bid request.
2. If a bidder provides an endpoint of their own, they can send loss notifications about their bids to their own endpoint via the JS Beacon API: https://developer.mozilla.org/en-US/docs/Web/API/Beacon_API

A few questions also came to mind while working on this PR:

• Is it ok to have the logic for this ticket within the new "lossNotifications" module that I made in core? Or let me know if it should live somewhere else
• Thinking tid's should only be referencing bid.ortb2Imp.ext.tid right? (or set to null if no value is found for that key)
• When local storage is used for loss notifications, most likely, there will always be some loss notification value being stored in local storage at a given point (which will always be waiting on the next/subsequent auction..) is this ok? (not sure if this matters or not)
• When using the prebid storageManager.js, what should moduleType be set to? (Is it ok to set this to “prebid”?)

[patmmccann]

@jlquaccia noe thought, fetch keepalive replaced beacon see https://github.com/prebid/Prebid.js/blob/13cbc7c53c52e856fdcd5d9522283d9609c2d103/modules/amxBidAdapter.js#L553

[patmmccann]

Is it ok to have the logic for this ticket within the new "lossNotifications" module that I made in core? Or let me know if it should live somewhere else

how about a library that bidders can import, not a module?

Thinking tid's should only be referencing bid.ortb2Imp.ext.tid right? (or set to null if no value is found for that key)

or auctionid, but bidderRequestId is always avail

When local storage is used for loss notifications, most likely, there will always be some loss notification value being stored in local storage at a given point (which will always be waiting on the next/subsequent auction..) is this ok? (not sure if this matters or not)

why not just store in window?