From 14d9f62d31c6929e7f7bbaaa1b0449d1aa0b3f4e Mon Sep 17 00:00:00 2001 From: Michael Kleber Date: Thu, 5 Nov 2020 16:13:42 -0500 Subject: [PATCH] Update TURTLEDOVE to point to on-device JS auctions The PARROT and TERN proposals, and discussions in e.g. #37 and #59, all point to the need for separating out the DSP and SSP roles for on-device bidding and auctioning. --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 39142acb7..1d7bda04d 100644 --- a/README.md +++ b/README.md @@ -219,6 +219,8 @@ The contextual request/response need not be implemented as its own HTTP request. As a possible extension to this idea, the contextual response might _also_ contain a JS bidding function, rather than a fixed bid. This may be useful if there are any other user-specific signals that are available in the browser but not in the server, which could then be made available to the various on-device bidding functions without compromising privacy. +_Addendum:_ The above description focused on each ad producing a _bid_, and assumed a simple auction in which the winner was the largest bid. This is probably too simplistic, and instead we will need a mechanism in which (1) each ad can run on-device JS to procuce a bid, and then (2) some on-device JS provided by the publisher or their ad network chooses the winner. This idea is explored more in the [PARROT](https://github.com/prebid/identity-gatekeeper/blob/master/proposals/PARRROT.md) and [TERN](https://github.com/WICG/turtledove/blob/master/TERN.md#6-the-auction) proposals. + ### Rendering the Winning Ad