Bitnami MediaWiki - User contributions [en]

Fenced Frames

2021-07-19T16:26:40Z

Bleparmentier:

== Overview ==
Google's Fenced Frames loads ads in a separate container that dissociates information within the container from the parent page.<ref>https://github.com/shivanigithub/fenced-frame/</ref>

Fenced Frames are designed to address short comings in other Privacy Sandbox proposals, such as providing support for:

* [[Interest Based Advertising]]
* [[Conversion]] Lift measurement studies
* Granting unpartitioned storage access without impairing user experience via a permission prompt
* Cross-site embedded content

Fenced Frames will allow read-only access to cross-site information (e.g., audience segments, membership within an A/B experiment, access to cross-site conversion lift measurement). The Fenced Frame will only have network access beyond the web client, when initiated by a user (e.g., a click).

Chrome recommends caching embedded content to eliminate content access requests at run-time, which thus requires all permutations of personalization logic to be pre-rendered and available to local storage. Chrome calls this pre-rendered content "web bundles".

Chrome opened the door to communication toward "trusted servers" as an alternative to "web bundles", but did not elaborate on the requirements of such servers.

Note: Google has made no commitment that it will rely only on Fenced Frames to monetize its own web properties.

== Impact ==
By removing communication between the container and the parent page, publishers lose monitoring and control over this content.

Advertiser also loose the ability to know where, when and at what precise cost his ads are rendered

Fenced Frames suggests that Chrome will allow people choice to store information in their browser that can be used across different sites. "On user activation / [Fenced Frame will have] Full network access, read/write unpartitioned storage (if requested [from the user)"<ref>https://github.com/shivanigithub/fenced-frame/</ref> However, a per ad slot pop-up dialog seems like a poor user experience.

If the parent page cannot know or communicate information into Fenced Frame, it is unclear how resizing, scrolling or other user actions in the parent page will avoid causing a poor user experience with the content within the frame.

== Regulator Perspectives ==
The UK CMA noted (5.43) that should Google impair the ability of publishers and their marketer customers from understanding what content is being delivered where, to which audiences at which time, similar to other Privacy Sandbox proposals, Google's Fenced Frame proposal would:

# "lead to brand safety concerns,"
# impair "the ability of publishers to control, measure, and optimise content on their website,"
# lower the value marketers would ascribe to publisher inventory, given the same in real-time control, measurement and optimization impairments to "the advertiser from knowing on which publisher inventory its ad content is being placed," and
# given Google's extensive owned and operated properties would give it an advantage over rivals, on account of Google continuing to have access to granular real-time feedback information and unimpeded insight into the content on their pages.<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf</ref>

== References ==

<references />

[[Category:Glossary|Fenced Frames]]
[[Category:Privacy Sandbox|Fenced Frames]]

Turtledove

2021-07-12T14:07:18Z

Bleparmentier:

== Overview ==
The goal of Google's [[:Category:Privacy Sandbox|Privacy Sandbox]] is prevent marketers from engaging a particular audience in a particular context.<ref>https://github.com/michaelkleber/turtledove</ref>

TURTLEDOVE (“Two Uncorrelated Requests, Then Locally-Executed Decision On Victory”) proposal attempts to enable consumer retargeting without any marketers receiving any identifier.<ref>https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers</ref>

The proposed mechanism requires the web client to store some the attribute information marketers would want to use as an input into audience creation or auction management. As the name implies, the web client performs two separate local auctions based solely on context or almost solely on audience information. In the audience auction, some contextual information can be sent inside the browser to select ads, but is extremely limited by the complexity of having everything in a javascript code. The winner of these is sent to [[Fenced Frames|Fenced Frame]] ad slot on the publisher.

Google has suggested measuring the effectiveness of TURTLEDOVE proposal under the [[Fledge]] project.

== Impact ==
TURTLEDOVE removes transparency and control from publishers, by requiring the final auction in a given ad slot to be conducted by Google.
In addition to removing price transparency and introducing a time-delay to publishers in how well their websites are performing, TURTLEDOVE also impacts publishers ability to appropriately understanding and managing:

Traffic quality (TQ) - is this a legitimate request from a real user or [[Non-human Traffic|non-human traffic]]?

DSP qualification - which DSPs are interested in this request?

Bid solicitation - which DSPs will place a bid on this request?

Ad Quality (AQ) - which bids are eligible given the publisher's requirements?

Valuation - which bid is most valuable to the publisher at this moment?<ref>https://github.com/JoelPM/prebid-td/</ref>

Another potential impact of removing this information is a degraded end user experience.

Because TURTLEDOVE mandates the browser determines the final auction and relies on Fenced Frames, publishers cannot compare in real-time the monetization of the ad slot by Google vs competing ads sourced via other mechanisms. For example, if a publisher has other demand sources, such as an internal sales team, these will need to forward their highest desirable ad to Google for it to compare against the winning ad among the context-only ad and the audience-only ad it processes within the auction.

== Regulator Perspectives ==
The UK CMA noted (5.42, 5.74-75) TURTLEDOVE would give disadvantage Google's rivals for the following reasons:

# Google would have "full and unique visibility of the interest groups to which users belong"
# "Google would determine the minimum size of these interest groups and, in so doing, rival publishers and ad tech providers would not be able to compete to offer their unique value proposition to advertisers"
# Google "could have access to more granular user interest data and therefore have a competitive advantage over rivals in the provision of retargeting services to advertisers."
# Share confidential information with Google's consumer browser software, could create a conflict of interest given Google's DSP would "have visibility of its competitors' bidding strategies"<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf</ref>

Note: Google has made no commitment that it will rely only on TURTLEDOVE to monetize its own web properties.

== Open Questions ==
* What is the impact on web experiences given many client devices do not have the same processing power of the servers that currently select which content to render?
* How does the local client auction support publisher custom logic, such as factors other than price to select which ad to render?

== References ==

<references />

[[Category:Glossary|Turtledove]]
[[Category:Privacy Sandbox|Turtledove]]

Fledge

2021-03-01T08:31:00Z

Bleparmentier:

Google's First Locally-Executed Decision over Groups Experiment (FLEDGE) is a proposal to measure the effectiveness of Google's [[Turtledove]] auction mechanism as being a viable replacement for the interoperable identifiers that support the decentralized, open web.<ref>https://github.com/WICG/turtledove/blob/master/FLEDGE.md</ref>

FLEDGE has a goal to quantify the economic impact of [[Turtledove]] on publishers.

== Experiment Design ==
FLEDGE will rely upon the following steps:

* '''Pre-auction Audience Segmentation'''
** Marketers will periodically (maximum of once per day in this experiment) send two sets of information to a Google-specified endpoint
*** The mechanics of sending this logic information are described by their forthcoming documentation on [[Worklet|worklets]].
*** 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 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 the periodic refresh of JS.
**** Each audience segment will have a maximum lifespan of 30 days

* '''Pre-auction Auction Desirability Logic'''
** In addition to audience segmentation logic, marketers will send logic to determines marketer auction desirability
*** Marketer-specific desirability logic can include ad size, publisher domain, prior frequency of exposure to a give set of ads, and audience segmentation
*** Marketers will also send budget information per campaign to a Google-controlled trusted server
** 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
** Publishers may conduct an out-of-band creative review process to pre-approve particular creatives
*** Chrome browser will not allow publishers to render ads that have previously been otherwise eligible to win auctions for a minimum number of distinct browser identifiers, thus this is the second set of browser information that must be sent to a Google-controlled server to compute distinct counts

* '''Pre-auction Publisher ad slot implementation'''
** Publishers will implement a [[Fenced Frames|Fenced Frame]] to query the browser APIs for ads and render the resulting ad
*** 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 MUST whitelist each buyer's access to audience segments
*** 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
**** Publisher can also apply an out-of-band creative review process to be used as an input into this desirability logic

* '''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.
** 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

* '''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"
*** 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

== Impact ==
Given FLEDGE's design, the following are impacts to marketing effectiveness will not be measured:

* [[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 ==
* Marketer Effectiveness
** What is the acceptable level of impairment to marketing effectiveness, such that marketers will not reduce payments to publishers?
** 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?
** 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 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?
** 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?
** 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?
* 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?
** 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?
* Ecosystem Impact
** 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?
***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?
** 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 ==

[[Teetar]]

== References ==

<references />

[[Category:Glossary|Fledge]]
[[Category:Privacy Sandbox|Fledge]]

User:Bleparmentier

2021-03-01T08:10:10Z

Bleparmentier: create user page