Allow attribution to be scoped smaller than destination site

[johnivdel]

Currently, when a trigger is registered the browser looks up all sources which are registered within the destination site to perform attribution.

Once the matching source is found, the filtering feature can be used to control whether or not that attribution should continue. This has a number of short comings.

For example let's consider an advertiser site which hosts multiple stores and the following events: shop1.example.com and shop2.example.com

Source 1 registered publisher.test -> shop1.example.com
Source 2 registered publisher.test -> shop2.example.com

Trigger -> shop1.example.com

If we are using last touch attribution, source 2 will be matched to the trigger, even though source 1 should get attribution credit.

[bmayd]

We came across a similar effect from the use of reporting origin + destination eTLD+1 to match conversions.

What we'd ideally want to be able to do is count conversions for a campaign grouped by the impression source domains on which impressions for the campaign were shown across all browsers using aggregated data. So, when a conversion is triggered for a browser, we'd want to generate a list of the unique eTLD+1s of the impression source domains on which the browser showed an impression for the associated campaign. We would then assign each impression domain a value of 1, put it into a report which could be added to a batch sent to the aggregation service from which we would get a count the number of times each impression domain was associated with a conversion. This would provide us with a list of impression source domains for the campaign that could be ordered by conversion counts and allow us to identify the impression domains most often associated with conversions.

For example: browser1 sees impressions on running.example and walking.example and converts on sneakers.example. Browser2 sees impressions on waking.example and hiking.example and converts on sneakers.example. Browser3 sees impressions on walking.example, hiking.example and jogging.example. We would want to end up with:

walking.example: 3
hiking.example: 2
running.example: 1
jogging.example: 1

This will allow us to identify which impression domains are most frequently associated with conversions.

My original thinking was that we'd be able to use the event-level ARA to take a step toward this if we could get the impression domain that led to a conversion, but I didn't think it through. Because event-level ARA identifies only a single impression per conversion trigger, and because the match is done on the basis of reporting origin and conversion domain, we won't be able to do per-campaign attribution, only per-advertiser destination eTLD+1.

In the above example, if we ran 2 campaigns for sneakers.example with campaign1 targeting running.example and campaign2 targeting walking.example and campaign2 ran after campaign1, default event-level ARA, because it triggers conversions for both campaigns on sneakers.example, would consistently show walking.example outperforming running.example because campaign2 impressions would be last touch and supersede and hide campaign1 impressions. Our reporting would show a disproportionate number of campaign2 conversions, not because campaign2 was better performing, but only because it ran after campaign1.

We considered using the priority field, but that won't resolve the issue, it will just change how it impacts us. For example, if we were to give campaign1 impressions a priority of 2 and campaign2 impressions a priority of 1, we'd just effectively end up shifting from campaign2 hiding campaign1 impressions to campaign1 hiding campaign2 impressions.

This is different from cookie-based attribution in that with cookie-based there is an opportunity to record all of the impressions shown on a browser by cookie ID and campaign ID and that allows us to attribute conversions to the cookie ID and therefore all impressions associated with it. This means we can see all of the domains on which impressions are shown that contribute to conversions for a given campaign. Even in cases where we only get last-touch cookie attribution, we're still able to do it by campaign which allows us to test different strategies and optimize based on campaign attributes.

With event-level ARA we get a non-representative sample of converting impression domains across all campaigns for an advertiser, which is likely to make using event-level ARA impractical and/or cost prohibitive.

I've reviewed ARA summary reporting to try and figure out if we can use that, but the documentation gets pretty hard to follow and I haven't been able to piece together if it could support multiple concurrent campaigns for the same destination or not; my sense is it does not since it also does not have a means of distinguishing the campaign a trigger is associated with.

The situation would be improved if there was a way of indicating what campaign or set of campaigns a trigger was associated with. In the cookie world this is sometimes done by creating campaign-specific landing pages. To use John's example above, the campaign for shop1.example.com could register shop1.example.com instead of example.com as the destination and the browser could match triggers from shop1.example.com to those impressions specifically.

[arpanah]

@akashnadan @vikassahu29

[bmayd]

A colleague just pointed out that there can be multiple (up to 3) destinations defined on a source registration, a change I missed when it was added in the end of 2022. I'm mentioning it because it further complicates the issue identified above: if multiple campaigns which target overlapping subsets of destinations are run concurrently, the most recent, highest priority impression registered across all of the campaigns that share a destination will be matched to a conversion. This makes it very difficult, if not impossible, to understand how campaigns are performing.

With event-level ARA a report includes attribution_destination, but it isn't clear what that is; whether it is the set of destinations registered at impression source registration time or just the eTLD+1 of the attribution trigger page. If it is the set of registered destinations it potentially creates even uncertainty about what is happening across campaigns.

[dmdabbs]

I suspect that

the attribution destination set on the source

is wording dating to when source registrations supported a single destination and not up to three.

Would it be clearer as

the site where the attribution is triggered (matched to a value(s) in the attributed source)

[akashnadan]

@bmayd regarding the attribution_destination field in the event-level ARA report, this would be the set of destinations registered at impression source registration time.

Regarding the original post, we are working on a new feature that will help to address part of this. More details can be found in the following PR: #1215

This proposal should help with "indicating what campaign or set of campaigns a trigger was associated with" because it will allow you to set pre-defined attribution scopes (more details in the PR) on both the source and trigger. This can help with filtering for specific campaigns if there are multiple campaigns for the same product. And we plan to post additional details regarding this proposal soon!

[bmayd]

Thanks for the reply. To make sure I'm clear regarding:

...regarding the attribution_destination field in the event-level ARA report, this would be the set of destinations registered at impression source registration time.

You are saying if the impression registered destination is: ["domain1.example", "domain2.example"] and a conversion is triggered on domain1.example the attribution_destination in the subsequent event-level report would include the full array and not just domain1.example?

More details can be found in the following PR: #1215

Saw the PR and it seems promising, but wasn't able to get a good sense of what is being proposed from trying to skim it; looking forward to the additional details.

[akashnadan]

@bmayd regarding the attribution_destination field, your example above is correct. The event-level report would include the full array and not just domain1.example.