Multiple domains for conversion funnel

[eysegal]

I went over some issues like this and this but I still don't understand if the following scenario is supported:

When working with performance advertisers the conversion funnel is sometimes composed of different stages -
(a) The user reached the landing page
(b) The user is interested in a product
(c) The user purchased the product.
Stage (a) and stage (b) might occur in different domains, and require conversion count separately to show the conversion funnel.
Is it possible to do this in Attribution Reporting?

[csharrison]

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.

[omriariav]

@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

[apasel422]

@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.

[omriariav]

@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.

[taboola1dsg]

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?

[apasel422]

@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.

[omriariav]

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

[apasel422]

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.

[apasel422]

@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.

[omriariav]

@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?

[omriariav]

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

[omriariav]

@apasel422 I want to follow up here and provide more information

The focus here is on the requirement to declare the destinations with a click, as we verified that the three destination constraints are workable.

• We identified advertiser types using more than one destination in their funnels (more than one eTLD+1). Native advertising is a key factor for these advertisers types to succeed.
• The New user journey adds overhead:
  • Advertiser installs a pixel on all the pages in the funnel regardless of their eTLD+1 domains - enabler to log the different destinations
  • The advertiser creates a new campaign with a landing page - the landing page hostname (eTLD+1) will be the first destination that we will use
  • The options now are either to ask the advertiser to declare all of the destinations when they set up the campaign (more friction/error prone), or show the destinations we logged and choose the relevant ones during the campaign flight, or suggest them when a new campaing is set up (More infra costs and resources to support it)

Native proves well for those types of advertisers, which may be a different case for display. Display may have a fixed domain, given the smaller funnel (top-of-funnel advertisers compared to performance, which have longer funnels). This can cause an unfair advantage towards display advertising.

I understand the privacy requirements here and that we must tell the browser for each source where to look for the conversions. However, it's essential to understand the overhead in requesting to declare the destinations upon a click and the impact on the campaign setup.

We will be happy to brainstorm possible solutions.

[jolynyao]

Thanks @omriariav, great to hear that 3 destinations works for you. Could you provide more details on what you mean when you say this is a use case for native advertising? What is unique about native that means the destinations are dynamic?

If I'm understanding the conversation (and this comment), you're saying that generally users don't convert on more than 3 destinations; however, it's difficult to tell in advance what those destinations are? Is that because the conversion action you're targeting is actually a click on another ad?

[taboola1dsg]

Hi @jolynyao, that is not the case. We have a significant amount of advertisers with campaign strategies that take you through several destinations before reaching the final primary conversion. Here are 3 examples:

1. Online stores
   • ad click takes the user to an advertorial LP on destination 1
   • button click on advertorial LP takes the user to the store on destination 2
2. Gaming apps
   • ad click takes the user to an advertorial LP on destination 1
   • button click on advertorial LP takes the user to the game site on destination 2
3. Affiliates
   • ad click takes the user to an advertorial LP on destination 1
   • button click on advertorial LP takes the user to another advertorial or a demo video on destination 2
   • button click on demo page takes the user to the purchase or lead page on destination 3

The common for all the above is that they provide only the 1st destination on our platform and we don't expect them to provide a list of destinations per campaign because it adds a lot of unnecessary friction and requires a big dev effort.
I hope this makes more sense now. Thanks

[jolynyao]

Thanks for the explanation @taboola1dsg!
Couple more questions:

• Is the end goal is to be able to attribute the final primary conversion to the first ad click in each of your examples (the ad click that takes user to the advertorial LP)?
• Your examples focus on clicks but wondering how critical view-through conversions are for this use case?

[taboola1dsg]

Hi @jolynyao please see comments:

1. Exactly
2. Click through attribution is definitely number 1 priority for us, but we have a significant portion of clients that rely on view-through attribution as well. For this group of clients we need to have a solution as well.

Please lmk if you have any other questions

Thanks,
Adi

[apasel422]

Is this issue still relevant?

[omriariav]

Yes, it does. Thank you for checking.