Skip to content
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

Capabilities of the proposal for publishers #51

Open
anielo opened this issue Aug 31, 2020 · 1 comment
Open

Capabilities of the proposal for publishers #51

anielo opened this issue Aug 31, 2020 · 1 comment

Comments

@anielo
Copy link

anielo commented Aug 31, 2020

Hi all,

after analyzing the proposal and the comments (as many as possible), the following points remained open for us:

  • Can a publisher control which bidders are allowed to participate in the auction? This is an important point, as publishers have a need to control who is advertising on their inventory.

  • Can a publisher set a floor bid on the inventory? Publishers often want to make sure that the inventory is not sold under a given bid/price.

  • Is it possible to make ad servers compete in the browser? In the proposal this seems possible by chaining consecutive calls to renderInterestGroupAd with different values of metadata.network. This would be similar to a waterfall model, where the first winning bid wins even though another ad server would have won later in the chain. Did you think of an alternative where bidding could happen in parallel for many ad servers?

  • According to the proposal, the contextual request can contain any first-party targeting information (which could be a first-party profile of the user for example). This would mean that if a publisher wants to use its own first-party interest groups only, it could completely bypass the renderInterestGroupAd method to render ads. Is this correct? This would be a way to preserve IO (insertion order) deals.

  • Who controls the bidding rules in the browser (on-device-bid.js)? As commented here, we assume that advertisers define the script dependending on their campaigns. For each interest group an advertiser wishes to use, one bidding script can be defined to determine the bid depending on contextual and ad signals. Is this correct?

  • How does this contextual signal of the contextual response look like and where does it come from? If no schema is defined, this would imply that the author of the bidding rules that read the contextual signals (on-device-bid.js) needs to coordinate with the provider of the contextual signals.

In addition, we would be very glad if you could inform us on the progress of the proposal as well as on the further specification/development process.

Best regards,
Angelo Brillout

@JoelPM
Copy link
Contributor

JoelPM commented Nov 19, 2020

I think these are very good questions and I'm also interested in the answers to them. With regard to publisher control, I think this is a broader question of what level of decision TURTLE-DOV is making, something I asked in #73 . My hope is that TURLTE-DOV is making a local decision over the ads for a given SSP, and that it does so only when asked to by the publisher.

If the publisher is allowed to make calls of the sort:

let openxAd = navigator.selectAd("openx.com");
let indexAd = navigator.selectAd("index.com");

Then they can implicitly control who participates by requesting ads only for the SSPs they wish. In fact, I have a hard time imagining the feasibility of a global decision API where a publisher can only do: let bestAd = navigator.selectAd();.

At any rate, I look forward to seeing TURLTE-DOV provide clarity on the points you raised.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants