-
Notifications
You must be signed in to change notification settings - Fork 177
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
App to web attribuition #1479
Comments
In this case where you aren't sure whether sources will be on the OS or web, we recommend delegating all registrations to the OS so that there is one unified view. The OS version of ARA will be able to see both the delegated web sources and app sources and find the correct one. The same would be true for web sources where you are unsure if the trigger will happen on the web or in an app, by delegating it to the OS there will be a unified view across app and web. We have an implementation guide for cross app and web that provides additional details: https://developers.google.com/privacy-sandbox/private-advertising/attribution-reporting/cross-web-app |
@hpatoski thanks for your answer. Our problem is that we don't know from where the click (on the publisher) came from. |
@eysegal @danieldansker Could you also clarify whether you are going to register the click(on the publisher) with ARA or would this entity be different. In the scenario you described above, you'd need to also register/delegate the Source with the OS and register/delegate the Trigger with OS, that way OS can do the cross-app/web attribution correctly. |
@arpanah, let me try to explain the user story here. (I am working with @eysegal and @danieldansker in Taboola). Taboola's clients render ads on mobile apps using our SDK or API. They also use our JavaScript library to render website ads. As a platform, we are indifferent to the click origin (the OS and platform), but per ARA requirements, we need to declare the right platform to enable the relevant module (web-to-web or app-to-web). If we use an OS (i.e., Android) only, we'll not be able to differentiate between Android as an app or Android in Chrome (mobile web). Our SDK docs - https://developers.taboola.com/taboolasdk/docs/welcome |
Thanks for the response @omriariav (also tagging @eysegal @danieldansker). We still have a few more followups to understand your flow, would you be open to attending a WICG call in early Jan so we can work through this? Meanwhile we have updated the app-to-web implementation guide: https://developers.google.com/privacy-sandbox/private-advertising/attribution-reporting/cross-web-app. Let us know if that helps clarify? Mainly your server-side response headers on Android in Chrome (mobile web) can tell the chrome to delegate the source/trigger to underlying OS - there should not be any client side changes for you and once you get a report destination field in the report can indicate web or app destination. |
@arpanah Sure - we'll have someone from Taboola joining - do we have the meeting on a bi-weekly cadence or per demand? |
Hey I read this thread - #1240
But am still not clear how we can proceed with app to web attributions.
In our case, during the trigger event (on the web) we have no way of knowing where the source originated (knowing would probably also violate the privacy Model).
But according to your API we most return a header that instructs where to search for the source - (Attribution-Reporting-Register-Os-Trigger - to search for the click in the OS | Attribution-Reporting-Register-Trigger - to search for the source in the browser).
Since we can't know were the source is from during the trigger event we can't decide what header to return.
We need an option to search in both locations.
The text was updated successfully, but these errors were encountered: