search

WICG / attribution-reporting-api

Attribution Reporting API
https://wicg.github.io/attribution-reporting-api/
Other
347 stars 161 forks source link

App-to-Web Click Source Registration #1313

Open jfggit opened 1 month ago

jfggit commented 1 month ago

I'm trying to follow along with the documentation both here and in Android docs and I'm not quite sure how or if the following works, or if it does, how exactly.

In the scenario where an app is using a WebView purely to display an ad (i.e. non-browser-like app), we have a simple display ad with an image wrapped in an anchor tag like:

<a href="[click tracker + landing page URL]" attributionsrc="" target="_blank">...</a>

I believe this case would result in Android opening up the default system browser to load the URL (let's ignore the case where the app/ad SDK intercepts the click and handles it differently). Can this click be registered? Will the WebView be able to delegate to registerSource for this type of event? It seems like the WebView is actively being paused/discarded if the context is switching over to a browser, right? If the default system browser is Chrome, would the request made to the click tracker server be registration eligible (i.e. would Chrome inherit the registration eligibility from the WebView click context)? Which context (WebView or browser) would be attempting to register this source event, if any?

linnan-github commented 4 weeks ago

@justjoza Could you please take a look at the WebView workflow? Thanks.

cc @vikassahu29

JustJoZa commented 3 weeks ago

This flow doesn't work. The main issue is that the app is back-grounded and the Android Measurement API doesn't allow sources to be registered from the background.

If Chrome is opened it will have no context about the click and won't try to register anything (unless of course the page that is loaded has attribution code).

For this scenario the best thing would be to get the app to handle the click instead and call registerSource itself.

jfggit commented 3 weeks ago

Isn't the app itself also getting backgrounded? If the app catches the click and calls registerSource, but the click is ultimately intended to open the web browser, is that still a race? Is there some kind of backgrounding/keepalive mechanic for the registerSource call here?

JustJoZa commented 2 weeks ago

I think you would need to call registerSource and then try open the url for the click. As long as the registerSource is called in the foreground to begin with it should be okay if the app is then backgrounded.

@vikassahu29 Can you comment on the timing here?