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.

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

Use of Frequency Capping for upper funnel campaigns #122

Open
remysaissy opened this issue Oct 24, 2023 · 1 comment
Open

Use of Frequency Capping for upper funnel campaigns #122

remysaissy opened this issue Oct 24, 2023 · 1 comment

Comments

@remysaissy
Copy link

Hello,
Teads is participating in the Google market testing for Privacy Sandbox as a Buying Platform and we are more generally working on supporting the Privacy Sandbox for our existing use cases.
We have identified some limitations in the use of Privacy Sandbox to implement Frequency Capping and would like to share our concerns here as well as proposed solutions.
Thanks!

Context
Frequency Capping is an important feature to avoid user fatigue and we are naturally looking to how we can provide the same level of quality we do today in this regard when using the Privacy Sandbox.

In our case, we are mostly using Frequency Capping for non-retargeting campaigns.
It means a given ad could be delivered through the protected audience or contextual auction and in the vast majority of cases it is a contextual auction.

To maintain the same level of quality in our capping, we need a way to cap a given ad regardless of how the ad was delivered (protected audience auction or contextual auction).

Other important aspects include:

  • Our Frequency Capping today works at either the Campaign or the Line Item level. We can consider a creative as being part of a single Line Item. We can use the Ad structure metadata to pass this extra information today

Limitations of the current design
The current design of Privacy Sandbox has several limitations:

  • Frequency Capping must rely either on the use of Protected Audiences or contextual auction, but not mixing both, which doesn’t fit our use case since our campaigns deliver through both channels
  • A contextual auction can apply Frequency Capping on the browser side only. However this is too late in the workflow since the slot has already been won and paid. We need to apply Frequency Capping before winning the slot

Proposed solutions
Without getting into too much details, the improvement we need should:

  • Provide a unified view (prevwins?) between Protected Audiences and Contextual auctions
  • Have a prevwin that is global to a given owner, so that creatives present in several interest groups and contextual auctions can be properly filtered
  • Provide a way for contextual auctions to run Frequency Capping before winning the slot
@menonasha
Copy link

We appreciate the feedback that cross-site frequency capping outside of Protected Audience is a valuable use case. At this time, Privacy Sandbox remains focused on its current set of Ads APIs for 3rd party cookie deprecation.

A privacy-forward, non-Protected Audience frequency capping solution that provides meaningful adtech utility is challenging for the following reasons:

  • It is currently unclear based on adtech feedback whether a frequency signal could tolerate noise.
  • We have heard consistent adtech feedback that a cross-site frequency signal would have to be available during auction time, which require non-noised cross-site signals to be available for use in any advertising auction. This could reveal a large amount of information about a user’s activity across sites, undermining the privacy goals of Privacy Sandbox.
  • We are sensitive to introducing latency and an on-device solution that might provide this signal could cause latency and disrupt the auction environment
  • A solution would likely need to be a new API, which would have to go through the W3C proposal process.

As such, building a frequency cap solution outside of Protected Audience is not in our immediate roadmap, but we are open to feedback around potential ways to solve this use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants