Description of our usage of the measurements APIs

[BasileLeparmentier]

Dear Charlie,

Following the last call, here are the kind of reporting we would like to use at Criteo (it is not exhaustive and I might have missed some use cases, but it should be a good start).

I will also consider use cases where the reporting is needed for basic use cases such as billing and campaign management, which are not the exact use case of this API, but will be the object of another, we understand, similar API for Fledge. I will also try to give tentative frequency for our queries.

At least every hour:

• We will need to have the cost and number of display:

1. Per interest group. Other dimensions, like SSP name, device type might also be important.
2. It is important to be able to aggregate across publisher with the same noise, or this is going to be unusable.
3. Hourly feedback is already quite delayed, and paramount to avoid overspending and pace budget.

• A small either dataset / or many projections on wide dimensions for bug detections. It is easy to loose a lot of money in a very small amount of time because of a bug, and we therefore need quick feedback to be able to handle bugs.

At least every day:

• A precise report on the advertising spend in order to handle billing. We need the following dimension at least:

1. SSP
2. Publisher Domain
3. Advertiser domain

• A report on conversions across all single dimensions. We will need multiple data on each conversion:

1. Number of sales,
2. Number of interactions with the website,
3. Sales amount,
4. Etc..

• We have more than 100 dimension of interest
• On top of those, we may want up to 300 cross features (e.g display position X display size)
• Most of those are not hierarchical.

Other topics where we have a strong need of reporting:

• It is still extremely unclear how we can tackle Fraud with these kind of reporting. Indeed fraud is often at the individual level, therefore capping individual contribution is actually the worse possible set up for fraud detection.
• It is also often very localized (on display size, on one placement, on one publisher), and in time. This fits very badly with the proposed framework.
• Ex post granular (at the display and at the publisher page, not domain), not necessarily user based reporting to handle ad quality and ad safety ex post (for a publisher to see if an advertiser put unsafe content on their webpage, and vice versa for an advertiser to audit the page they are doing advertising on) .
• Granular detection of bug. Bug are sometime very hard to spot, very localized, and very costly. They come in extremely wide variety, and they are extremely hard to pin down without granular data or at least projections on multiple dimensions. In bug cases, we often have to project on all cross dimension (more than 10 000) and often on cross feature involving more than 3 dimensions. It is unclear how we will be able to handle such bugs with the current reporting.

Best, Basile

[Lovaso]

Label

[Lovaso]

****> Dear Charlie,

Following the last call, here are the kind of reporting we would like to use at Criteo (it is not exhaustive and I might have missed some use cases, but it should be a good start).

I will also consider use cases where the reporting is needed for basic use cases such as billing and campaign management, which are not the exact use case of this API, but will be the object of another, we understand, similar API for Fledge. I will also try to give tentative frequency for our queries.

At least every hour:

• We will need to have the cost and number of display:

1. Per interest group. Other dimensions, like SSP name, device type might also be important.
2. It is important to be able to aggregate across publisher with the same noise, or this is going to be unusable.
3. Hourly feedback is already quite delayed, and paramount to avoid overspending and pace budget.

• A small either dataset / or many projections on wide dimensions for bug detections. It is easy to loose a lot of money in a very small amount of time because of a bug, and we therefore need quick feedback to be able to handle bugs.

At least every day:

• A precise report on the advertising spend in order to handle billing. We need the following dimension at least:

1. SSP
2. Publisher Domain
3. Advertiser domain

• A report on conversions across all single dimensions. We will need multiple data on each conversion:

1. Number of sales,
2. Number of interactions with the website,
3. Sales amount,
4. Etc..

• We have more than 100 dimension of interest
• On top of those, we may want up to 300 cross features (e.g display position X display size)
• Most of those are not hierarchical.

Other topics where we have a strong need of reporting:

• It is still extremely unclear how we can tackle Fraud with these kind of reporting. Indeed fraud is often at the individual level, therefore capping individual contribution is actually the worse possible set up for fraud detection.
• It is also often very localized (on display size, on one placement, on one publisher), and in time. This fits very badly with the proposed framework.
• Ex post granular (at the display and at the publisher page, not domain), not necessarily user based reporting to handle ad quality and ad safety ex post (for a publisher to see if an advertiser put unsafe content on their webpage, and vice versa for an advertiser to audit the page they are doing advertising on) .
• Granular detection of bug. Bug are sometime very hard to spot, very localized, and very costly. They come in extremely wide variety, and they are extremely hard to pin down without granular data or at least projections on multiple dimensions. In bug cases, we often have to project on all cross dimension (more than 10 000) and often on cross feature involving more than 3 dimensions. It is unclear how we will be able to handle such bugs with the current reporting.

Best, Basile