From 4c7fc11fa5173df0e5892e0e20e4e2fb81ddcaa0 Mon Sep 17 00:00:00 2001 From: Paul Marcilhacy Date: Tue, 30 Jun 2020 10:54:16 +0200 Subject: [PATCH 1/2] add SPARROW's answers to the list of use-cases in the community proposal column. --- support_for_advertising_use_cases.md | 70 ++++++++++++++-------------- 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/support_for_advertising_use_cases.md b/support_for_advertising_use_cases.md index 8925493..d13376c 100644 --- a/support_for_advertising_use_cases.md +++ b/support_for_advertising_use_cases.md @@ -66,21 +66,21 @@ The ads industry has endeavored to find good ways of answering these basic quest | Use-case | Chrome | Safari | Community Proposals | |----------|--------|--------|---------------------| -| [Impression and Viewability Measurement](#impression-and-viewability-measurement) | There should be no conflict with Chrome’s proposed “[Privacy Model for the Web](https://github.com/michaelkleber/privacy-model)”. First parties should still be capable of measuring that the ads displayed on their own properties entered the viewport, that images and video were loaded, how much time they spent in the viewport, etc. None of this requires joining up user identity across multiple domains. The only possible complication that might arise would be with "blind rendering" as described in proposals like "[TURTLEDOVE](https://github.com/michaelkleber/turtledove)" and “[PETREL](https://github.com/w3c/web-advertising/blob/master/PETREL.md)”. Here, the publisher would have restricted access to the ad being rendered and we will have to discuss the feasibility of "viewability" measurement. There is a discussion on this [GitHub issue](https://github.com/csharrison/aggregate-reporting-api/issues/10). | Similar answer as that for Chrome. This should not be in conflict with Webkit's [Tracking Prevention Policy](https://webkit.org/tracking-prevention-policy/) given the measurement is entirely within the scope of a single publisher website. | | +| [Impression and Viewability Measurement](#impression-and-viewability-measurement) | There should be no conflict with Chrome’s proposed “[Privacy Model for the Web](https://github.com/michaelkleber/privacy-model)”. First parties should still be capable of measuring that the ads displayed on their own properties entered the viewport, that images and video were loaded, how much time they spent in the viewport, etc. None of this requires joining up user identity across multiple domains. The only possible complication that might arise would be with "blind rendering" as described in proposals like "[TURTLEDOVE](https://github.com/michaelkleber/turtledove)" and “[PETREL](https://github.com/w3c/web-advertising/blob/master/PETREL.md)”. Here, the publisher would have restricted access to the ad being rendered and we will have to discuss the feasibility of "viewability" measurement. There is a discussion on this [GitHub issue](https://github.com/csharrison/aggregate-reporting-api/issues/10). | Similar answer as that for Chrome. This should not be in conflict with Webkit's [Tracking Prevention Policy](https://webkit.org/tracking-prevention-policy/) given the measurement is entirely within the scope of a single publisher website. | SPARROW: The aggregated report (Cf. [here](https://github.com/BasileLeparmentier/SPARROW/blob/master/Reporting_in_SPARROW.md)) can be leveraged for that purpose. | | [Audience Verification](#audience-verification) | No support | No support | No Support | | -| [Conversion Lift Measurement](#conversion-lift-measurement) | A [section of the Conversion Measurement with Aggregation proposal](https://github.com/WICG/conversion-measurement-api/blob/master/AGGREGATE.md#view-through-conversions) describes explicit support for view through conversions, which should be sufficient to support lift measurement using experiments on a first party site (e.g. when using a first-party identifier to decide which experiment branch a person is in). | No support | Facebook proposal for “[Private Lift Measurement](https://github.com/w3c/web-advertising/blob/master/private-lift-measurement-conceptual-overview.md)” | +| [Conversion Lift Measurement](#conversion-lift-measurement) | A [section of the Conversion Measurement with Aggregation proposal](https://github.com/WICG/conversion-measurement-api/blob/master/AGGREGATE.md#view-through-conversions) describes explicit support for view through conversions, which should be sufficient to support lift measurement using experiments on a first party site (e.g. when using a first-party identifier to decide which experiment branch a person is in). | No support | Facebook proposal for “[Private Lift Measurement](https://github.com/w3c/web-advertising/blob/master/private-lift-measurement-conceptual-overview.md)”

SPARROW : SPARROW served ads come with a semi-stable bucket_id allowing to do ABTest at the user level, transferred by the GATEKEEPER to the advertiser. This allows for precise ABTest measurement. | | [Brand Lift Measurement](#brand-lift-measurement) | No support | No support | No support | | -| [Click-through attribution](#click-through-and-view-through-attribution-heuristics) | Proposal: “[Click Through Conversion-Measurement Event-level API](https://github.com/WICG/conversion-measurement-api)” | Proposal: “[Private Click Measurement API](https://github.com/WICG/ad-click-attribution)” | -| [View-through attribution](#click-through-and-view-through-attribution-heuristics) | A [section of the Conversion Measurement with Aggregation proposal](https://github.com/WICG/conversion-measurement-api/blob/master/AGGREGATE.md#view-through-conversions) describes explicit support for view through conversions. | No support | | -| [Multi-touch attribution](#multi-touch-attribution) | The [Event-level API](https://github.com/WICG/conversion-measurement-api/blob/master/README.md) proposal covers last-click attribution. A section of the [Conversion Measurement with Aggregation](https://github.com/WICG/conversion-measurement-api/blob/master/AGGREGATE.md#multi-touch-attribution-mta) proposal describes support for some built-in multi-touch models, and acknowledges that measurement providers writing their own models would be good to support if technically feasible. | No support | Facebook proposal for “[Privacy-Preserving Multi-Touch-Attribution and Cross-Publisher Lift Measurement](https://github.com/w3c/web-advertising/blob/master/privacy_preserving_multi_touch_attribution_and_cross_publisher_lift_measurement.md)” | +| [Click-through attribution](#click-through-and-view-through-attribution-heuristics) | Proposal: “[Click Through Conversion-Measurement Event-level API](https://github.com/WICG/conversion-measurement-api)” | Proposal: “[Private Click Measurement API](https://github.com/WICG/ad-click-attribution)” | SPARROW: All click-through attribution rules are available as of today thanks to the ranked k-anonymous granular report described [here](https://github.com/BasileLeparmentier/SPARROW/blob/master/Reporting_in_SPARROW.md) | +| [View-through attribution](#click-through-and-view-through-attribution-heuristics) | A [section of the Conversion Measurement with Aggregation proposal](https://github.com/WICG/conversion-measurement-api/blob/master/AGGREGATE.md#view-through-conversions) describes explicit support for view through conversions. | No support | SPARROW: View-through attribution is available for the advertisers thanks to the ranked k-anonymous granular report described [here](https://github.com/BasileLeparmentier/SPARROW/blob/master/Reporting_in_SPARROW.md) | +| [Multi-touch attribution](#multi-touch-attribution) | The [Event-level API](https://github.com/WICG/conversion-measurement-api/blob/master/README.md) proposal covers last-click attribution. A section of the [Conversion Measurement with Aggregation](https://github.com/WICG/conversion-measurement-api/blob/master/AGGREGATE.md#multi-touch-attribution-mta) proposal describes support for some built-in multi-touch models, and acknowledges that measurement providers writing their own models would be good to support if technically feasible. | No support | Facebook proposal for “[Privacy-Preserving Multi-Touch-Attribution and Cross-Publisher Lift Measurement](https://github.com/w3c/web-advertising/blob/master/privacy_preserving_multi_touch_attribution_and_cross_publisher_lift_measurement.md)”

SPARROW: Multi-toucht attribution available as of today thanks to the ranked k-anonymous granular report described [here](https://github.com/BasileLeparmentier/SPARROW/blob/master/Reporting_in_SPARROW.md)| | [Cross Browser / Cross Device Measurement](#cross-browser--cross-device-measurement) | No support | No support | Facebook proposal for “[Cross Browser Anonymous Conversion Reporting](https://github.com/w3c/web-advertising/blob/master/cross-browser-anonymous-conversion-reporting.md)” | -| [Conversion Fraud](#conversion-fraud) | A section of the [Multi-Browser Aggregation Service Explainer](https://github.com/WICG/conversion-measurement-api/blob/master/SERVICE.md#authenticating-inputs) describes using a service that includes an authentication mechanism. This use case is also being explored for the event level API in this [GitHub Issue](https://github.com/WICG/conversion-measurement-api/issues/13). | Confirmation this is a use-case Safari cares about addressing. In the process of collaboratively designing a solution on this [GitHub Issue](https://github.com/WICG/ad-click-attribution/issues/27). | Facebook proposal for “[Private Fraud Prevention](https://github.com/siyengar/private-fraud-prevention)” | -| [Click Flooding](#click-flooding) | No solutions yet for this problem. However, lift measurement could be a potential way of measuring this problem. This might be supported by the “[Aggregate Reporting API](https://github.com/csharrison/aggregate-reporting-api)”. | No solutions yet for this problem. | Facebook proposal for “[Private Lift Measurement](https://github.com/w3c/web-advertising/blob/master/private-lift-measurement-conceptual-overview.md)” a potential way of measuring this problem | +| [Conversion Fraud](#conversion-fraud) | A section of the [Multi-Browser Aggregation Service Explainer](https://github.com/WICG/conversion-measurement-api/blob/master/SERVICE.md#authenticating-inputs) describes using a service that includes an authentication mechanism. This use case is also being explored for the event level API in this [GitHub Issue](https://github.com/WICG/conversion-measurement-api/issues/13). | Confirmation this is a use-case Safari cares about addressing. In the process of collaboratively designing a solution on this [GitHub Issue](https://github.com/WICG/ad-click-attribution/issues/27). | Facebook proposal for “[Private Fraud Prevention](https://github.com/siyengar/private-fraud-prevention)”

SPARROW : Thanks to exact reporting, it will be possible to link conversion to both an interest group and a publisher. It will also be possible to have user-level granularity on the website, helping to spot fraudulent activity. | +| [Click Flooding](#click-flooding) | No solutions yet for this problem. However, lift measurement could be a potential way of measuring this problem. This might be supported by the “[Aggregate Reporting API](https://github.com/csharrison/aggregate-reporting-api)”. | No solutions yet for this problem. | Facebook proposal for “[Private Lift Measurement](https://github.com/w3c/web-advertising/blob/master/private-lift-measurement-conceptual-overview.md)” a potential way of measuring this problem.

SPARROW: Advertisers can use ranked k-anonymous granular report in a limited fashion. For massive fraud events, the aggregated reporting may be leveraged in real time. However, the necessary delay and partial information reduce the capacity to act quickly. Gatekeepers might have to become a first line of defense. | | [Malicious Browser Extensions](#malicious-browser-extensions) | No solutions yet for this problem. | No solutions yet for this problem. | | | [Malicious Mobile Apps](#malicious-mobile-apps) | No solutions yet for this problem. | No solutions yet for this problem. | | | [Malicious Browsers](#malicious-browsers) | No solutions yet for this problem. | No solutions yet for this problem. | | -| [Brand Safety](#brand-safety) | There should be no conflict with Chrome’s proposed “[Privacy Model for the Web](https://github.com/michaelkleber/privacy-model)”. When an ad targets an interest group, it is served as a web package with all subresources included and the detail of which interest group won lets you trace down the problematic campaign. However, the ads that were printed less than k times (k being the reporting threshold) would still pose a threat as they would remain undetectable because not reported. | Similar answer as that for Chrome. This should not be in conflict with Webkit's [Tracking Prevention Policy](https://webkit.org/tracking-prevention-policy/) given the measurement is entirely within the scope of a single publisher website. | | -| [Billing Transaprency](#billing-transaprency) | In TURTLEDOVE, the browser is the sole owner of billing information. | | | +| [Brand Safety](#brand-safety) | There should be no conflict with Chrome’s proposed “[Privacy Model for the Web](https://github.com/michaelkleber/privacy-model)”. When an ad targets an interest group, it is served as a web package with all subresources included and the detail of which interest group won lets you trace down the problematic campaign. However, the ads that were printed less than k times (k being the reporting threshold) would still pose a threat as they would remain undetectable because not reported. | Similar answer as that for Chrome. This should not be in conflict with Webkit's [Tracking Prevention Policy](https://webkit.org/tracking-prevention-policy/) given the measurement is entirely within the scope of a single publisher website. | SPARROW: At bidding time, the gatekeeper follows the advertiser instructions to ensure brand safety. Granular reporting allows the advertiser to audit the brand safety and to be assured that the rules were properly enforced. | +| [Billing Transaprency](#billing-transaprency) | In TURTLEDOVE, the browser is the sole owner of billing information. | | SPARROW : The aggregated report can be leveraged for billing. An especially low noise / noiseless aggregated report could be provided daily for the specific billing purposes. SPARROW enables two parties, one on Publisher side and one on Advertiser side, to generate that same report, thus enabling cross-data comparison and disputes resolution. | ## Specialized Advertiser Needs @@ -114,14 +114,14 @@ These are use-cases that only apply to a (possibly large) subset of advertisers. |----------|--------|--------|---------------------| | [Audience definition](#audience-definition) | | | | | [Exclusion Targeting](#exclusion-targeting) | Acknowledgement that this is a valuable use-case and a link to Facebook’s PETREL proposal on this [GitHub Issue](https://github.com/michaelkleber/turtledove/issues/3) | No support | Facebook proposal for “[Private Exclusion Targeting Rendered Exclusively Locally (PETREL)](https://github.com/w3c/web-advertising/blob/master/PETREL.md)” | -| [Lookalike Targeting](#lookalike-targeting) | Might be possible to achieve limited support by leveraging “[Federated Learning of Cohorts (FLoC)](https://github.com/jkarlin/floc)”. Might require an extension to TURTLEDOVE offering a new way to create interest groups, which Chrome indicated support for in [this issue](https://github.com/michaelkleber/turtledove/issues/26). | No support | Facebook proposal for "[Privacy Preserving Lookalike Audience Targeting](privacy_preserving_lookalike_audience_targeting.md)" | -| [Retargeting](#retargeting) | Proposal: "[Two Uncorrelated Requests, Then Locally-Executed Decision On Victory (TURTLEDOVE)](https://github.com/michaelkleber/turtledove)" | No support | | -| [Display and target environment](#display-and-target-environment) | Supported in TURTLEDOVE thanks to the contextual request. Ability to use this together with interest group request limited by the JS complexity. | | | -| [Frequency Capping](#frequency-capping) / [Frequency Optimization](#frequency-optimization) | For ads served via TURTLEDOVE interest-group targeting, the proposal offers a way to [handle frequency capping on-device](https://github.com/michaelkleber/turtledove#on-device-auction). For other types of targeting, while it will not be possible to enforce a hard "frequency-cap" across multiple websites, it might be possible to calibrate a target average frequency model. See discussion about how to do this on the explainer for the [Aggregate Reporting API](https://github.com/csharrison/aggregate-reporting-api#advanced-example-calibrating-a-frequency-capping-model). | No support | | -| [Businesses with Multiple Domains](#businesses-with-multiple-domains) | Proposal: "[First Party Sets](https://github.com/krgovind/first-party-sets/)" | Some discussion in this [GitHub issue](https://github.com/krgovind/first-party-sets/issues/6) indicates weak support for at least the country-specific eTLD use-case, but various concerns with the current "First Party Sets" proposal. | | +| [Lookalike Targeting](#lookalike-targeting) | Might be possible to achieve limited support by leveraging “[Federated Learning of Cohorts (FLoC)](https://github.com/jkarlin/floc)”. Might require an extension to TURTLEDOVE offering a new way to create interest groups, which Chrome indicated support for in [this issue](https://github.com/michaelkleber/turtledove/issues/26). | No support | Facebook proposal for "[Privacy Preserving Lookalike Audience Targeting](privacy_preserving_lookalike_audience_targeting.md)"

SPARROW: Lookalike audiences can be defined using interest groups and meta-interest groups such as defined in [this document](https://github.com/BasileLeparmentier/SPARROW/blob/master/Interest_groups_audiences_new_building_blocks.md#lookalike-targeting). | +| [Retargeting](#retargeting) | Proposal: "[Two Uncorrelated Requests, Then Locally-Executed Decision On Victory (TURTLEDOVE)](https://github.com/michaelkleber/turtledove)" | No support | SPARROW: SPARROW Proposal extends TURTLEDOVE to provide more control, performance whilst preserving user privacy. | +| [Display and target environment](#display-and-target-environment) | Supported in TURTLEDOVE thanks to the contextual request. Ability to use this together with interest group request limited by the JS complexity. | | SPARROW: The gatekeeper is responsible for enforcing the policy defined by the advertiser. | +| [Frequency Capping](#frequency-capping) / [Frequency Optimization](#frequency-optimization) | For ads served via TURTLEDOVE interest-group targeting, the proposal offers a way to [handle frequency capping on-device](https://github.com/michaelkleber/turtledove#on-device-auction). For other types of targeting, while it will not be possible to enforce a hard "frequency-cap" across multiple websites, it might be possible to calibrate a target average frequency model. See discussion about how to do this on the explainer for the [Aggregate Reporting API](https://github.com/csharrison/aggregate-reporting-api#advanced-example-calibrating-a-frequency-capping-model). | No support | SPARROW: As TURTLEDOVE, SPARROW can handle hard frequency capping (not transferred by the gatekeeper), allowing to stop bidding. | +| [Businesses with Multiple Domains](#businesses-with-multiple-domains) | Proposal: "[First Party Sets](https://github.com/krgovind/first-party-sets/)" | Some discussion in this [GitHub issue](https://github.com/krgovind/first-party-sets/issues/6) indicates weak support for at least the country-specific eTLD use-case, but various concerns with the current "First Party Sets" proposal. | SPARROW: "First Party Sets" + ability to add users to the same interest group via different domains ("shared" interest groups). Note that whilst it's possible to add the user to the same interest from multiple domains, no cross-domain information can be used to define the interest group. (Cf. [here](https://github.com/w3c/web-advertising/blob/master/support_for_advertising_use_cases.md)) | | [Collaborative Ads](#collaborative-ads) / [Dynamic Ads](#dynamic-ads) | Some discussion in this [GitHub issue](https://github.com/WICG/conversion-measurement-api/issues/32). No solutions or even strong acknowledgement of the importance of this use-case yet. | Some discussion in this [GitHub issue](https://github.com/WICG/ad-click-attribution/issues/36). Good collaborative problem solving going on. No firm solution yet. | Facebook proposal for “[Conversion Filters](https://github.com/w3c/web-advertising/blob/master/conversion-filters.md)” | | [Email Marketing](#email-marketing) | unclear | unclear | | -| [Real time spend management](#real-time-spend-management) | High latency in TURTLEDOVE as the javascript updates have unknown frequency, and reporting is delayed in the [Aggregate Reporting API](https://github.com/csharrison/aggregate-reporting-api#advanced-example-calibrating-a-frequency-capping-model) | Supported as ads are not done in opaque iframe and bidding is not done remotely | | +| [Real time spend management](#real-time-spend-management) | High latency in TURTLEDOVE as the javascript updates have unknown frequency, and reporting is delayed in the [Aggregate Reporting API](https://github.com/csharrison/aggregate-reporting-api#advanced-example-calibrating-a-frequency-capping-model) | Supported as ads are not done in opaque iframe and bidding is not done remotely | SPARROW: Handled with both near real-time aggregated report, and near real-time update of the bidding function. | | [Product availability management](#product-availability-management) | More details required. | | | | [Price management](#price-management) | More details required. | | | | [Products promotion management](#products-promotion-management) | More details required. | | | @@ -146,12 +146,12 @@ These are core essentials ad networks need to deliver value to advertisers. | Use-case | Chrome | Safari | Community Proposals | |----------|--------|--------|---------------------| -| [P(click \| impression)](#click-through-rate-ctr-model-pclick--impression) | There is no conflict with Chrome’s proposed “[Privacy Model for the Web](https://github.com/michaelkleber/privacy-model)”. Should be possible to use 1st party cookies to tie together multiple sessions from the same browser on the same website. | [isLoggedIn](https://github.com/WebKit/explainers/tree/master/IsLoggedIn) may potentially pose problems here for websites without login. Limited storage may make it hard to tie together multiple sessions from the same person. | | -| [P(conversion \| click)](#conversion-rate-cvr-model-pconversion--click) | This is a stated goal of Chrome’s “[Click Through Conversion-Measurement Event-level API](https://github.com/WICG/conversion-measurement-api)” | Not possible to train an ML model. | | -| [Post-view attribution: P(conversion \| impression)](#post-view-attribution-pconversion--impression) | Not possible to train an ML model. However, It may be possible to use the "Aggregate Reporting API" to obtain average conversion value measurement for very coarse-grain buckets of people. This could be used to perform calibration at this coarse-grain bucketed level. | Not possible to train an ML model. | | +| [P(click \| impression)](#click-through-rate-ctr-model-pclick--impression) | There is no conflict with Chrome’s proposed “[Privacy Model for the Web](https://github.com/michaelkleber/privacy-model)”. Should be possible to use 1st party cookies to tie together multiple sessions from the same browser on the same website. | [isLoggedIn](https://github.com/WebKit/explainers/tree/master/IsLoggedIn) may potentially pose problems here for websites without login. Limited storage may make it hard to tie together multiple sessions from the same person. | SPARROW: Exactly same capabilities as today, with user-level data condensed into interest group-level data. | +| [P(conversion \| click)](#conversion-rate-cvr-model-pconversion--click) | This is a stated goal of Chrome’s “[Click Through Conversion-Measurement Event-level API](https://github.com/WICG/conversion-measurement-api)” | Not possible to train an ML model. | SPARROW: Exactly same capabilities as today, with user-level data condensed into interest group-level data. | +| [Post-view attribution: P(conversion \| impression)](#post-view-attribution-pconversion--impression) | Not possible to train an ML model. However, It may be possible to use the "Aggregate Reporting API" to obtain average conversion value measurement for very coarse-grain buckets of people. This could be used to perform calibration at this coarse-grain bucketed level. | Not possible to train an ML model. | SPARROW: Exactly same capabilities as today, with user-level data condensed into interest group-level data. | | [P(Display \| Request)](#pdisplay--request) | No support. | Not possible to train an ML model. | | -| [Return on Ad Spend (ROAS) optimization](#return-on-ad-spend-roas-optimization) | Not possible to train an ML model. However, It may be possible to use the “[Aggregate Reporting API](https://github.com/csharrison/aggregate-reporting-api)” to obtain average conversion value measurement for very coarse-grain buckets of people. This could be used to perform calibration at this coarse-grain bucketed level. | Not possible to train an ML model. | | -| [Multiple Targets optimization](#multiple-targets-optimization) | No support | Not possible to train an ML model. | | +| [Return on Ad Spend (ROAS) optimization](#return-on-ad-spend-roas-optimization) | Not possible to train an ML model. However, It may be possible to use the “[Aggregate Reporting API](https://github.com/csharrison/aggregate-reporting-api)” to obtain average conversion value measurement for very coarse-grain buckets of people. This could be used to perform calibration at this coarse-grain bucketed level. | Not possible to train an ML model. | SPARROW: Exactly same capabilities as today, with user-level data condensed into interest group-level data. | +| [Multiple Targets optimization](#multiple-targets-optimization) | No support | Not possible to train an ML model. | SPARROW: k-anonymous granular report for optimization (Granular and low-noise) reporting allows for in-house attribution and optimize for multiple targets at once. | ## Specialized Ad Network Needs @@ -160,8 +160,8 @@ These are core essentials ad networks need to deliver value to advertisers. | Use-case | Chrome | Safari | Community Proposals | |----------|--------|--------|---------------------| -| [Audience Selling](#audience-selling) | Probably possible under "[TURTLEDOVE](https://github.com/michaelkleber/turtledove)" by defining interest groups usable by other parties. | No support | | -| [CRM Targeting](#crm-targeting) | possible if done via interest groups under "[TURTLEDOVE](https://github.com/michaelkleber/turtledove)" | No support | | +| [Audience Selling](#audience-selling) | Probably possible under "[TURTLEDOVE](https://github.com/michaelkleber/turtledove)" by defining interest groups usable by other parties. | No support | SPARROW: interest groups are used to define audiences. These interest groups are defined at single-domain level (even though an interest group can be shared across domains) but can be used for ads targeting another domain. Please cf. [here](https://github.com/BasileLeparmentier/SPARROW/blob/master/Interest_groups_audiences_new_building_blocks.md) for more details. | +| [CRM Targeting](#crm-targeting) | possible if done via interest groups under "[TURTLEDOVE](https://github.com/michaelkleber/turtledove)" | No support | SPARROW: Same as in TURTLEDOVE. | # Publisher Needs @@ -177,7 +177,7 @@ These use-cases are more focused on the publisher's perspective. - [Click-through Site Personalization](#click-through-site-personalization) - [On-site Sponsored Product](#on-site-sponsored-product) - [Search](#search) -- [Ad Safety](#ad-safety) +- [Ad Quality](#ad-quality) - [Advertisers exclusion](#advertisers-exclusion) - [Revenue management](#revenue-management) @@ -185,15 +185,15 @@ These use-cases are more focused on the publisher's perspective. |----------|--------|--------|---------------------| | [Serving relevant ads (non-logged in publishers)](#serving-relevant-ads) | Proposal: “[Federated Learning of Cohorts (FloC)](https://github.com/jkarlin/floc)”. | No support | | | [Running an auction (non-logged in publishers)](#running-an-auction) | The TURTLEDOVE proposal is built around a server-side auction for contextually-targeted ads, and then an in-browser auction for user interest targeting. [This GitHub issue comment](https://github.com/michaelkleber/turtledove/issues/20#issuecomment-602800377) describes the RTB flow in some more detail. | No support | Verizon / Oath [write-up of this use-case](https://github.com/w3c/web-advertising/blob/master/rtb-use-case.md) | -| [Affiliate Marketing](#affiliate-marketing) | It may be possible to use a combination of the “[Click Through Conversion-Measurement Event-level API](https://github.com/WICG/conversion-measurement-api)” and the “[Aggregate Reporting API](https://github.com/csharrison/aggregate-reporting-api)” to get a first-order estimate of the number of the number of conversions driven by an Affiliate marketing link, but questions remain about “returns” and fraud. | Extremely limited support possible with the “[Private Click Measurement API](https://github.com/WICG/ad-click-attribution)”, but questions remain about “returns” and fraud. | | +| [Affiliate Marketing](#affiliate-marketing) | It may be possible to use a combination of the “[Click Through Conversion-Measurement Event-level API](https://github.com/WICG/conversion-measurement-api)” and the “[Aggregate Reporting API](https://github.com/csharrison/aggregate-reporting-api)” to get a first-order estimate of the number of the number of conversions driven by an Affiliate marketing link, but questions remain about “returns” and fraud. | Extremely limited support possible with the “[Private Click Measurement API](https://github.com/WICG/ad-click-attribution)”, but questions remain about “returns” and fraud. | SPARROW : possible as today with UTM source in the redirect link. | | [Federated Single Sign-on](#federated-single-sign-on) | Yes - Proposal: “[WebID](https://github.com/samuelgoto/WebID)”| Generally supportive as per [Tracking Prevention Policy](https://webkit.org/tracking-prevention-policy/) " "*We consider certain user actions, such as logging in to multiple first party websites or apps using the same account, to be implied consent to identifying the user as having the same identity in these multiple places*". Policy also acknowledges unintended impacts to federated SSO setups. General discussion in the context of the [Storage Access API](https://github.com/privacycg/storage-access) which is related but not targeted for this use-case (non-goal)| | | -| [View-through Site Personalization](#view-through-site-personalization) | No support | No support | | -| [Click-through Site Personalization](#click-through-site-personalization) | There should not be any conflict with Chrome's proposed “[Privacy Model for the Web](https://github.com/michaelkleber/privacy-model)” unless this mechanism is used to pass through high-entropy identifiers which could be used to tie user identity across websites. See PING's [Privacy Threat Model](https://w3cping.github.io/privacy-threat-model/#goal-transfer-userid). | Similar to Chrome, this should not fall afoul of Webkit's [Tracking Prevention Policy](https://webkit.org/tracking-prevention-policy/) unless high-entropy identifiers are being used to perform "navigational tracking". See PING's [Privacy Threat Model](https://w3cping.github.io/privacy-threat-model/#goal-transfer-userid). | | +| [View-through Site Personalization](#view-through-site-personalization) | No support | No support | SPARROW: No support | +| [Click-through Site Personalization](#click-through-site-personalization) | There should not be any conflict with Chrome's proposed “[Privacy Model for the Web](https://github.com/michaelkleber/privacy-model)” unless this mechanism is used to pass through high-entropy identifiers which could be used to tie user identity across websites. See PING's [Privacy Threat Model](https://w3cping.github.io/privacy-threat-model/#goal-transfer-userid). | Similar to Chrome, this should not fall afoul of Webkit's [Tracking Prevention Policy](https://webkit.org/tracking-prevention-policy/) unless high-entropy identifiers are being used to perform "navigational tracking". See PING's [Privacy Threat Model](https://w3cping.github.io/privacy-threat-model/#goal-transfer-userid). | SPARROW: Possible via URL decoration. If following a SPARROW targeted ad, this URL could technically not contain identifying information except the interest group linked to the winning ad. Personalization can therefore only be done at the publisher origin/interest group level. | |[On-site Sponsored Product](#on-site-sponsored-product)| There should not be any conflict with Chrome's proposed “[Privacy Model for the Web](https://github.com/michaelkleber/privacy-model)” | Similar answer as that for Chrome. This should not be in conflict with Webkit's Tracking Prevention Policy given the measurement is entirely within the scope of a single publisher website. | | |[Search](#search) | unclear, but relies a lot on contextual | unclear | | -| [Ad Safety](#ad-safety) | Very limited support as opaque iframe aggregated reporting allow for very little ex post audit. | No Support | | -| [Advertisers exclusion](#advertisers-exclusion) | Unclear. To be defined. | | | -| [Revenue management](#revenue-management) | Little support in TURTLEDOVE, as nor reporting nor updating bidding JavaScripts is not real-time. This means delays in both information and action, leading to very complex and inaccurate budget/revenue management. | | | +| [Ad Quality](#ad-quality) | Very limited support as opaque iframe aggregated reporting allow for very little ex post audit. | No Support | SPARROW: The Gatekeeper is reponsible for enforcing the publisher policy. The Gatekeeper could provide a service to ensure Ad Quality before the ad is displayed.
The aggregated report and Delayed served ads report can be leveraged for ex post ad quality audit. | +| [Advertisers exclusion](#advertisers-exclusion) | Unclear. To be defined. | | SPARROW: The gatekeeper is responsible for enforcing the policy. | +| [Revenue management](#revenue-management) | | | SPARROW: Supported thanks to aggregated reporting. | # User Needs @@ -205,9 +205,9 @@ These use-cases are more focused on the publisher's perspective. | Use-case | Chrome | Safari | Community Proposals | |----------|--------|--------|---------------------| -|[Why am I seeing this ad?](#why-am-i-seeing-this-ad)| Both the Chrome team and the Google ads team have on multiple occassions cited a desire show people an explanation of what caused an ad to appear. The TURTLEDOVE proposal specifically aims to provide people with an accurate answer as to why they are seeing a re-targeting ad. | No support. | | -|[Opt-out of an advertiser, category or product](#opt-out-of-an-advertiser-category-or-product)| Unclear | No support | | -|[Opt-out of a marketing service](#opt-out-of-a-marketing-service)| Supported | | | +|[Why am I seeing this ad?](#why-am-i-seeing-this-ad)| Both the Chrome team and the Google ads team have on multiple occassions cited a desire show people an explanation of what caused an ad to appear. The TURTLEDOVE proposal specifically aims to provide people with an accurate answer as to why they are seeing a re-targeting ad. | No support. | SPARROW: Same as in TURTLEDOVE. | +|[Opt-out of an advertiser, category or product](#opt-out-of-an-advertiser-category-or-product)| Unclear | No support | SPARROW: Same as in TURTLEDOVE. | +|[Opt-out of a marketing service](#opt-out-of-a-marketing-service)| | | | |[Seeing ads relevant to me](#seeing-ads-relevant-to-me)| Interest groups and contextual signals should help have relevant ads. | | | |[Smooth user experience](#smooth-user-experience)| More details required. Concerns about the size of the data to load, store and process in-browser. | | | @@ -660,12 +660,12 @@ Contrary to the other use cases mentioned above, the entire process from printin Advertisers use services like Google Shopping to advertise their products directly in Search Engines' results. -## Ad Safety +## Ad Quality Publishers usually consider that some ads contain inappropriate imagery, promote inappropriate products or messages they don't want to be associated with. Publisher usually maintain a "block-list" of advertisers/domains and forbid any ad coming from these. -**Publishers need the list of all of the redirecting domains of the ads that were printed on their real estate and access to the visual rendering of each ad, so that they can review this list from the perspective of "Ad Safety".** This reporting is used to investigate reported misconducts and update the block-list. +**Publishers need the list of all of the redirecting domains of the ads that were printed on their real estate and access to the visual rendering of each ad, so that they can review this list from the perspective of "Ad Quality".** This reporting is used to investigate reported misconducts and update the block-list. ## Advertisers exclusion @@ -699,4 +699,4 @@ As a user, I prefer to see ads that are relevant to me. ## Smooth user experience As a user, I do not want: - Ads to degrade my browsing experience, in term of navigation, e.g.: ads blocking access to content or slowing down page load. - - Ads to be annoying, e.g.: get to many times ads for the same product, or ads for products I already bought. + - Ads to be annoying, e.g.: get to many times ads for the same product, or ads for products I already bought. \ No newline at end of file From d21cc140248d635e5fc98dcb3caafc929c92b9ae Mon Sep 17 00:00:00 2001 From: Paul Marcilhacy Date: Fri, 3 Jul 2020 13:12:47 +0200 Subject: [PATCH 2/2] Clarify SPARROW's answer to several use-cases. --- support_for_advertising_use_cases.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/support_for_advertising_use_cases.md b/support_for_advertising_use_cases.md index d13376c..f2f62c1 100644 --- a/support_for_advertising_use_cases.md +++ b/support_for_advertising_use_cases.md @@ -71,16 +71,17 @@ The ads industry has endeavored to find good ways of answering these basic quest | [Conversion Lift Measurement](#conversion-lift-measurement) | A [section of the Conversion Measurement with Aggregation proposal](https://github.com/WICG/conversion-measurement-api/blob/master/AGGREGATE.md#view-through-conversions) describes explicit support for view through conversions, which should be sufficient to support lift measurement using experiments on a first party site (e.g. when using a first-party identifier to decide which experiment branch a person is in). | No support | Facebook proposal for “[Private Lift Measurement](https://github.com/w3c/web-advertising/blob/master/private-lift-measurement-conceptual-overview.md)”

SPARROW : SPARROW served ads come with a semi-stable bucket_id allowing to do ABTest at the user level, transferred by the GATEKEEPER to the advertiser. This allows for precise ABTest measurement. | | [Brand Lift Measurement](#brand-lift-measurement) | No support | No support | No support | | | [Click-through attribution](#click-through-and-view-through-attribution-heuristics) | Proposal: “[Click Through Conversion-Measurement Event-level API](https://github.com/WICG/conversion-measurement-api)” | Proposal: “[Private Click Measurement API](https://github.com/WICG/ad-click-attribution)” | SPARROW: All click-through attribution rules are available as of today thanks to the ranked k-anonymous granular report described [here](https://github.com/BasileLeparmentier/SPARROW/blob/master/Reporting_in_SPARROW.md) | -| [View-through attribution](#click-through-and-view-through-attribution-heuristics) | A [section of the Conversion Measurement with Aggregation proposal](https://github.com/WICG/conversion-measurement-api/blob/master/AGGREGATE.md#view-through-conversions) describes explicit support for view through conversions. | No support | SPARROW: View-through attribution is available for the advertisers thanks to the ranked k-anonymous granular report described [here](https://github.com/BasileLeparmentier/SPARROW/blob/master/Reporting_in_SPARROW.md) | -| [Multi-touch attribution](#multi-touch-attribution) | The [Event-level API](https://github.com/WICG/conversion-measurement-api/blob/master/README.md) proposal covers last-click attribution. A section of the [Conversion Measurement with Aggregation](https://github.com/WICG/conversion-measurement-api/blob/master/AGGREGATE.md#multi-touch-attribution-mta) proposal describes support for some built-in multi-touch models, and acknowledges that measurement providers writing their own models would be good to support if technically feasible. | No support | Facebook proposal for “[Privacy-Preserving Multi-Touch-Attribution and Cross-Publisher Lift Measurement](https://github.com/w3c/web-advertising/blob/master/privacy_preserving_multi_touch_attribution_and_cross_publisher_lift_measurement.md)”

SPARROW: Multi-toucht attribution available as of today thanks to the ranked k-anonymous granular report described [here](https://github.com/BasileLeparmentier/SPARROW/blob/master/Reporting_in_SPARROW.md)| +| [View-through attribution](#click-through-and-view-through-attribution-heuristics) | A [section of the Conversion Measurement with Aggregation proposal](https://github.com/WICG/conversion-measurement-api/blob/master/AGGREGATE.md#view-through-conversions) describes explicit support for view through conversions. | No support | SPARROW: No particular support / Cf. Chrome section. | +| [Multi-touch attribution](#multi-touch-attribution) | The [Event-level API](https://github.com/WICG/conversion-measurement-api/blob/master/README.md) proposal covers last-click attribution. A section of the [Conversion Measurement with Aggregation](https://github.com/WICG/conversion-measurement-api/blob/master/AGGREGATE.md#multi-touch-attribution-mta) proposal describes support for some built-in multi-touch models, and acknowledges that measurement providers writing their own models would be good to support if technically feasible. | No support | Facebook proposal for “[Privacy-Preserving Multi-Touch-Attribution and Cross-Publisher Lift Measurement](https://github.com/w3c/web-advertising/blob/master/privacy_preserving_multi_touch_attribution_and_cross_publisher_lift_measurement.md)”

SPARROW: Only Multi-touch post-click attribution is available thanks to the ranked k-anonymous granular report described [here](https://github.com/BasileLeparmentier/SPARROW/blob/master/Reporting_in_SPARROW.md).| | [Cross Browser / Cross Device Measurement](#cross-browser--cross-device-measurement) | No support | No support | Facebook proposal for “[Cross Browser Anonymous Conversion Reporting](https://github.com/w3c/web-advertising/blob/master/cross-browser-anonymous-conversion-reporting.md)” | -| [Conversion Fraud](#conversion-fraud) | A section of the [Multi-Browser Aggregation Service Explainer](https://github.com/WICG/conversion-measurement-api/blob/master/SERVICE.md#authenticating-inputs) describes using a service that includes an authentication mechanism. This use case is also being explored for the event level API in this [GitHub Issue](https://github.com/WICG/conversion-measurement-api/issues/13). | Confirmation this is a use-case Safari cares about addressing. In the process of collaboratively designing a solution on this [GitHub Issue](https://github.com/WICG/ad-click-attribution/issues/27). | Facebook proposal for “[Private Fraud Prevention](https://github.com/siyengar/private-fraud-prevention)”

SPARROW : Thanks to exact reporting, it will be possible to link conversion to both an interest group and a publisher. It will also be possible to have user-level granularity on the website, helping to spot fraudulent activity. | +| [Conversion Fraud](#conversion-fraud) | A section of the [Multi-Browser Aggregation Service Explainer](https://github.com/WICG/conversion-measurement-api/blob/master/SERVICE.md#authenticating-inputs) describes using a service that includes an authentication mechanism. This use case is also being explored for the event level API in this [GitHub Issue](https://github.com/WICG/conversion-measurement-api/issues/13). | Confirmation this is a use-case Safari cares about addressing. In the process of collaboratively designing a solution on this [GitHub Issue](https://github.com/WICG/ad-click-attribution/issues/27). | Facebook proposal for “[Private Fraud Prevention](https://github.com/siyengar/private-fraud-prevention)”

SPARROW: The advertiser can tie the conversions on its website to its ad campaigns thanks to the click_id and the granular reporting. | | [Click Flooding](#click-flooding) | No solutions yet for this problem. However, lift measurement could be a potential way of measuring this problem. This might be supported by the “[Aggregate Reporting API](https://github.com/csharrison/aggregate-reporting-api)”. | No solutions yet for this problem. | Facebook proposal for “[Private Lift Measurement](https://github.com/w3c/web-advertising/blob/master/private-lift-measurement-conceptual-overview.md)” a potential way of measuring this problem.

SPARROW: Advertisers can use ranked k-anonymous granular report in a limited fashion. For massive fraud events, the aggregated reporting may be leveraged in real time. However, the necessary delay and partial information reduce the capacity to act quickly. Gatekeepers might have to become a first line of defense. | | [Malicious Browser Extensions](#malicious-browser-extensions) | No solutions yet for this problem. | No solutions yet for this problem. | | | [Malicious Mobile Apps](#malicious-mobile-apps) | No solutions yet for this problem. | No solutions yet for this problem. | | | [Malicious Browsers](#malicious-browsers) | No solutions yet for this problem. | No solutions yet for this problem. | | | [Brand Safety](#brand-safety) | There should be no conflict with Chrome’s proposed “[Privacy Model for the Web](https://github.com/michaelkleber/privacy-model)”. When an ad targets an interest group, it is served as a web package with all subresources included and the detail of which interest group won lets you trace down the problematic campaign. However, the ads that were printed less than k times (k being the reporting threshold) would still pose a threat as they would remain undetectable because not reported. | Similar answer as that for Chrome. This should not be in conflict with Webkit's [Tracking Prevention Policy](https://webkit.org/tracking-prevention-policy/) given the measurement is entirely within the scope of a single publisher website. | SPARROW: At bidding time, the gatekeeper follows the advertiser instructions to ensure brand safety. Granular reporting allows the advertiser to audit the brand safety and to be assured that the rules were properly enforced. | -| [Billing Transaprency](#billing-transaprency) | In TURTLEDOVE, the browser is the sole owner of billing information. | | SPARROW : The aggregated report can be leveraged for billing. An especially low noise / noiseless aggregated report could be provided daily for the specific billing purposes. SPARROW enables two parties, one on Publisher side and one on Advertiser side, to generate that same report, thus enabling cross-data comparison and disputes resolution. | +| [Billing Transparency](#billing-transparency) | In TURTLEDOVE, the browser is the sole owner of billing information. | | SPARROW : The aggregated report can be leveraged for billing. An especially low noise / noiseless aggregated report could be provided daily for the specific billing purposes. SPARROW enables two parties, one on Publisher side and one on Advertiser side, to generate that same report, thus enabling cross-data comparison and disputes resolution. | + ## Specialized Advertiser Needs @@ -116,7 +117,7 @@ These are use-cases that only apply to a (possibly large) subset of advertisers. | [Exclusion Targeting](#exclusion-targeting) | Acknowledgement that this is a valuable use-case and a link to Facebook’s PETREL proposal on this [GitHub Issue](https://github.com/michaelkleber/turtledove/issues/3) | No support | Facebook proposal for “[Private Exclusion Targeting Rendered Exclusively Locally (PETREL)](https://github.com/w3c/web-advertising/blob/master/PETREL.md)” | | [Lookalike Targeting](#lookalike-targeting) | Might be possible to achieve limited support by leveraging “[Federated Learning of Cohorts (FLoC)](https://github.com/jkarlin/floc)”. Might require an extension to TURTLEDOVE offering a new way to create interest groups, which Chrome indicated support for in [this issue](https://github.com/michaelkleber/turtledove/issues/26). | No support | Facebook proposal for "[Privacy Preserving Lookalike Audience Targeting](privacy_preserving_lookalike_audience_targeting.md)"

SPARROW: Lookalike audiences can be defined using interest groups and meta-interest groups such as defined in [this document](https://github.com/BasileLeparmentier/SPARROW/blob/master/Interest_groups_audiences_new_building_blocks.md#lookalike-targeting). | | [Retargeting](#retargeting) | Proposal: "[Two Uncorrelated Requests, Then Locally-Executed Decision On Victory (TURTLEDOVE)](https://github.com/michaelkleber/turtledove)" | No support | SPARROW: SPARROW Proposal extends TURTLEDOVE to provide more control, performance whilst preserving user privacy. | -| [Display and target environment](#display-and-target-environment) | Supported in TURTLEDOVE thanks to the contextual request. Ability to use this together with interest group request limited by the JS complexity. | | SPARROW: The gatekeeper is responsible for enforcing the policy defined by the advertiser. | +| [Display and target environment](#display-and-target-environment) | Supported in TURTLEDOVE thanks to the contextual request. Ability to use this together with interest group request limited by the JS complexity. | | SPARROW: The gatekeeper enforces the policy defined by the advertiser. | | [Frequency Capping](#frequency-capping) / [Frequency Optimization](#frequency-optimization) | For ads served via TURTLEDOVE interest-group targeting, the proposal offers a way to [handle frequency capping on-device](https://github.com/michaelkleber/turtledove#on-device-auction). For other types of targeting, while it will not be possible to enforce a hard "frequency-cap" across multiple websites, it might be possible to calibrate a target average frequency model. See discussion about how to do this on the explainer for the [Aggregate Reporting API](https://github.com/csharrison/aggregate-reporting-api#advanced-example-calibrating-a-frequency-capping-model). | No support | SPARROW: As TURTLEDOVE, SPARROW can handle hard frequency capping (not transferred by the gatekeeper), allowing to stop bidding. | | [Businesses with Multiple Domains](#businesses-with-multiple-domains) | Proposal: "[First Party Sets](https://github.com/krgovind/first-party-sets/)" | Some discussion in this [GitHub issue](https://github.com/krgovind/first-party-sets/issues/6) indicates weak support for at least the country-specific eTLD use-case, but various concerns with the current "First Party Sets" proposal. | SPARROW: "First Party Sets" + ability to add users to the same interest group via different domains ("shared" interest groups). Note that whilst it's possible to add the user to the same interest from multiple domains, no cross-domain information can be used to define the interest group. (Cf. [here](https://github.com/w3c/web-advertising/blob/master/support_for_advertising_use_cases.md)) | | [Collaborative Ads](#collaborative-ads) / [Dynamic Ads](#dynamic-ads) | Some discussion in this [GitHub issue](https://github.com/WICG/conversion-measurement-api/issues/32). No solutions or even strong acknowledgement of the importance of this use-case yet. | Some discussion in this [GitHub issue](https://github.com/WICG/ad-click-attribution/issues/36). Good collaborative problem solving going on. No firm solution yet. | Facebook proposal for “[Conversion Filters](https://github.com/w3c/web-advertising/blob/master/conversion-filters.md)” | @@ -148,7 +149,7 @@ These are core essentials ad networks need to deliver value to advertisers. |----------|--------|--------|---------------------| | [P(click \| impression)](#click-through-rate-ctr-model-pclick--impression) | There is no conflict with Chrome’s proposed “[Privacy Model for the Web](https://github.com/michaelkleber/privacy-model)”. Should be possible to use 1st party cookies to tie together multiple sessions from the same browser on the same website. | [isLoggedIn](https://github.com/WebKit/explainers/tree/master/IsLoggedIn) may potentially pose problems here for websites without login. Limited storage may make it hard to tie together multiple sessions from the same person. | SPARROW: Exactly same capabilities as today, with user-level data condensed into interest group-level data. | | [P(conversion \| click)](#conversion-rate-cvr-model-pconversion--click) | This is a stated goal of Chrome’s “[Click Through Conversion-Measurement Event-level API](https://github.com/WICG/conversion-measurement-api)” | Not possible to train an ML model. | SPARROW: Exactly same capabilities as today, with user-level data condensed into interest group-level data. | -| [Post-view attribution: P(conversion \| impression)](#post-view-attribution-pconversion--impression) | Not possible to train an ML model. However, It may be possible to use the "Aggregate Reporting API" to obtain average conversion value measurement for very coarse-grain buckets of people. This could be used to perform calibration at this coarse-grain bucketed level. | Not possible to train an ML model. | SPARROW: Exactly same capabilities as today, with user-level data condensed into interest group-level data. | +| [Post-view attribution: P(conversion \| impression)](#post-view-attribution-pconversion--impression) | Not possible to train an ML model. However, It may be possible to use the "Aggregate Reporting API" to obtain average conversion value measurement for very coarse-grain buckets of people. This could be used to perform calibration at this coarse-grain bucketed level. | Not possible to train an ML model. | SPARROW: Same as Chrome | | [P(Display \| Request)](#pdisplay--request) | No support. | Not possible to train an ML model. | | | [Return on Ad Spend (ROAS) optimization](#return-on-ad-spend-roas-optimization) | Not possible to train an ML model. However, It may be possible to use the “[Aggregate Reporting API](https://github.com/csharrison/aggregate-reporting-api)” to obtain average conversion value measurement for very coarse-grain buckets of people. This could be used to perform calibration at this coarse-grain bucketed level. | Not possible to train an ML model. | SPARROW: Exactly same capabilities as today, with user-level data condensed into interest group-level data. | | [Multiple Targets optimization](#multiple-targets-optimization) | No support | Not possible to train an ML model. | SPARROW: k-anonymous granular report for optimization (Granular and low-noise) reporting allows for in-house attribution and optimize for multiple targets at once. | @@ -191,8 +192,8 @@ These use-cases are more focused on the publisher's perspective. | [Click-through Site Personalization](#click-through-site-personalization) | There should not be any conflict with Chrome's proposed “[Privacy Model for the Web](https://github.com/michaelkleber/privacy-model)” unless this mechanism is used to pass through high-entropy identifiers which could be used to tie user identity across websites. See PING's [Privacy Threat Model](https://w3cping.github.io/privacy-threat-model/#goal-transfer-userid). | Similar to Chrome, this should not fall afoul of Webkit's [Tracking Prevention Policy](https://webkit.org/tracking-prevention-policy/) unless high-entropy identifiers are being used to perform "navigational tracking". See PING's [Privacy Threat Model](https://w3cping.github.io/privacy-threat-model/#goal-transfer-userid). | SPARROW: Possible via URL decoration. If following a SPARROW targeted ad, this URL could technically not contain identifying information except the interest group linked to the winning ad. Personalization can therefore only be done at the publisher origin/interest group level. | |[On-site Sponsored Product](#on-site-sponsored-product)| There should not be any conflict with Chrome's proposed “[Privacy Model for the Web](https://github.com/michaelkleber/privacy-model)” | Similar answer as that for Chrome. This should not be in conflict with Webkit's Tracking Prevention Policy given the measurement is entirely within the scope of a single publisher website. | | |[Search](#search) | unclear, but relies a lot on contextual | unclear | | -| [Ad Quality](#ad-quality) | Very limited support as opaque iframe aggregated reporting allow for very little ex post audit. | No Support | SPARROW: The Gatekeeper is reponsible for enforcing the publisher policy. The Gatekeeper could provide a service to ensure Ad Quality before the ad is displayed.
The aggregated report and Delayed served ads report can be leveraged for ex post ad quality audit. | -| [Advertisers exclusion](#advertisers-exclusion) | Unclear. To be defined. | | SPARROW: The gatekeeper is responsible for enforcing the policy. | +| [Ad Quality](#ad-quality) | Very limited support as opaque iframe aggregated reporting allow for very little ex post audit. | No Support | SPARROW: The Gatekeeper enforces the policy defined by the publisher.
The aggregated report and Delayed served ads report can be leveraged for ex post ad quality audit. | +| [Advertisers exclusion](#advertisers-exclusion) | Unclear. To be defined. | | SPARROW: The gatekeeper enforces the policy defined by the publisher. | | [Revenue management](#revenue-management) | | | SPARROW: Supported thanks to aggregated reporting. | # User Needs