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

Enabling Ghost ads incrementality studies in Protected Audience #1182

Open
alois-bissuel opened this issue May 16, 2024 · 0 comments
Open

Enabling Ghost ads incrementality studies in Protected Audience #1182

alois-bissuel opened this issue May 16, 2024 · 0 comments

Comments

@alois-bissuel
Copy link

Incrementality studies are commonly used by large advertisers to measure the impact of their campaign. To maximize the usefulness of incrementality studies, techniques such as Ghost Ads (see the paper which introduced it) were developed, but cannot be implemented in PA in practice as there is no visibility in the bidding process.

To be able to run such methods, we would need to know in an aggregated form some details about what happened in the auction and the action of the user on the advertiser’s website thereafter.

There are two paths to have a working Ghost Ads system in the Privacy Sandbox. It could either be implemented in the overall auction process or independently by each buyer with the addition of a novel reporting system. Both options are detailed below.

Option 1: Implement Ghost Bid in runAdAuction

In this option, the logic of Ghost Bid is done in runAdAuction. The buyer determines that a user should be in the control group for ad XYZ and returns of bid for this ad along with a flag indicating that this ad is an incrementality test. If this ad wins the auction, then runAdAuction should kill it instead and make the second-highest bid the winner and enable the adtech to report on this bid. For the reporting part, a call to Shared Storage gated through a reporting function could be used - this is detailed in more depth in the second option.

Option 2: Implement Ghost Bid through reporting in generateBid

In this case, the buyer would be solely responsible for not bidding on this ad inside the generateBid function. Here we would need a new reporting mechanism for the buyer to understand if this ad would have won the auction had it not been in the control group. What I propose is a gated access to writing in Shared Storage, akin to what reportWin does in allowing a ping through sendReportTo. A new reporting function would be created for the adtech to write in SharedStorage if the counterfactual bid would have won. This way, the adtech would be able to report on subsequent outcomes on the advertiser’s website using Shared Storage, enabling a Ghost Ads incrementality study.

Do you favor one alternative over the other?

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

1 participant