[proposals] Use cases and principles for Attribution/Measurement proposals (#14)

lbdvt has just created a new issue for https://github.com/patcg/proposals:

== Use cases and principles for Attribution/Measurement proposals ==
We'd like to propose a set of use cases and principles to assess Attribution/Measurement proposals coverage from a utility standpoint. We hope it will help in defining the roadmap of these proposals.

What use cases need to be covered or not by a proposal depends on the bidding/ad display mechanism constraints. For example, when using FLEDGE and Fenced Frames, a part or all of the "monitoring" use case may need to be supported by a specific Attribution/Measurement proposal. In less constrained environments, some data (usually data not linked to attribution) may be readily available.

We'd like to gather feedback on the proposal below, and add it as a document for the group.

## Use cases
An advertising measurement system must support the following use cases, if the data is not otherwise accessible:

### Billing
The system must provide data for computing advertiser spend and publisher revenue. 
- Publisher revenue is generally linked to auction clearing prices, but can also be linked to additional information (e.g. discounts or premiums linked to specific deals or volumes).
- Advertiser spend can be linked to auction clearing prices (CPM), but also conversions such as clicks on a display, visits to the advertiser site, or sales.
The system shall provide ways for advertisers, publishers, and ad tech providers to audit that data and/or reconcile it with external data sources.

### Reporting 
The system must provide data for reporting for advertisers, publishers, and ad tech providers. 
- Common dimensions in these reports include campaign, product, day, hour, type of device, ad display characteristics (e.g. size), creative type, click zone, etc. 
- Common KPIs in these reports include bid win rate, yield, number of displays, user exposure, click-through rate, attributed visits,  attributed sales, etc. 
    - Note that attribution can be used for billing, reporting, campaign optimization and piloting.
    - It must be possible to use various events for attribution, such as visits and sales.
- Flexibility around these dimensions and KPIs are important.
- Reporting must also plan for after-the-fact control of key functionalities such as:
   - Brand Safety for advertisers (i.e. “as an advertiser, I want to control where my ads have been displayed, to make sure that there has no been on a site I don’t want them to”).
    - Ad Quality for publishers (i.e. “as a publisher, I want to control the ads that have been displayed on my site, to make sure that there was no offensive/refused ad or brand”).
- Reporting on incrementally / lift measurement (combined with A/B testing capabilities).

### Legal Reporting 
Some jurisdictions have legal requirements related to web advertising (e.g. [French digital advertising reporting law](https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000034024418), which requires disclosing to a marketer, among other things, the domains where its ads have been displayed). The system must support this.

### Campaign optimization
The system must provide Machine Learning training for the models that select campaigns, products, ads layouts and features, calculate bid amounts, or dynamic attribution models (i.e. that are able to highlight the main contributors among several impressions or clicks).

### Campaign piloting
It must be possible to control campaign delivery pace and enforce budget constraints in real-time.
Marketers must have the ability to get feedback on their campaigns' performance, e.g. cost per action, to adapt the related objectives, with a latency of around an hour. 

### User feedback collection
Ads may include a method for users to provide feedback on what they see. The system must enable reporting those feedbacks in an aggregated way, with a latency of around an hour.

### Monitoring and incident detection
It must be possible to possible to detect incidents (at campaign, client, or company level) within 5 minutes, as they can cause large overspend or loss of opportunities.
One standard way of detecting incident is to detect unexpected changes to KPIs, such as win rate, yield, ad displays, etc. A certain level of data breakdown enabling a quick and detailed diagnosis of the incident is required.

### Allow for external data ingestion
The solution should cover the ingestion and processing of external data (e.g. brick&mortar stores sales) in combination with web events.

## Principles
We propose seven key principles to consider:

### Fairness
The system must treat all participants equally, and shall not introduce a competing advantage for those who do not need to use them, that is to say, open web measurement shall not be at a disadvantage compared to large first parties.
Delegation to third parties should be possible, enabling small and medium sites to rely on external suppliers.

### Accuracy
The system must provide accurate enough data for the use cases it supports.

### Velocity
The system must provide data at a rate fast enough for the use cases it supports.

### Flexibility
The system must not be locked to specific measurement methods. (e.g. last-click attribution, specific attribution windows, etc.), machine learning frameworks, etc. Lack of flexibility would limit participants' ability to innovate.
As an example, video advertising has some specific measurement KPIs, such as view percentage. The system must easily adapt to such innovations.

### Interoperability
The system must provide for interoperability between advertisers, publishers, and Ad Tech participants, i.e. it should be possible for multiple participants to share, compare, and combine data. In particular multiple participants should be able to get their own reports, investigate, and resolve any dispute.

### Scalability
The system shall scale to the need of all Ad Tech participants, for a reasonable cost.
On-device processing should not incur undue load on these users' devices.

### Compliance
The system shall improve compliance with respect to applicable Laws and Reglementations on user data processing.



Please view or discuss this issue at https://github.com/patcg/proposals/issues/14 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 4 October 2022 11:09:42 UTC