Hi Yoav,
On Thu, Feb 8, 2024 at 11:09 PM Yoav Weiss (@Shopify)
<[email protected]> wrote:
On Wed, Feb 7, 2024 at 12:58 PM Nan Lin <[email protected]> wrote:
Thanks Mike.
On Wed, Feb 7, 2024 at 12:50 AM Mike Taylor
<[email protected]> 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
<[email protected]> wrote:
Hi Nan,
On 2/2/24 5:00 AM, Nan Lin wrote:
Contact emails
[email protected] <mailto:[email protected]>,
[email protected] <mailto:[email protected]>
Explainer
Cross App and Web Attribution Measurement
<https://github.com/WICG/attribution-reporting-api/blob/main/app_to_web.md>
Specification
https://wicg.github.io/attribution-reporting-api/#cross-app-and-web
<https://wicg.github.io/attribution-reporting-api/#cross-app-and-web>
Summary
This is an extension to the Attribution Reporting
API
<https://github.com/WICG/conversion-measurement-api>that
has already shipped.
Currently, the Attribution Reporting API
<https://github.com/WICG/conversion-measurement-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
<https://developer.android.com/design-for-safety/privacy-sandbox/attribution>,
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)
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.
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
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EAttributionReporting>
TAG review
https://github.com/w3ctag/design-reviews/issues/724#issuecomment-1908353938
<https://github.com/w3ctag/design-reviews/issues/724#issuecomment-1908353938>
TAG review status
Pending
Risks
Interoperability and Compatibility
See the Attribution Reporting API I2S
<https://groups.google.com/a/chromium.org/g/blink-dev/c/2Rmj5V6FSaY>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
<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
<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.
Gecko: No official position
(https://github.com/mozilla/standards-positions/issues/791#issuecomment-1908359889
<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.
WebKit: No official position
(https://github.com/WebKit/standards-positions/issues/307
<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
<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.<https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#optional-transitional-debugging-reports>
Additionally, debug reports
<https://github.com/WICG/attribution-reporting-api/blob/main/app_to_web.md#optional-debugging-reports>are
supported for OS registrations. The Attribution
Reporting API for Android also implements a similar
debugging reports framework
<https://developer.android.com/design-for-safety/privacy-sandbox/attribution-app-to-web#transitional-debugging>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
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
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
<https://launch.corp.google.com/launch/4238495>
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4994430156668928
<https://chromestatus.com/feature/4994430156668928>
Links to previous Intent discussions
Cross App and Web Attribution Measurement Intent to
Experiment
<https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/gTvI5x-qex8>
Cross App and Web Attribution Measurement Intent to
Extend Experiment
<https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/0drGQpsOKh0>
Attribution Reporting API Intent to Ship
<https://groups.google.com/a/chromium.org/g/blink-dev/c/2Rmj5V6FSaY>
--
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
[email protected].
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BVrgP%3DZDhgDguTkPXBnPOk8CpOVkxKHyBoeUR9%3D43c7p6wZuw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BVrgPn%2BCBi6AEExLWMrwRF9y68cs5GGQ4vhFPxXCHmwndZeCQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
