-
Notifications
You must be signed in to change notification settings - Fork 12
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
Gatekeeper involvement in conversions? ...or in viewability? #11
Comments
Actually, reading over your claims of SPARROW support in w3c/web-advertising#64, I see that you're asserting way more than that! For example, you say
To support multi-touch attribution, the Gatekeeper would need to know about every ad this advertiser showed to a particular user. Are you imagining the browser attaching a persistent ID to all of its Gatekeeper requests? That's not mentioned anywhere in the proposal — and indeed the fact that you talk about a bucket for A/B testing makes it seem like you do not have such an ID. So I think the reporting you imagine may not be compatible with the design you've described, or else you need more explanation about how it could possibly work. |
This is indeed a mistake on our part. Multi-touch is not fully supported, only post-click multi-touch. We will update to fix this error. Conversions are not reported to the Gatekeeper. They are reported to the advertiser, and we will be able to join them with the report, thanks to a click id. |
Backing up a step, how about viewability: Does the Gatekeeper learn which ads end up viewable in the publisher page? If so, how? If not, how does the advertiser join viewability information with Gatekeeper information (for the ranked k-anonymous granular report)? |
Following our workshop, please find below a summary of the discussions around this issue. The full video can be found here, password:0Y$y0.R$. We invite participants to comment if they want to add a specific point or want to correct the following summary of the discussions. Gatekeepers should not be involved in conversion as the delay can be quite high between conversion and display/click. However, it should be involved in viewability (but not post-view conversion). Notification of a view should be sent directly to the gatekeeper. This should be done without exchanging PII. We think it should be possible by firing a pixel directly to the gatekeeper including a display id in order for it to be able to join the view information with the display. Additional work is needed to ensure feasibility and privacy of the proposed solution. |
Do you imagine that conversions are reported to the Gatekeeper as well? This seems undesirable to me for a lot of reasons.
For example, it means that the Gatekeeper needs to keep logs of impressions around for a long time, waiting for conversion events to join up. It's not at all clear to me how the "Reporting in SPARROW" reports would interact with impressions that didn't have a conversion at the time the report was generated but got one later.
The text was updated successfully, but these errors were encountered: