[blink-dev] Intent to Ship: Cross App and Web Attribution Measurement

[Nan Lin]

Contact emails

lin...@chromium.org, john...@chromium.org

Explainer

Cross App and Web Attribution Measurement

Specification

https://wicg.github.io/attribution-reporting-api/#cross-app-and-web

Summary

This is an extension to the Attribution Reporting API that has already shipped.

Currently, the Attribution Reporting API supports attributing events within a single browser instance. This proposal expands the scope of attribution to allow attributing conversions that happen on the web to events that happen off the browser on the same device, within other applications such as mobile applications, or vice-versa.

The proposal here leverages OS-level support for attribution. In particular, it gives the developer an option to allow events on the mobile web to be delegated to Android’s Privacy Sandbox, although support for other platforms could also be implemented in the future.

Note that with this proposal new features shipped by the OS may be implicitly supported without web API changes. For example, Android may ship support for new registration fields not supported in the existing Attribution Reporting API. Once a developer elects to delegate events to the OS, there is no way web-visible to introspect this.

Blink component

Internals > AttributionReporting

TAG review

https://github.com/w3ctag/design-reviews/issues/724#issuecomment-1908353938

TAG review status

Pending

Risks

                 Interoperability and Compatibility

See the Attribution Reporting API I2S for information on the other general measurement proposals in this space.

Private Click Measurement in Safari supports app to web measurement (https://webkit.org/blog/11529/introducing-private-click-measurement-pcm/#:~:text=App%2Dto%2DWeb%20Click%20Measurement). On iOS, some web to app measurement is supported via SKAdNetwork (https://developer.apple.com/documentation/skadnetworkforwebads). There is currently no interop between these proposals and the cross app web API for Attribution Reporting. 

Gecko: No official position (https://github.com/mozilla/standards-positions/issues/791#issuecomment-1908359889)

WebKit: No official position (https://github.com/WebKit/standards-positions/issues/307)

Web developers: Positive. Some testers are currently implementing and providing feedback and more usage expected in 2024. Developers have requested expansion of coverage of this feature (example: https://github.com/WICG/attribution-reporting-api/issues/1125).

Debuggability

The Attribution Reporting API utilizes DevTools and an internal page (chrome://attribution-internals) to facilitate testing and integration. The debugging information for OS registrations from Chrome will be displayed in DevTools and the internal page as well. 

Additionally, debug reports are supported for OS registrations. The Attribution Reporting API for Android also implements a similar debugging reports framework to facilitate cross app and web testing.

              

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

The Attribution-Reporting-Support header is supported on all platforms. Today, only Android offers a native Attribution Reporting API, so the ability to register with the OS is only supported on those platforms (Android and Android WebView).

Is this feature fully tested by web-platform-tests?

The Attribution-Reporting-Support header is tested by web platform tests, but the integration with OS is not as web platform tests are not supported for Android.

Requires code in //chrome?

False

Estimated milestones

Chrome 123

Launch bug

https://launch.corp.google.com/launch/4238495

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4994430156668928

Links to previous Intent discussions

Cross App and Web Attribution Measurement Intent to Experiment

Cross App and Web Attribution Measurement Intent to Extend Experiment

Attribution Reporting API Intent to Ship

[Mike Taylor]

Hi Nan,

On 2/2/24 5:00 AM, Nan Lin wrote:

Contact emails

lin...@chromium.org, john...@chromium.org

Explainer

Cross App and Web Attribution Measurement

Specification

https://wicg.github.io/attribution-reporting-api/#cross-app-and-web

Summary

This is an extension to the Attribution Reporting API that has already shipped.

Currently, the Attribution Reporting API supports attributing events within a single browser instance. This proposal expands the scope of attribution to allow attributing conversions that happen on the web to events that happen off the browser on the same device, within other applications such as mobile applications, or vice-versa.

The proposal here leverages OS-level support for attribution. In particular, it gives the developer an option to allow events on the mobile web to be delegated to Android’s Privacy Sandbox, although support for other platforms could also be implemented in the future.

Note that with this proposal new features shipped by the OS may be implicitly supported without web API changes. For example, Android may ship support for new registration fields not supported in the existing Attribution Reporting API. Once a developer elects to delegate events to the OS, there is no way web-visible to introspect this.

Could you help me better understand the implications of this? Does it just mean that debugging becomes challenging for new fields, or are there other possible implications depending on new OS features? Or possibly the web API lags behind what is possible via the platform, until the web API catches up formally?

Blink component

Internals > AttributionReporting

TAG review

https://github.com/w3ctag/design-reviews/issues/724#issuecomment-1908353938

TAG review status

Pending

Risks

                 Interoperability and Compatibility

See the Attribution Reporting API I2S for information on the other general measurement proposals in this space.

Private Click Measurement in Safari supports app to web measurement (https://webkit.org/blog/11529/introducing-private-click-measurement-pcm/#:~:text=App%2Dto%2DWeb%20Click%20Measurement). On iOS, some web to app measurement is supported via SKAdNetwork (https://developer.apple.com/documentation/skadnetworkforwebads). There is currently no interop between these proposals and the cross app web API for Attribution Reporting.

If Blink ever ships on iOS (at least in the EU, given recent announcements by Apple), would it be possible to expect interop between iOS and Android?

Gecko: No official position (https://github.com/mozilla/standards-positions/issues/791#issuecomment-1908359889)

Any reason we didn't file a new issue w/ Mozilla (or TAG...), but we did with WebKit?

WebKit: No official position (https://github.com/WebKit/standards-positions/issues/307)

Web developers: Positive. Some testers are currently implementing and providing feedback and more usage expected in 2024. Developers have requested expansion of coverage of this feature (example: https://github.com/WICG/attribution-reporting-api/issues/1125).

Debuggability

The Attribution Reporting API utilizes DevTools and an internal page (chrome://attribution-internals) to facilitate testing and integration. The debugging information for OS registrations from Chrome will be displayed in DevTools and the internal page as well. 

Additionally, debug reports are supported for OS registrations. The Attribution Reporting API for Android also implements a similar debugging reports framework to facilitate cross app and web testing.

              

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

The Attribution-Reporting-Support header is supported on all platforms. Today, only Android offers a native Attribution Reporting API, so the ability to register with the OS is only supported on those platforms (Android and Android WebView).

Is this feature fully tested by web-platform-tests?

The Attribution-Reporting-Support header is tested by web platform tests, but the integration with OS is not as web platform tests are not supported for Android.

Requires code in //chrome?

False

Estimated milestones

Chrome 123

Launch bug

https://launch.corp.google.com/launch/4238495

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4994430156668928

Links to previous Intent discussions

Cross App and Web Attribution Measurement Intent to Experiment

Cross App and Web Attribution Measurement Intent to Extend Experiment

Attribution Reporting API Intent to Ship

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BVrgP%3DZDhgDguTkPXBnPOk8CpOVkxKHyBoeUR9%3D43c7p6wZuw%40mail.gmail.com.

[Nan Lin]

Hi Mike,

Thanks for reviewing. Please see responses inline.

Nan

On Mon, Feb 5, 2024 at 9:33 PM Mike Taylor <mike...@chromium.org> wrote:

Hi Nan,

On 2/2/24 5:00 AM, Nan Lin wrote:

Contact emails

lin...@chromium.org, john...@chromium.org

Explainer

Cross App and Web Attribution Measurement

Specification

https://wicg.github.io/attribution-reporting-api/#cross-app-and-web

Summary

This is an extension to the Attribution Reporting API that has already shipped.

Currently, the Attribution Reporting API supports attributing events within a single browser instance. This proposal expands the scope of attribution to allow attributing conversions that happen on the web to events that happen off the browser on the same device, within other applications such as mobile applications, or vice-versa.

The proposal here leverages OS-level support for attribution. In particular, it gives the developer an option to allow events on the mobile web to be delegated to Android’s Privacy Sandbox, although support for other platforms could also be implemented in the future.

Note that with this proposal new features shipped by the OS may be implicitly supported without web API changes. For example, Android may ship support for new registration fields not supported in the existing Attribution Reporting API. Once a developer elects to delegate events to the OS, there is no way web-visible to introspect this.

Could you help me better understand the implications of this? Does it just mean that debugging becomes challenging for new fields, or are there other possible implications depending on new OS features? Or possibly the web API lags behind what is possible via the platform, until the web API catches up formally?

It’s not about debugging. Currently the web API and the Android’s implementation of the Attribution Reporting API are expected to be interoperable. However it’s possible that Android may ship support for new registration fields in the OS-level API, which may or may not be supported in the web API. The web API may lag behind, or even not implement the new features at all. Once the event is delegated to the OS, the attribution registration will be handled by the OS and possibly using the new features in its API. This can happen without web API change and there’s no way web-visible to introspect this.

Blink component

Internals > AttributionReporting

TAG review

https://github.com/w3ctag/design-reviews/issues/724#issuecomment-1908353938

TAG review status

Pending

Risks

                 Interoperability and Compatibility

See the Attribution Reporting API I2S for information on the other general measurement proposals in this space.

Private Click Measurement in Safari supports app to web measurement (https://webkit.org/blog/11529/introducing-private-click-measurement-pcm/#:~:text=App%2Dto%2DWeb%20Click%20Measurement). On iOS, some web to app measurement is supported via SKAdNetwork (https://developer.apple.com/documentation/skadnetworkforwebads). There is currently no interop between these proposals and the cross app web API for Attribution Reporting.

If Blink ever ships on iOS (at least in the EU, given recent announcements by Apple), would it be possible to expect interop between iOS and Android?

There’s no official position from WebKit yet, but there’s some concern on the interoperability between Safari’s Private Click Measurement and the Attribution Reporting API. We may expect similar concerns on supporting Attribution Reporting API on iOS, therefore would not expect interoperability between iOS and Android in the short term.

Gecko: No official position (https://github.com/mozilla/standards-positions/issues/791#issuecomment-1908359889)

Any reason we didn't file a new issue w/ Mozilla (or TAG...), but we did with WebKit?

We initially requested feedbacks for TAG, Mozilla and Webkit all in the comments of the Attribution Reporting API requests as it’s an extension of that API. We were then suggested by WebKit folks to file a new issue instead as it’s easier for their system to handle new requests.

[Mike Taylor]

On 2/6/24 3:59 AM, Nan Lin wrote:

Hi Mike,

Thanks for reviewing. Please see responses inline.

Nan

On Mon, Feb 5, 2024 at 9:33 PM Mike Taylor <mike...@chromium.org> wrote:

Hi Nan,

On 2/2/24 5:00 AM, Nan Lin wrote:

Contact emails

lin...@chromium.org, john...@chromium.org

Explainer

Cross App and Web Attribution Measurement

Specification

https://wicg.github.io/attribution-reporting-api/#cross-app-and-web

Summary

This is an extension to the Attribution Reporting API that has already shipped.

Currently, the Attribution Reporting API supports attributing events within a single browser instance. This proposal expands the scope of attribution to allow attributing conversions that happen on the web to events that happen off the browser on the same device, within other applications such as mobile applications, or vice-versa.

The proposal here leverages OS-level support for attribution. In particular, it gives the developer an option to allow events on the mobile web to be delegated to Android’s Privacy Sandbox, although support for other platforms could also be implemented in the future.

Note that with this proposal new features shipped by the OS may be implicitly supported without web API changes. For example, Android may ship support for new registration fields not supported in the existing Attribution Reporting API. Once a developer elects to delegate events to the OS, there is no way web-visible to introspect this.

Could you help me better understand the implications of this? Does it just mean that debugging becomes challenging for new fields, or are there other possible implications depending on new OS features? Or possibly the web API lags behind what is possible via the platform, until the web API catches up formally?

It’s not about debugging. Currently the web API and the Android’s implementation of the Attribution Reporting API are expected to be interoperable. However it’s possible that Android may ship support for new registration fields in the OS-level API, which may or may not be supported in the web API. The web API may lag behind, or even not implement the new features at all. Once the event is delegated to the OS, the attribution registration will be handled by the OS and possibly using the new features in its API.

Thanks for the response! I'm still trying to understand what a registration field is in the context of this API - is that a possible future item added to the OS registration struct in https://wicg.github.io/attribution-reporting-api/#os-registration? (Apologies, I can't find any reference to "registration field" in the draft spec...).

This can happen without web API change and there’s no way web-visible to introspect this.

OK, so introspection here is not about debugging, but being able to make decisions programmatically at runtime? Is that correct?

Blink component

Internals > AttributionReporting

TAG review

https://github.com/w3ctag/design-reviews/issues/724#issuecomment-1908353938

TAG review status

Pending

Risks

                 Interoperability and Compatibility

See the Attribution Reporting API I2S for information on the other general measurement proposals in this space.

Private Click Measurement in Safari supports app to web measurement (https://webkit.org/blog/11529/introducing-private-click-measurement-pcm/#:~:text=App%2Dto%2DWeb%20Click%20Measurement). On iOS, some web to app measurement is supported via SKAdNetwork (https://developer.apple.com/documentation/skadnetworkforwebads). There is currently no interop between these proposals and the cross app web API for Attribution Reporting.

If Blink ever ships on iOS (at least in the EU, given recent announcements by Apple), would it be possible to expect interop between iOS and Android?

There’s no official position from WebKit yet, but there’s some concern on the interoperability between Safari’s Private Click Measurement and the Attribution Reporting API. We may expect similar concerns on supporting Attribution Reporting API on iOS, therefore would not expect interoperability between iOS and Android in the short term.

Thanks - ignoring the PCM API proposal, my question was more along the lines of if it would be possible to implement this proposal were Blink to be shipped on iOS (rather than the current Bling architecture), i.e., do the underlying iOS APIs allow for implementing this proposal. I don't think this is a blocking concern today, but an interesting interop concern for a future state.

[Nan Lin]

Thanks Mike.

On Wed, Feb 7, 2024 at 12:50 AM Mike Taylor <mike...@chromium.org> wrote:

On 2/6/24 3:59 AM, Nan Lin wrote:

Hi Mike,

Thanks for reviewing. Please see responses inline.

Nan

On Mon, Feb 5, 2024 at 9:33 PM Mike Taylor <mike...@chromium.org> wrote:

Hi Nan,

On 2/2/24 5:00 AM, Nan Lin wrote:

Contact emails

lin...@chromium.org, john...@chromium.org

Explainer

Cross App and Web Attribution Measurement

Specification

https://wicg.github.io/attribution-reporting-api/#cross-app-and-web

Summary

This is an extension to the Attribution Reporting API that has already shipped.

Currently, the Attribution Reporting API supports attributing events within a single browser instance. This proposal expands the scope of attribution to allow attributing conversions that happen on the web to events that happen off the browser on the same device, within other applications such as mobile applications, or vice-versa.

The proposal here leverages OS-level support for attribution. In particular, it gives the developer an option to allow events on the mobile web to be delegated to Android’s Privacy Sandbox, although support for other platforms could also be implemented in the future.

Note that with this proposal new features shipped by the OS may be implicitly supported without web API changes. For example, Android may ship support for new registration fields not supported in the existing Attribution Reporting API. Once a developer elects to delegate events to the OS, there is no way web-visible to introspect this.

Could you help me better understand the implications of this? Does it just mean that debugging becomes challenging for new fields, or are there other possible implications depending on new OS features? Or possibly the web API lags behind what is possible via the platform, until the web API catches up formally?

It’s not about debugging. Currently the web API and the Android’s implementation of the Attribution Reporting API are expected to be interoperable. However it’s possible that Android may ship support for new registration fields in the OS-level API, which may or may not be supported in the web API. The web API may lag behind, or even not implement the new features at all. Once the event is delegated to the OS, the attribution registration will be handled by the OS and possibly using the new features in its API.

Thanks for the response! I'm still trying to understand what a registration field is in the context of this API - is that a possible future item added to the OS registration struct in https://wicg.github.io/attribution-reporting-api/#os-registration? (Apologies, I can't find any reference to "registration field" in the draft spec...).

Sorry for the confusion. The registration field in the context of the Attribution Reporting API is a JSON field in the Attribution-Reporting-Register-Source (

https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#registering-attribution-sources) and Attribution-Reporting-Register-Trigger (

https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#triggering-attribution

) headers. Android also implements the Attribution Reporting API that supports header-based registration (

https://developer.android.com/design-for-safety/privacy-sandbox/attribution#enroll-ad-tech-platform). 

The workflow to delegate a web event to the OS is as follows:

1. In the web API, the reporting origin can respond with a list of registration urls in the Attribution-Reporting-Register-OS-Source and Attribution-Reporting-Register-OS-Trigger headers.

2.  The browser delegates the registration urls to the OS-level API.

3. The OS-level API makes a request to the registration url.

4. The registration url responds with the Attribution-Reporting-Register-Source or Attribution-Reporting-Register-Trigger header, which is handled by the OS-level API.

If the OS-level API supports a new registration field in the 

Attribution-Reporting-Register-Source or Attribution-Reporting-Register-Trigger JSON, in step 4 above the registration url could respond with the new registration field for new features supported in the OS-level API but not the web API.

Hope that clarifies.

This can happen without web API change and there’s no way web-visible to introspect this.

OK, so introspection here is not about debugging, but being able to make decisions programmatically at runtime? Is that correct?

Yes, that’s correct. Once the web event is delegated to the OS, the attribution registration will be handled by the OS-level API, and there’s no way for the web API to decide or even know the actual registration.

Blink component

Internals > AttributionReporting

TAG review

https://github.com/w3ctag/design-reviews/issues/724#issuecomment-1908353938

TAG review status

Pending

Risks

                 Interoperability and Compatibility

See the Attribution Reporting API I2S for information on the other general measurement proposals in this space.

Private Click Measurement in Safari supports app to web measurement (https://webkit.org/blog/11529/introducing-private-click-measurement-pcm/#:~:text=App%2Dto%2DWeb%20Click%20Measurement). On iOS, some web to app measurement is supported via SKAdNetwork (https://developer.apple.com/documentation/skadnetworkforwebads). There is currently no interop between these proposals and the cross app web API for Attribution Reporting.

If Blink ever ships on iOS (at least in the EU, given recent announcements by Apple), would it be possible to expect interop between iOS and Android?

There’s no official position from WebKit yet, but there’s some concern on the interoperability between Safari’s Private Click Measurement and the Attribution Reporting API. We may expect similar concerns on supporting Attribution Reporting API on iOS, therefore would not expect interoperability between iOS and Android in the short term.

Thanks - ignoring the PCM API proposal, my question was more along the lines of if it would be possible to implement this proposal were Blink to be shipped on iOS (rather than the current Bling architecture), i.e., do the underlying iOS APIs allow for implementing this proposal. I don't think this is a blocking concern today, but an interesting interop concern for a future state.

Thanks for explaining. To implement this proposal on iOS, it requires the iOS API to support a similar registration url based interface and handle the attribution registration. This is currently not supported by the underlying iOS API and we would not expect this happen in the short term. But I agree that it’s a reasonable interop concern in the future were Blink to be shipped on iOS.

[Nan Lin]

Also to clarify, we will remove the origin trial requirement for all platforms.

The feature will be shipped on all platforms except for Android WebView. Android WebView may have a slower rollout using Finch.

Thanks,

Nan

[Yoav Weiss (@Shopify)]

On Wed, Feb 7, 2024 at 12:58 PM Nan Lin <lin...@chromium.org> wrote:

Thanks Mike.

On Wed, Feb 7, 2024 at 12:50 AM Mike Taylor <mike...@chromium.org> wrote:

On 2/6/24 3:59 AM, Nan Lin wrote:

Hi Mike,

Thanks for reviewing. Please see responses inline.

Nan

On Mon, Feb 5, 2024 at 9:33 PM Mike Taylor <mike...@chromium.org> wrote:

Hi Nan,

On 2/2/24 5:00 AM, Nan Lin wrote:

Contact emails

lin...@chromium.org, john...@chromium.org

Explainer

Cross App and Web Attribution Measurement

Specification

https://wicg.github.io/attribution-reporting-api/#cross-app-and-web

Summary

This is an extension to the Attribution Reporting API that has already shipped.

Currently, the Attribution Reporting API supports attributing events within a single browser instance. This proposal expands the scope of attribution to allow attributing conversions that happen on the web to events that happen off the browser on the same device, within other applications such as mobile applications, or vice-versa.

The proposal here leverages OS-level support for attribution. In particular, it gives the developer an option to allow events on the mobile web to be delegated to Android’s Privacy Sandbox, although support for other platforms could also be implemented in the future.

Note that with this proposal new features shipped by the OS may be implicitly supported without web API changes. For example, Android may ship support for new registration fields not supported in the existing Attribution Reporting API. Once a developer elects to delegate events to the OS, there is no way web-visible to introspect this.

Could you help me better understand the implications of this? Does it just mean that debugging becomes challenging for new fields, or are there other possible implications depending on new OS features? Or possibly the web API lags behind what is possible via the platform, until the web API catches up formally?

It’s not about debugging. Currently the web API and the Android’s implementation of the Attribution Reporting API are expected to be interoperable. However it’s possible that Android may ship support for new registration fields in the OS-level API, which may or may not be supported in the web API. The web API may lag behind, or even not implement the new features at all. Once the event is delegated to the OS, the attribution registration will be handled by the OS and possibly using the new features in its API.

Can you provide an example of how future OS-level changes can result in semantics changes for the web exposed API?

Is the information flow here strictly from the web API to the OS API? Or is it possible for the OS attribution to flow into the web? (e.g. if an ad on a native app ends up landing on a website)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BVrgPn%2BCBi6AEExLWMrwRF9y68cs5GGQ4vhFPxXCHmwndZeCQ%40mail.gmail.com.

[Nan Lin]

Hi Yoav,

Please see my response below for the workflow to delegate a web event to the OS.

For example, the OS API implements a new feature, and allows developers to opt in this feature with a new field in the Attribution-Reporting-Register-Source/Trigger JSON.

The web API only delegates the registration url (to which the OS API will ping) to the OS API, and the registration url can respond to OS API ping with the new field in the Attribution Reporting response headers to opt in the new feature implemented by the OS API.

All the cross app web attribution is handled by the OS API. For app to web flow (an ad on a native app ends up landing on a website), the reporting origin can respond with Attribution-Reporting-Register-OS-Trigger header to delegate the trigger event to the OS API to perform the attribution within the OS API. So yes, the information flow is strictly from the web API to the OS API.

[Mike Taylor]

Thanks Nan for helping us better understand the feature.

LGTM1 given the following "...it’s possible that Android may ship support for new registration fields in the OS-level API, which may or may not be supported in the web API. The web API may lag behind, or even not implement the new features at all."

Shipping support for these new fields would require the Blink process - so we can evaluate future additions in the future (and I'm not worried about only supporting a subset of the OS-level API - if there is developer demand and utility to be gained from it, I suspect we'll eventually add support).

[Yoav Weiss (@Shopify)]

Thanks for the clarifications! 

For example, the OS API implements a new feature, and allows developers to opt in this feature with a new field in the Attribution-Reporting-Register-Source/Trigger JSON.

The web API only delegates the registration url (to which the OS API will ping) to the OS API, and the registration url can respond to OS API ping with the new field in the Attribution Reporting response headers to opt in the new feature implemented by the OS API.

All the cross app web attribution is handled by the OS API. For app to web flow (an ad on a native app ends up landing on a website), the reporting origin can respond with Attribution-Reporting-Register-OS-Trigger header to delegate the trigger event to the OS API to perform the attribution within the OS API. So yes, the information flow is strictly from the web API to the OS API.

So if the OS API registers an event source with a parameter that the Web API doesn't recognize, would that parameter be ignored when that event is triggered by the web API?

[Asif jutt Jutt]

Support on update 

Service delivery Manager

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d1f6e48f-32aa-46ad-9b9e-7237a3a664bf%40chromium.org.

[Nan Lin]

Hi Yoav,

The parameter would not be ignored by the OS API even if the event is triggered by the web API. When the event is delegated to the OS API, it will be completely handled by the OS API and can use all features available in the OS API even if some features may not be supported in the web API.

[Yoav Weiss (@Shopify)]

Does that mean that when a trigger is called on the web API in that scenario, that trigger would be delegated to the OS, and the OS would be the one doing the reporting?

[Nan Lin]

That’s right. This design places trust in the OS to process cross app web attribution reporting. When the trigger is delegated to the OS, it could be attributed to an app source, or a web source that was delegated to the OS, and an attribution report would be scheduled by the OS API if any.

[Yoav Weiss (@Shopify)]

LGTM2

That makes sense. Thanks for bearing with me :)

 

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BVrgP%3DZDhgDguTkPXBnPOk8CpOVkxKHyBoeUR9%3D43c7p6wZuw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Chris Harrelson]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5164e08a-c56c-4948-a72e-a2d7b86d0094n%40chromium.org.