Fledge - Revision history

Jkoran: /* Impact */

2021-06-25T13:28:25Z

Impact

Jkoran: /* Open Questions */

2021-03-01T14:24:18Z

Open Questions

Jkoran at 14:19, 1 March 2021

2021-03-01T14:19:37Z

Bleparmentier at 08:31, 1 March 2021

2021-03-01T08:31:00Z

MLysak at 17:20, 24 February 2021

2021-02-24T17:20:35Z

Jkoran: /* Open Questions */

2021-02-18T14:06:37Z

Open Questions

Jkoran: /* Open Questions */

2021-02-18T13:58:40Z

Open Questions

Jkoran: /* Experiment Design */

2021-02-18T13:51:35Z

Experiment Design

Jkoran: /* Open Questions */

2021-02-02T21:15:46Z

Open Questions

Jkoran: /* Open Questions */

2021-02-02T21:15:06Z

Open Questions

@@ Line 55: / Line 55: @@
 * [[Cohort]] vs [[attribute]] level audience inputs to buyer algorithms
 * [[Aggregate Reporting API|Aggregate]] vs event-level feedback to buyer algorithms
 * Time-delayed vs real-time event-level feedback to buyer algorithms
 == Open Questions ==

@@ Line 64: / Line 64: @@
 ** What time delay, if any (e.g., on lost bids), will be used to quantify the impact of Turtledove/Fledge on marketers' value of publisher inventory?
 ** How frequently can marketers adjust budgets per campaign (e.g., time delay after they realize that a campaign is not performing well)?
 * Publisher Revenues
 ** Given publishers will be monetizing the same ad slot with existing monetization and Chrome-based monetization, how will the metrics associated with each be reported for comparison?
@@ Line 81: / Line 82: @@
 ** What is the maximum number of DSPs that can operate in the ecosystem under a model where the browser must directly contact each for bids?
 ** What is the maximum level of latency chrome is willing to accept on their browser caused by the JS function running in worklet?
 ** How chrome intends to handle potential billing dispute, being the only one with access to billing data via their reporting APIs?
 * Experiment Goals
 ** Why is Google not evaluating the metrics proposed by [[Teetar]], such as measuring experience and perception of users exposed to cohort-based advertising?
 ***Related Fledge issue: https://github.com/WICG/turtledove/issues/95
 == See Also ==

@@ Line 12: / Line 12: @@
 **** Each Chrome browser will fetch marketer desired segmentation logic
 **** Each Chrome browser will processes each marketer's audience segmentation logic and send its unique identifier whether or not it qualifies for the audience segment to the Google-controlled server
-**** The Google-controlled server will count distinct number of identifiers belong to each audience segment
+**** The Google-controlled server will count distinct number of identifiers belonging to each audience segment
-***** If the number of identifiers exceeds a Google-defined threshold, then this server will notify these browsers that they may use such the periodic refresh of JS.
+***** If the number of identifiers exceeds a Google-defined threshold, then this server will notify these browsers that they may use such audience segment in the marketer's desirability logic.
 **** Each audience segment will have a maximum lifespan of 30 days
@@ Line 36: / Line 36: @@
 * '''Auction Mechanics'''
-** DSPs calculate the Audience-out-of-context bid by the desirability logic they posted to the Google designated end point. They can call a trusted key value server to help with their logic and have real time controls.
+** DSPs post to the Google-designated end point the desirability logic to calculate the Audience-out-of-context bid. They can post information to a Google-controlled key value server to help store inputs into their logic. While the information may be fetched by the browser in real-time from this trusted server, the updates to it will not be in real-time given the buyer does not have real-time feedback to adjust what it should alter.
 ** Publishers may also send to the Fenced Frame their most desirable ad from their own direct sales process, if they have one
 ** The Chrome browser conducts an on-device auction to determine a local winning ad
 *** The Chrome browser will filter the returned bids based on the presence of audience attributes
 *** The Chrome browser will apply the publisher desirability logic to first choose the on-device auction winning ad
-*** The Chrome browser will compare this ad to the direct-sold publisher, if any, and apply the publisher desirability logic to first choose the on-device auction winning ad
+*** The Chrome browser will compare this ad to any direct-sold publisher ad, and apply the publisher desirability logic to choose the on-device auction winning ad
 * '''Post-auction'''
 ** During the experiment phase, the Chrome browser will send reporting data to pre-specified publisher and buyer end points with event level data as to the outcome of the auction
 *** After the experiment phase, the Chrome browser will not send event-level data to the publisher or marketer
-**** It will "not [be] possible for any code on the publisher page to inspect the winning ad or otherwise learn about its contents"
+**** Because it will "not [be] possible for any code on the publisher page to inspect the winning ad or otherwise learn about its contents," Google will control the final auction on the page -- rather than allowing publishers to control their yield
 *** In neither phase, will the Fenced Frame allow the publisher or buyer browser identifiers to be associated with the event-level data
-** Marketer buying platforms that lose auctions will get access to aggregate metrics on some yet to be determined, time-delayed basis
+** Marketer buying platforms that lose auctions will get access to some aggregate metrics on some yet to be determined, time-delayed basis
 == Impact ==
-Given FLEDGE's design, the following are impacts to marketing effectiveness will not be measured:
+Given FLEDGE's design, the following are impacts to marketing effectiveness will not be measured during the trial:
 * [[Cohort]] vs [[attribute]] level audience inputs to buyer algorithms
@@ Line 62: / Line 62: @@
 ** What limits on marketer audience segmentation logic will be placed?
 ** How can marketers and their agents protect their intellectual property (audience data, campaign budgets) from being disclosed to Google?
-** What time delay, if any (e.g., on lost bids), will be used to quantify the impact of Turtledove on marketers' value of publisher inventory?
+** What time delay, if any (e.g., on lost bids), will be used to quantify the impact of Turtledove/Fledge on marketers' value of publisher inventory?
 ** How frequently can marketers adjust budgets per campaign (e.g., time delay after they realize that a campaign is not performing well)?
 * Publisher Revenues
 ** Given publishers will be monetizing the same ad slot with existing monetization and Chrome-based monetization, how will the metrics associated with each be reported for comparison?
-** Google states publishers must pre-approve each buyers' audiences (or allow all), but how can this be accomplished without buyers leaking intellectual property to sellers?
+** Google states publishers must pre-approve each buyers' audiences (or allow all), but how can publishers have granular control without buyers leaking intellectual property to sellers?
 ** Google states publishers must pre-approve each buyers' audiences (or allow all), but how feasible is it to send large lists of approvals to the browser on each ad request?
-** How does the publisher learn the clearing price of the ads on a per advertiser basis, so that it can negotiate direct deals with them?
+** How does the publisher learn the clearing price of the ads on a per advertiser basis (rather than on an average basis), so that it can negotiate direct deals with them?
 ** Why is Google mandating the order of operations which has the Chrome browser controlling the final auction, rather than the publisher's monetization platform (e.g., Publisher Ad Server or SSP) which otherwise could compare the locally winning ad and its bid price to other demand for this same ad slot and select the winning ad to render?
 * Creative Review
-** How does the publisher perform the ad creative review process across all live ads in the ecosystem given they do not know which ones will win auctions on their websites?
+** How does the publisher perform the ad creative review process across all live ads in the ecosystem, given they do not know which ones will win auctions on their websites?
 ** Given publishers will no longer be able to see which creative renders on its property in real-time, how do they prevent bad actors from swapping a pre-approved creative with a file of the same name but containing a new image?
 ** Because FLEDGE proposes that ad creatives will be cached ahead of time, such that the request for the creative by the browser will not be used to signal to buyers any information, this raises the question how the browser can cache video creatives?

@@ Line 13: / Line 13: @@
 **** Each Chrome browser will processes each marketer's audience segmentation logic and send its unique identifier whether or not it qualifies for the audience segment to the Google-controlled server
 **** The Google-controlled server will count distinct number of identifiers belong to each audience segment
-***** If the number of identifiers exceeds a Google-defined threshold, then this server will notify these browsers that they may use such audience segments for auction logic
+***** If the number of identifiers exceeds a Google-defined threshold, then this server will notify these browsers that they may use such the periodic refresh of JS.
 **** Each audience segment will have a maximum lifespan of 30 days
@@ Line 35: / Line 35: @@
 * '''Auction Mechanics'''
-** When triggered by the Fenced Frame, the Chrome browser will send a bid request to a limited number of marketers' buying platforms (e.g., DSPs) containing only the context of the given ad slot
-** DSPs receiving the Chrome browser request for a bid will determine whether they want to return a bid response
+** DSPs calculate the Audience-out-of-context bid by the desirability logic they posted to the Google designated end point. They can call a trusted key value server to help with their logic and have real time controls.
 ** Publishers may also send to the Fenced Frame their most desirable ad from their own direct sales process, if they have one
 ** The Chrome browser conducts an on-device auction to determine a local winning ad
@@ Line 81: / Line 80: @@
 ***Related Fledge Issue: https://github.com/WICG/turtledove/issues/120
 ** What is the maximum number of DSPs that can operate in the ecosystem under a model where the browser must directly contact each for bids?
 * Experiment Goals
 ** Why is Google not evaluating the metrics proposed by [[Teetar]], such as measuring experience and perception of users exposed to cohort-based advertising?

@@ Line 79: / Line 79: @@
 ** Who will pay for operating the Google-controlled servers that process marketer audience segmentation logic?
 ** How do Google-controlled servers become trusted and will this same process be available to all rivals?
 ** What is the maximum number of DSPs that can operate in the ecosystem under a model where the browser must directly contact each for bids?
 * Experiment Goals
 ** Why is Google not evaluating the metrics proposed by [[Teetar]], such as measuring experience and perception of users exposed to cohort-based advertising?
+***Related Fledge issue: https://github.com/WICG/turtledove/issues/95
 == See Also ==

@@ Line 11: / Line 11: @@
 *** The first information set contains logic rules that determines marketer-defined audience segmentation
 **** Each Chrome browser will fetch marketer desired segmentation logic
-**** Each Chrome browser will processes each marketer's audience segmentation logic and return back with its unique identifier whether or not it qualifies for the audience segment to the Google-controlled server
+**** Each Chrome browser will processes each marketer's audience segmentation logic and send its unique identifier whether or not it qualifies for the audience segment to the Google-controlled server
 **** The Google-controlled server will count distinct number of identifiers belong to each audience segment
 ***** If the number of identifiers exceeds a Google-defined threshold, then this server will notify these browsers that they may use such audience segments for auction logic
 * '''Pre-auction Auction Desirability Logic'''
@@ Line 21: / Line 22: @@
 ** Each Chrome browser will separately request information from a Google-controlled trusted server to fetch marketer-specific desirability logic
 *** The Google-controlled trusted server will apply the marketer desirability logic to generate a bid for each combination of ad size, audience information and context information per campaign independent of current context
 * '''Pre-auction Publisher ad slot implementation'''
@@ Line 26: / Line 29: @@
 *** After the experiment phase, the Fenced Frame will not communicate any information about the winning ad to the publisher
 ** Publishers will load into the Chrome browser logic called "[[Worklet|worklets]]" to select which bid response will win the on-device auction
 *** Publisher logic can adjust desirability of each bid response, based on price and other factors
 **** Publisher desirability logic can filter which marketer buying platforms can compete in the auction
@@ Line 41: / Line 45: @@
 * '''Post-auction'''
-** During the experiment phase, the Chrome browser will send reporting data to per-specified publisher and buyer end points with event level data as to the outcome of the auction
+** During the experiment phase, the Chrome browser will send reporting data to pre-specified publisher and buyer end points with event level data as to the outcome of the auction
 *** After the experiment phase, the Chrome browser will not send event-level data to the publisher or marketer
 *** In neither phase, will the Fenced Frame allow the publisher or buyer browser identifiers to be associated with the event-level data
 ** Marketer buying platforms that lose auctions will get access to aggregate metrics on some yet to be determined, time-delayed basis