Hey @eysegal , this use-case should be supported to some extent now that we have support for multiple destinations (#601). Here is how you can do it:

1. In source registration, list out all relevant domains in the destination field, which takes a list (spec link). Currently the maximum limit is 3.
2. For aggregatable reports, they will come with the correct effective destination in the clear, so it is simple to get breakouts by domain
3. For event-level reports, we cannot reveal directly the domain because it leaks too much information. To get domain-level breakouts with the event-level API, you will need to encode the domain in the low-entropy trigger_data at trigger registration.

Let me know if this makes sense.

@csharrison - following up here to see if the three destinations option is for the root domain (i.e., foo.com) or sub-domain (i.e., bar.foo.com) - I didn't find them in the spec. Can you please direct me here?
Thank you

@omriariav

following up here to see if the three destinations option is for the root domain (i.e., foo.com) or sub-domain (i.e., bar.foo.com) - I didn't find them in the spec. Can you please direct me here?

The source registration destination field may be either a single eTLD+1 or a list of 1-3 eTLD+1s. You can experiment with the header validator to see what types of values are allowed.

@apasel422 the spec @csharrison mentioned does not explain (at least I didn't manage to understand) what is valid value. When looking at what is eTLD/eTLD+1 in this link - we see that sub-domain can be included.

However, when we test it in the header validator, it returns an error:
{"destination":["https://foo.example.test", "https://bar.example.test", "https://other.test"]}

I get:

Errors:

Warnings:

["destination"][0] URL components other than site (https://example.test) will be ignored
["destination"][1] URL components other than site (https://example.test) will be ignored
["destination"][1] duplicate value https://example.test

We either need to update the spec or agree on what eTLD/eTLD+1 includes regarding sub-domains.

It's important to mention that in real-life usages, we see subdomains coming from different destinations/the same ones, and we want to ensure we can attribute them.

Hi,
I want to ask an even more specific question. According to current spec, let's take the following user journey:

1. Ad click
2. foo.example.test - clicking on button X on this page triggers a conversion A and also leads to
3. bar.example.test - clicking on button Y on this page triggers a conversion B

In this use case, what should we send in the destination array on ad click?

@omriariav

The specification is primarily written for implementation authors, not users of the API, but it does use the concept of site for destinations, which is equivalent to eTLD+1 with a scheme (for Attribution Reporting, almost always https:// but in some rare cases http://).

https://foo.example.test and https://bar.example.test are distinct origins that have the same site (https://example.test), which is why the header validator warns you about ignored URL components and duplicates: Attribution is always performed by matching destination sites, not origins.

I'm happy to provide further explanation if you supply some example destinations that you would like to use with the API in practice. In particular, if you can elaborate on:

we see subdomains coming from different destinations/the same ones, and we want to ensure we can attribute them.

thanks @apasel422 - please see my colleague @taboola1dsg comment with more specfic use case.

I want to ask an even more specific question. According to current spec, let's take the following user journey:

1. Ad click
2. foo.example.test - clicking on button X on this page triggers a conversion A and also leads to
3. bar.example.test - clicking on button Y on this page triggers a conversion B

In this use case, what should we send in the destination array on ad click?

As stated in #1048 (comment), the origins https://foo.example.test and https://bar.example.test have the same site, so in this case you could supply {"destination": "https://example.test"} to cover triggers happening on both origins.

@omriariav @taboola1dsg It might help to provide a realistic set of sites or origins, rather than the example-only https://example.test, so we can consult the public suffix list for the real behavior.

@apasel422 understood. I will work with @taboola1dsg to provide them.

We still want to indicate that the three destinations may be insufficient and that declaring them "manually" for each campaign is an overhead. Which data/information do you need to evaluate possible modifications to the spec?

Two examples:
(1) many of our advertisers are using A/B test platforms to optimize their funnels - so the destinations can change during campaign flight
(2) we want to cover all use cases, and knowing which destinations are taking place is a significant effort. It's getting even worse when this is a new advertiser that we have any previous data on its funnel