Questions about the billing auditing capabilities

[nchrys]

Hello,

The audit of the billing by both parties (supply & demand) is a key consideration to take into account.

Based on this proposition, there is no way to have a fully accurate reporting of the impressions printed. From my understanding there are two sources of mismatch:

• reports without enough identical reports are not reported.
• entries which expired before they were reported.

This raises a serious concern about billing. How can advertisers fairly retribute publishers without a fully accurate reporting of the impressions (and associated cost)?

How can smaller publishers (for which a bigger share of their printed ads won't be reported) expect to be retributed fairly?

[michaelkleber]

(Again, I'm going to assume you're thinking of the TURTLEDOVE use case, for the same reasons as in #6.)

You're right that it would be hard to do billing if the browser drops reports without enough identical copies across browsers. This use case seems to call for a different type of aggregation, in which each browser can issue its own report involving some aggregation keys and also some numerical value, and as long as there are enough reports with the same keys, you can learn the sum of those values. The Secure Aggregation approaches in the Conversion Measurement API explainer could offer this.

WIth that capability, billing for a particular event essentially involves sending two aggregatable values, in the style of double-entry bookkeeping: {'debit-from': advertiser_account, 'amount': 0.00037} and {'pay-to': publisher_account, 'amount': 0.00037}.

You could implement this with a single report as well, but then, as you note, small publisher/advertiser pairs would have a harder time getting useful data.

[nchrys]

Hi Michael,

Thank you for your response.

(Again, I'm going to assume you're thinking of the TURTLEDOVE use case, for the same reasons as in #6.

Indeed

This use case seems to call for a different type of aggregation

For Billing, the requirements would be:

• Aggregation Level: Single domain
• Delay: ~days
• Noise sensibility: there can be no noise so that publishers are fairly retributed.

The Secure Aggregation approaches could indeed be an answer, with the remaining open questions about its applicability to the web use case detailed in the same paper. Furthermore, the issue of auditability still remains. How can the advertiser/publisher make sure that he is not being cheated?

A solution which is fair to all, smaller and bigger actors alike is fundamental for adoption and as this billing issue is, of course, very sensitive. We will try to come up with a solution that could be acceptable by all parties while preserving the privacy features of these proposals.