Skip to content
This repository was archived by the owner on Jun 25, 2026. It is now read-only.

2022-04-04-minutes.md

Latest commit

 

History

History
147 lines (119 loc) · 11 KB

2022-04-04-minutes.md

File metadata and controls

147 lines (119 loc) · 11 KB
Raw

Attribution Reporting API

April 4th, 2022 @ 8-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: #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: John Delaney Scribe volunteer: TBD

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

  • Developer update
    • The new version of the API is available in Chrome
    • You can try it out today in your browser (and in the future, with end users as part of an origin trial)
    • Supported today in your browser:
      • Event-level reports and aggregatable reports.
      • Click-through and view-through measurement.
      • Debug reports, to compare your cookie-based results and your attribution-reporting-based results.
      • Additional features, such as filters for more flexibility in your attribution logic, and improved support for multiple reporters.
    • Detailed developer guides are available here—see the migration guide, the overview, and the handbook (complete API guide).
    • Try the demo
  • WICG/turtledove#281
  • #371
  • #373

Attendees — please sign yourself in!

(Please sign in at the start of the meeting)

  1. Angelina Eng (IAB)
  2. Wendell Baker (Yahoo)
  3. Graham Mudd (Anonym)
  4. Martin Pal (Google Chrome)
  5. Brad Smallwood (Anonym)
  6. Aloïs Bissuel (Criteo)
  7. Andrew Paseltiner (Google Chrome)
  8. Leon Yin (Microsoft)
  9. Alex Cone (IAB Tech Lab)
  10. Michael Kleber (Google Chrome)
  11. Alexandru Daicu (Eyeo)
  12. Brian May (dstillery)
  13. Jonasz Pamuła (RTB House)
  14. Matt Lamont (AdTheorent)
  15. Robert Kubis (Google Chrome)
  16. Christina Ilvento (Google Chrome)
  17. Manny Isu (Google Chrome)
  18. Alexandru Mihai (Eyeo)
  19. John Delaney (Google Chrome)
  20. Shivani Sharma (Google Chrome)
  21. Paul Jensen (Google Chrome)
  22. Alex Turner (Google Chrome)
  23. Andrew Pascoe (NextRoll)
  24. Russell Stringham (Adobe)
  25. Erik Taubeneck (Meta)
  26. Phillipp Schoppmann (Google)
  27. Daniel Rojas (Google Chrome)

Notes

Maud: developer update.

  • Maud: New version of API available in Chrome.

  • Jonasz: How can we test aggregatable reports? Is the aggregation binary already available?

  • Martin: You can enable the debugging functionality, so that you can collect event-level reports that are meant for the aggregation server. The aggregation binary should be available in a couple of weeks.

  • John: look through the handbook doc. Really good resource. Also updated explainers.

  • Angelina: how are folks doing a test. Are you working with advertisers, or doing a test without advertisers. Trying to figure out with IAB how to work with advertisers.

  • Christina: Are you asking about Google ads, Chrome, others?

  • Angelina: any adtech

  • Alois from Criteo: We intend to test these APIs, participate in the OT. Do it ourselves, without involving advertisers. Check against our data, see if usable.

  • Criteo has participated in earlier OTs -- e.g. FLOC. have published reports. Intend to publish in the future.

  • Brian May: Would Criteo be willing to take suggestions no wat to look at?

  • Alois: happy to connect with Criteo folks

  • Angelina: At IAB, putting together testing frameworks. Please reach out.

Next agenda item: Turtledove question about event-level API

  • Jonasz: Posted last week. How attribution api works with fledge. Not obvious. Require registering a click. Need to extend the anchor tag, provide click-side information. In FLEDGE, the ad will be in a fenced frame. A more useful way would be to use contextual data.

    • Conceptually, would it be OK to use contextual data for source registration, and is it feasible technically.

  • John : on attribution reporting side. Lot of information set in the impression ping. TBD whether this should be set on contextual info, or info about the ad. E.g. priority, filters. Default assumption is that this is set based on the ad rather than contextual. Also, need to consider how this interacts with multiple reporters.

    • Att reporting can have multiple reporters (e.g. 3p measurement companies -- pixel). Careful that solution works with different origins that want different behavior.

  • Michael: John asking the right questions. API as designed out of the box may not be good enough. The way the flow would work, inside fenced frame you can generate random event_id (in javascript), attach as attribution source id. Also use as event data passed from fenced frame to event level infra using report event api, described in https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#reportevent

    • Setting additional metadata may not be possible if the only thing attached to click is random event id. If events in fenced frame require extra data, we'll need to add an API that lets data outside fenced frame be attached to event within the FF. If worklet wants to report one way, the ad wants other way.

  • John: with current API, possible to use the random ID to join data from within FF with data outside. Requires logjoin.

  • Michael: weaknesses: e.g. can't set priority

  • John: how combining info from inside and outside FF. API shape not ideal. Have server request to register event. If TURTLEDOVE/FLEDGE changes, reporting needs to change.

  • Michael: flow has info from ad selection time sent to server; response from server gets attached to the attribution event.

  • J: For aggregate: keys need to be set this way.

  • M: at bidding time, have contextual info and user-specific info. FLEDGE tries to avoid mixing the two.

  • Shivani: 2 points. Reporting infra has not response for report event -- one-way info from browser. We'll have to see if response can come from server, what are privacy implications.

    • Beacon state: not arbitrary contextual information, only what’s available to the worklet at reportWin time.

  • Brian: didn't feel right to provide contextual + fledge info outside of browser.

    • Is the intent to have people work off the interest groups provided. Maybe reporting should tell what the interest group was.

  • Michael: what you describe is desired end state. Interest group signals should go through aggregate reporting. At outset, we'll allow event level reporting to get things started, then move to aggregate reporting.

  • John: attribution reporting discloses pub site in the clear. For example privacy budgeting in aggregate API.

  • Angelina: affiliate marketing requires compensation to publisher. Advertisers need to know the publishers, know which pub drives quality ROI. Post click site engagement on adv site (do CNN bring more engaged users than another pub). If we don't know the pub, can't optimize. Want to understand at placement level. Which page (politics, tech, sports)

  • Michael: these sound like use cases for aggregate reporting. Aggregate reports -- assuming we have good APIs to attach contextual and ad campaign data to the ad event.

  • Jonasz: thanks for proposing the solution. Missed the part of the spect that says we can attach data from FF to the event-level conversion event.

    • When networking is blocked in FF, will attribution reporting work out of the box (e.g. ping to registration server)?

  • John: can someone from FF comment

  • Michael: In the long term, we want aggregate reporting to be the solution. Event level solution is a stop-gap until we get to aggregate.

  • Jonasz: FF will have no access to internet. For source registration, internet access is necessary

  • Michael: yes, roundtrip to server required. Today, FF has network access. Agreem the API isn't compatible with end state. Won't break stopgap solution until we have final solution.

  • John: depends how we handle network access restriction. Right now, server request is needed to validate that server wants to register. Challenge to make this work; in theory possible.

  • John: AI to post summary on the issue.

  • Jonasz: follow-up on aggregate reporting + fledge. Seems that a technical extension may be needed.

  • John: let's start on issue first; then talk in mtg

  • Brian: people from both msmt and fledge streams should be aware

  • John: thanks FLEDGE folks for attending; can drop off now

#371

Leon Yin from MSFT: question about encoding.

  • Data encoding section. Source id 64 bits. Browser allowed to shorten the ID. Could be collisions. Can we know how many bits ahead of time, so that we can design best ID scheme to avoid collisions.

  • John: the reason we have the section: private click msmt. Lower entropy impression side information. We wanted to allow interoperability. Any browser that supports this API, should allow for large enough IDs. If a browser wants to set this lower -- want to hear. For now, assume the ID can be unique.

#373

  • John: High level. Currently event level reports click -> 3 reports. Advertiser can register >3 conversions. Browser will prioritize, choose 3 with highest priority.

    • In agg API, no limit on # convs per click/source. No way to prioritize the conversions. API will generate report for each conversion. Can use filtering to decide what contribution to generate.
    • One idea to make it more flexible: say measuring pageview convs. Only want one pageview conversion per click. We'd like to understand how adtechs would want to use this. Feel free to follow up offline. Complicated topic.

  • Angelina: Is there another example you can come up with? Ex: advertisers would look at various events leading up to conversion, but not related to conv. Say landing page -- much lower prio than conversion, but useful to measure. View of the product page. Can you explain.

  • John: say for landing page, shopping cart, purchase. For each, have the ability to set what you measure based on conv/imp. What you don't have control over is the flow.

    • Say you have 3 purchases, the 3rd is super valuable, the first two not so much. Ideally, want to measure a lot on the 3rd purchase. What if browser could provide extra signals (e.g. 2 conv events in a short time span -- perhaps drop one of them). Overall theme: make sure the budget is easy to manage.