Multiple Impression Registrations on Existing Tracking Pings

[chandan-giri]

Multi Conversion Domain Tracking
Advertisers may track conversions on different conversion domains than original click/impression destinations. Eg: User clicks on an Ad and lands on advertiser.us, performs interactions to further navigate and convert on advertiser.com. If we register for only the click/impression domain, AdTech will not be able to track conversions on advertiser.com. It can also happen for the above case that AdTech is tracking page view conversion on advertiser.us and purchase conversion on advertiser.com domain. For a given ad click or impression, AdTech may need to register multiple impressions for a given Ad.

1. The additional impressions are always registered as views. For these additional impressions registrations, view validations and corresponding 1 conversion per view limits for EventApi will apply. This is true even when the original event is a click. Hence for these additional impression registration, we will not validate that registration destination matches click destination.
2. The “source_event_id” of these impression registrations may be all different and depend on AdTech implementation.
3. Aggregation dimensions may change from original event registration and depend on AdTech implementation. AdTech may want to measure conversions for these x-domain registration slices. Eg: For the case where the original event is a click, 3 bits conversion metadata and 3 conversions per click is tracked for original click whereas 1 bit conversion metadata and 1 conversion per click is tracked for additional view registrations.
4. Attribution filters may change from original events since newer aggregation dimensions and conversion metadata may be output differently for cross-domain registrations. Eg: For the original click 3 bits of metadata will be output, however for additional x-domain view registrations, only 1 bit of metadata is allowed.

Constraints With Current Proposal

1. Support for 3rd party trackers: 3rd party trackers can only register impressions on click tracking pings. Currently there is no mechanism available to register additional views to track cross-domain conversions. Also for click, these cross-domain registrations will be rejected since destination doesn’t match click destination.
2. Rendering/Serving overhead: For current registration mechanism, changes are likely required in rendering/serving of all ad formats to fire new registration pings. Newer feature requests will remove these overheads and make integration more convenient.
3. Additional Network Requests: Since currently only one registration is allowed per registration ping, new registration pings order of magnitude of additional cross-domain registrations is generated. The # of request pings will increase by lot for such use cases.

Feature Request
We are requesting the following extension to the current impression registration mechanism

1. Allow for multiple events registration for given registration ping.
2. Allow for events registration to be downgraded as view. For these explicitly downgraded views’ registration, the view registration validation will apply.
3. Add destination to registration and attribution debug reports. For the cases where AdTech opts to use the same source_event_id for all click/view registrations, <source_event_id, destination, {user_agent | device}> will create a unique identifier for registered events.

Example sample response:
Attribution-Reporting-Register-Sources [
// Original click. Validation is computed for click registration.
{
"source_event_id": "123456",
"destination": "advertiser.com",
…
},
// View registered for another conversion domain. Validation is computed for
// click registration.
{
"source_event_id": "987654",
"destination": "conversion-page1.com",
// If set to false, use the original source inference: {event, navigation}.
“register_source_as_event”: “true”,
…
},
// View registered for another conversion domain. Validation is computed for
// click registration.
{
"source_event_id": "567891",
"destination": "conversion-page2.com",
// If set to false, use the original source inference: {event, navigation}.
“register_source_as_event”: “true”,
…
},
...]

[csharrison]

With the recent changes to remove the landing page constraint on navigation sources, I think we have the opportunity to come up with a more holistic solution to this problem of multiple conversion domains. Previously, we required sources to only register a single destination to align with that requirement, and satisfy the additional browsing-history protections we wanted for navigation sources.

However, with that constraint no longer applicable, we can re-evaluate whether we can simply allow multiple destinations on a single source registration (for both navigation and event sources). I believe that provides strictly improved utility over this proposal, because:

• We no longer require view-downgrades for auxiliary destinations on navigation sources, they will get the full CTC privacy parameters
• There is less risk of overcounting conversions due to duplicate source registration targeting different trigger domains
• We no longer spam the system with duplicative information, which fills up users’ device storage unnecessarily and makes it easier to hit rate limits

Concretely, we can extend the registration syntax for the destination field in the JSON to optionally take a list of sites, where we would cap the list at a certain number (e.g. 3-5). Then, when a trigger registration occurs on a particular site, for a particular reporting origin, we would scan through all of their pending sources and find those which include the current site in the destination list. Any rate-limits that are keyed by the trigger destination will still be applied by considering the site where the trigger actually occurred (the “effective” trigger destination).

Additionally, the attribution_destination field on attribution reports would be updated to include the entire list, for event-level reports which specified a list in the source registration. The field would be unchanged for aggregatable reports (lest we reveal more information about the source registration).

The privacy implications for this change in isolation is fairly benign. Rather than an event-level report revealing information that the user visited the given destination site, a report reveals that the user visited one of the sites in the destination site list. This should only slightly increase cross site information gain for a limited adversary that cannot predict in advance where the user will convert. For worst-case adversaries this should be privacy neutral.

I believe this proposal should fully close out the use-cases listed in this issue and also in #44, but LMK if there's something I'm missing.

[csharrison]

Closing, confirmed this fixes the issue