Skip to content

Latest commit

 

History

History
83 lines (73 loc) · 5.4 KB

2025-01-15-minutes.md

File metadata and controls

83 lines (73 loc) · 5.4 KB

Attribution Reporting API

Wed Jan 15, 2025 @ 9am PT

This doc: bit.ly/ara-meeting-notes

Meet link: https://meet.google.com/jnn-rhxv-nsy Previous meetings: https://github.com/WICG/conversion-measurement-api/tree/main/meetings Meeting issue: https://githubhttps://github.com/WICG/conversion-measurement-api/issues/80.com/WICG/conversion-measurement-api/issues/80

  • Use Google meet “Raise hand” for queuing.
  • If you can’t edit the doc during the meeting, try refreshing as permissions may have been updated after you loaded the page.
  • If you are not admitted to the meeting, try rejoining. Google Meet has some UI that makes it easy to misclick if someone simultaneously requests to join while someone else is typing into the meeting chat.
  • Please make sure to join W3C and WICG if you plan on participating

Agenda

  • Chair: Haley Patoski, Arpana Hosabettu
  • Scribe volunteer: Charlie Harrison

Please suggest agenda topics here! (either in a comment or a suggestion on the doc:

Cross app and web attribution implementation guidance and clarification - as described in our recently published guide

Attendees — please sign yourself in!

(Please sign in at the start of the meeting)

  1. Arpana Hosabettu (Google Privacy Sandbox)
  2. Brian May (unaffiliated)
  3. Lior Golan (Taboola)
  4. Eyal Segal (Taboola)
  5. Liran Segev (Taboola)
  6. Charlie Harrison (Google CHrome)
  7. Aloïs Bissuel (Criteo)
  8. Nan Lin (Google Chrome)
  9. Michal Kalisz (Rtb House)
  10. David Dabbs (Epsilon)
  11. Roi Shemi (Taboola)
  12. Haley Patoski (Google Chrome)
  13. Matt Lamont (Cadent/AdTheorent)
  14. Stacy Andrade (Cadent/AdTheorent)

Notes

  • Cross app and web attribution implementation guidance and clarification - as described in our recently published guide

  • Haley: the ARA natively supports x app and web on the same device. Needs ARA enabled on both. ARA support header returns what platform support is available OS, Web, or both. Tells you what your options are

    • Source Chrome → can only be matched w/ Chrome triggers
    • Source OS → can only be matched w/ OS triggers
    • When you might want to delegate (to OS): When registering in Chrome, you can delegate to one of the platforms. Attribution happens independently across OS and Chrome
    • If you don’t know where they are occurring, delegate both to OS. Even if both occurred on Web, they can still be matched (by OS)
    • Avoid duplicating: registering both Chrome and OS → hard to deduplicate

  • Eyal Segal: source Web, trigger OS → cannot be matched

  • Lior Golan: Pixel on website, that advertiser can get traffic from apps and web. We don’t know whether traffic came from web or OS. How is it supposed to work?

  • Haley: we would recommend you register with the OS. Even if the source happens on the web, you can delegate it to the OS. When the OS support is available, you can delegate the source to the OS.

  • Arpana: you don’t need presence on the app itself to register source w/ the OS. Pixel on the browser is fine. Browser initiates an HTTP call. You tell the browser to delegate to OS, send request to OS.

  • Lior Golan: same website can get traffic from Chrome on windows, Chrome on Android, app on android. We don’t want a separate website for different platforms. Single pixel there can get traffic from No OS support (windows) and OS support (OS or browser level).

  • Charlie - Basic algo runs on the server. Server gets the request and pixel will fire telling you whether there is OS support or not which tells you whether you are on windows or not and what you need to do is unconditionally you register with OS if its available but on windows you can choose to do Web. So on places where you chose OS - it will always do matching and attribution at the OS layer handling it correctly.

  • Lior - Repeat for understanding

  • Lior: maybe we can make this a bit more clear in documentation (if I am benchmark for average reader)

  • Haley: we can make documentation more clear. Default to the OS when it is available.

  • Lior: thank you

  • Haley:

    • Setting: source on app and trigger on web
    • App side, they can only register with OS. Goes to OS version of ARA
    • Trigger on web, start w/ registering trigger and will receive ARA support header, indicating both App and Web support are available
    • Choosing OS → Delegate to Android. Chrome will pass off to Android
    • Then Android will send you a final request, responding back gives all the config
    • Web source and app trigger
    • Register web source with OS if available
    • Register app with OS (only availability)
    • For campaigns with both app and web destinations
    • Support dual destinations (app package or web URL)
    • If you do this, event-level reports will tell you the destination, but we need to add additional noise. You can opt-out of this with coarse event reporting
    • Webviews: Some nuances here
    • Webviews only support OS level attribution, we don’t support web
    • You have to delegate to OS
    • App needs to have correct manifest permissions for ARA
    • App rendering webview can configure whether sources are associated w/ App itself, or with top level domain of the webview.
    • Default: Sources → app, triggers tld

  • Roi Shemi: Enrollment defines the URL that is enrolled. End to end happened, the URL changes. Does that match for destination?

  • Vikas: enrollment is separate from destination.

  • Roi: I did open two cases for this one. Will ping this issue

  • Brian: some issues with the google group invite

  • Thanks everyone for participating