Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Guidance and clarification regarding CPC billing #1104

Open
omriariav opened this issue Mar 27, 2024 · 2 comments
Open

Guidance and clarification regarding CPC billing #1104

omriariav opened this issue Mar 27, 2024 · 2 comments

Comments

@omriariav
Copy link
Contributor

omriariav commented Mar 27, 2024 •
edited
Loading

Hi all,

Background:
A common model in native advertising is CPC. A native advertising platform charges the advertiser when a user clicks a sponsored content item (ad).

Ad tech platforms engage in different use cases that involve campaign stoppage (avoiding overcharging), billing accountability, bid optimization, bid tuning, campaign pacing, and other related issues (see this case from three years ago—#175).

In PAAPI, these use cases will happen in the client upon generating the bid (buyer) and scoring the ad (seller).

To support CPC billing, we need to keep real-time reporting.

What we know:
Until the aggregate reporting and fenced frames reporting APIs are enforced in 2026, the following event-level reportings are currently available:

  • reportWin - buyer reporting on render (buyer)
  • reportResult - this is called with the bid that won the auction (seller)
  • Ad tech platform (SSP) own click event (coming from the renderUrl rendering in the iframe)

According to the explainer, registerAdBeacon() and registerAdMacro() functions can report the click event within the fenced frame. However, fenced frame does not support native advertising yet, and both of those functions are missing information about the bid and ad cost. There is also ambiguity in the document regarding these functions availability in the current stage of event-level reporting.

Challenge:
CPC billing is impossible.

There is a race condition between:
reportWin and reportResult events with the CPC (these events are reporting the bid and adCost values) - fired upon win and render of the ad, and not when the user is clicking the ad.
And:
The SSP own click reporting event that lacks the CPC billing value as it just comes from the renderUrl within the iframe

Open questions:

  • Given the race condition and the gap between the click itself and the auction events, how would you recommend performing CPC billing as long as event-level reporting is available?
  • Assuming the fenced frame will fully support native advertising by 2026, what is your recommendation on adopting the Fenced frame reporting, Aggregate reporting the Private Aggregation APIs to accomplish CPC billing? Can you provide a walkthrough? (for example, we are worried about noise and delay that can disrupt the billing process)
  • We see the bid field as a representation of the CPM value and adCost as the representation of billing upon click, viewable impression, an action, or any other event. Can you please confirm this?

We're seeking clarity on implementing 'CPC billing' effectively, especially considering the current challenges.

Thank you!
@omriariav
Copy link
Contributor Author

@michaelkleber I found out those wordings here:
Note window.fence here is a new namespace for APIs that are only available from within a fenced frame. In the interim period when FLEDGE supports rendering the winning ad in an iframe, window.fence will also be available in such an iframe.

Potentially, we can fire events (registerAdBeacon() and registerAdMacro()) now from the "regular" iframe, right? The only thing is that we need to ensure those events will hold ad cost and bid information.

Will appreciate further guidance. Thank you!

@michaelkleber
Copy link
Collaborator

If you are rendering the ad inside a fenced frame or an iframe where the src is the render URL that came out of the PA auction, then you can use the registerAdBeacon() and registerAdMacro() functions. (For native ad rendering in that situation, you would presumably use something like postMessage to push some how-to-render information into that frame to make the ad look like you want it to.)

If that doesn't meet your needs — which is to say, if your plan is to pull information out of that iframe, and instead render it somewhere up in the publisher page — then you won't have that reporting system available. In that case you can still reconstruct the association between auctions and their clicks, but it would be more involved:

  1. Inside the iframe whose src is the render URL, you can create a unique event ID, e.g. by calling crypto.randomUUID() or whatever mechanism you want.
  2. Associate that event ID with the auction using registerAdBeacon() and registerAdMacro() inside the iframe.
  3. Associate that event ID with the ad click by inserting it somehow into the ad click URL that you render, or however it is that you are used to learning about clicks.

With this technique you will end up getting two reports: one with the event ID and the information from the auction, and another with the same event ID and information about the click. Then you will need to do some kind of server-side log join to connect them to each other.

If I were picking between the two techniques, I would probably try the "render inside the iframe" approach. That one is more future-proof when looking ahead to the Fenced Frame era: of course we will need some different way to get the rendering info into the Fenced Frame, but the essential idea should stay the same. But depending on how your various systems work, the log-join approach might be easier to implement for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@omriariav @michaelkleber