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.

Sign up for GitHub

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

Jump to bottom

Clarifying product-level specification. #185

Merged
merged 4 commits into from
Sep 9, 2021
Merged

Clarifying product-level specification. #185

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
789c636
Clarifying product-level specification.
jonasz May 21, 2021
9f1455e
Better description of trustedBiddingSignalsKeys.
jonasz Jun 11, 2021
9443fb8
Drop the idea of shallow merge in daily updates
jonasz Jul 30, 2021
c148499
Drop the clarification on prevWins
jonasz Sep 3, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion FLEDGE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -93,6 +93,7 @@ const myGroup = {
'trustedBiddingSignalsKeys': ['key1', 'key2'],
'userBiddingSignals': {...},
'ads': [shoesAd1, shoesAd2, shoesAd3],
'adComponents': [runningShoes1, runningShoes2, gymShoes, gymTrainers1, gymTrainers2],
};
navigator.joinAdInterestGroup(myGroup, 30 * kSecsPerDay);
```
Expand All @@ -113,6 +114,8 @@ The `dailyUpdateUrl` provides a mechanism for the group's owner to periodically

The `ads` list contains the various ads that the interest group might show. Each entry is an object that includes both a rendering URL and arbitrary metadata that can be used at bidding time.

The `adComponents` field contains the various ad components (or "products") that can be used to construct ["Ads Composed of Multiple Pieces"](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#34-ads-composed-of-multiple-pieces)). Similarly to `ads` field, each entry is an object that includes both a rendering URL and arbitrary metadata that can be used at bidding time. Thanks to `ads` and `adsComponents` being separate fields, the buyer is able to update the `ads` field via daily update without losing `adComponents` stored in the interest group.

The browser will provide protection against microtargeting, by only rendering an ad if the same rendering URL is being shown to a sufficiently large number of people (e.g. at least 100 people would have seen the ad, if it were allowed to show). As discussed in the [Outcome-Based TURTLEDOVE](https://github.com/WICG/turtledove/blob/master/OUTCOME_BASED.md) proposal, this threshold applies only to the rendered creative; all of the metadata associated with ad bidding is not under any such restriction. Since a single interest group can carry multiple possible ads that it might show, the group will have an opportunity to re-bid another one of its ads to act as a "fallback ad" any time its most-preferred choice is below threshold. This means that a small, specialized interest group that is still below the daily-update threshold could still choose to participate in auctions, bidding with a more-generic ad until the group becomes large enough.


Expand Down Expand Up @@ -236,7 +239,7 @@ Buyers may want to make on-device decisions that take into account real-time dat
The base URL `https://www.kv-server.example/getvalues` comes from the interest group's `trustedBiddingSignalsUrl`, the hostname of the top-level webpage where the ad will appear `publisher.com` is provided by the browser, and `keys` is a list of `trustedBiddingSignalsKeys` strings, perhaps coalesced (for efficiency) across any number of interest groups that share a `trustedBiddingSignalsUrl`. The response from the server should be a JSON object whose keys are key1, key2, etc., and whose values will be made available to the buyer's bidding functions (un-coalesced).


Similarly, sellers may want to fetch information about a specific creative, e.g. the results of some out-of-band ad scanning system. This works in the same way, with the base URL coming from the `trustedScoringSignalsUrl` property of the seller's auction configuration object, and the keys being the `renderUrl` fields of all the ads in the `ads` fields of all interest groups in the auction. The value associated with a `renderUrl` key is provided as the `trustedScoringSignals` parameter to the seller's `scoreAd()` function.
Similarly, sellers may want to fetch information about a specific creative, e.g. the results of some out-of-band ad scanning system. This works in the same way, with the base URL coming from the `trustedScoringSignalsUrl` property of the seller's auction configuration object, and the keys being the `renderUrl` fields of all entries in the `ads` and `adComponents` fields of all interest groups in the auction. The value associated with a `renderUrl` key is provided as the `trustedScoringSignals` parameter to the seller's `scoreAd()` function.


_As a temporary mechanism_ during the First Experiment timeframe, the buyer and seller can fetch these bidding signals from any server, including one they operate themselves (a "Bring Your Own Server" model). However, in the final version after the removal of third-party cookies, the request will only be sent to a trusted key-value-type server. Because the server is trusted, there is no k-anonymity constraint on this request. The browser needs to trust that the server's return value for each key will be based only on that key and the hostname, and that the server does no event-level logging and has no other side effects based on these requests.
Expand Down