Multiple reporting domains in ad impression

[itsikb]

In case the advertiser works with multiple measurement platforms, will it be possible to define multiple reporting domains in the ad impression?
In any case, who will have the control on the reporting domain? Will it be the advertiser setting the reporting domain when defining the impression within the publisher, or is it solely the publisher?

[csharrison]

Thanks for the comment, this is a gap in the existing API and it is due to some difficult to solve privacy issues.

In the existing API, the publisher site and the advertiser site have to more or less "agree" on a reporting domain for the report to be sent. Thus, the choice of reporting domain does not reveal much that isn't already implicitly bound to the impression data.

The simplest way to extend this would be for both the publisher and advertiser to agree on a set of reporting domains, and to drop the report if the sets differ at all. This would satisfy the same privacy guarantees as the existing design, but I'm concerned that it would be somewhat fragile to deploy (and has some non-trivial implications with API surface).

Another "solution" here is to have the configured reporting domain do server-to-server calls to forward events to partners, though obviously this isn't an ideal solution either because often reporting domains do not mutually trust one another.

[itsikb]

Thanks for your answer.
IMO, having only one reporting domain will be very limiting to the advertiser.
Also, to make sure I got this right - the advertiser will be the one setting the reporting domain used in the impression, and the publisher will have to "agree". Is this correct?

[csharrison]

Also, to make sure I got this right - the advertiser will be the one setting the reporting domain used in the impression, and the publisher will have to "agree". Is this correct?

Sorry my explanation was not precise. Basically the "impression registration" steps and the "conversion registration" steps have to agree on reporting domain. Those can be done by publisher, advertiser respectively, or their ad-tech on their behalf.

[itsikb]

Understood. Based on this - question is: since the publisher is defining the impression, can he impose a specific reporting domain on the advertiser (via the impression definition) or, which IMO is most likely, there will be several reporting domains agreed on the publisher (similar to a certificate authority in some sense), and the advertiser will choose for each impression which reporting domain to use, when the advertiser defines the ad in the publisher platform?

[csharrison]

Yeah, ads served on the publisher site can all set different reporting domains. The only constraint here is we need some limit on the number of conversion tags on the advertiser site, which is described in this section:
https://github.com/csharrison/conversion-measurement-api#limits-on-the-number-of-conversion-pixels

For any given conversion report, it can only flow (in the existing design) to a single reporting endpoint though.

[itsikb]

Thanks @csharrison !
Looking forward to see where this ends up.

[csharrison]

I appreciate the kind words :)
Let's keep this issue open because imo this is still a weak point in the API, and there could be clever solutions here we haven't thought of.

[abebis]

The simplest way to extend this would be for both the publisher and advertiser to agree on a set of reporting domains, and to drop the report if the sets differ at all.

It sounds similar to the current setup where advertisers set a tracking URL for clicks and a tag on the conversion page using the same 3rd-party measurement domain, in addition to the DSP's internal click tracking and conversion tag. 1 redirect and 1 tag needed for each measurement domain.
For example with Google Ads the advertiser can set a tracking template to redirect clicks through a 3rd-party measurement domain and set tags for both Google Ads and the 3rd-party measurement tool on the conversion page.

but I'm concerned that it would be somewhat fragile to deploy

The main issue I can think of is how to share the "impressiondata" between two reporting domains. My understanding is that impressiondata will typically be generated dynamically at impression time by the DSP (Google Ads in the example above).
A possible solution could be to share it with the other reporting domain at click time through redirects using click tracking URLs.

Impression data would look like this:

href=”https://measurement.test/redirect?impressiondata=0x12345678&campaignid=abcdef&lp=https://toasters.com/purchase”
conversiondestination=”https://toasters.com”
impressiondata=”0x12345678”
reportingorigin=”https://dsp.test,https://measurement.test”

campaignid would be the id associated with the clicked ad, in the 3rd-party measurement system. At click time the measurement tool will learn that impression data "0x12345678" corresponds to campaign "abcdef", so that later when it receives a report from the browser for impression "0x12345678" it knows which campaign/ad it should attribute the conversion to.

Another "solution" here is to have the configured reporting domain do server-to-server calls to forward events to partners, though obviously this isn't an ideal solution either because often reporting domains do not mutually trust one another.

Yes sending reports directly would defeat the purpose of independent 3rd-party measurement/attribution.

Instead of sending reports, at conversion time the first reporting domain could redirect to the next one:

conversion page -> dsp.test-> dsp.test/.well-known/register-conversion -> measurement.test -> measurement.test/.well-known/register-conversion

instead of 2 independent tags (more "fragile"?):

conversion page -> dsp.test-> dsp.test/.well-known/register-conversion
conversion page -> measurement.test -> measurement.test/.well-known/register-conversion

Hopefully harder to make the browser record fake clicks and conversions than just sending fake reports from server to server.

[csharrison]

Thanks for the ideas Antoine!

I agree having some scheme to share the impressiondata is useful. From my POV that is probably best achieved using something like sendBeacon rather than redirects on the navigation. The latter runs into problems where it may be possible to transmit these identifiers across sites via the URL and associate it with first party cookies - we want to be able to recover these use cases without needing these techniques.

In terms of multiple conversion registrations, I like the redirect idea as a way of the first endpoint signaling its metadata to the next endpoint. The one drawback is that it requires more cooperation. Now all the ad-tech companies that want to receive reports have to know the full chain and redirect to the correct origins. This cooperation is definitely incentivized in this scheme (if anyone messes up the report is dropped), but there might be better solutions that only require one party to know the correct set of endpoints to declare.

[abebis]

From my POV that is probably best achieved using something like sendBeacon rather than redirects on the navigation. The latter runs into problems where it may be possible to transmit these identifiers across sites via the URL and associate it with first party cookies

I see. Actually Google Ads is already using sendBeacon ("parallel tracking") for internal and third-party measurement instead or redirects, in browsers that support it. Another good thing about beacons compared to redirects is that cookies are treated as third-party (and thus will be blocked in the future).

Now all the ad-tech companies that want to receive reports have to know the full chain and redirect to the correct origins. This cooperation is definitely incentivized in this scheme (if anyone messes up the report is dropped), but there might be better solutions that only require one party to know the correct set of endpoints to declare.

Some advertisers are already used to set up redirect chains to track clicks with multiple tools. And to set multiple tags for each measurement domain on the conversion page.

Overall I think it should be quite easy to adapt current third-party measurement setups to take advantage of multiple reporting domains. Is there a blocking issue implementation-wise or privacy-wise preventing the API from supporting multiple reporting domains?

[csharrison]

Thanks for the feedback!

Overall I think it should be quite easy to adapt current third-party measurement setups to take advantage of multiple reporting domains. Is there a blocking issue implementation-wise or privacy-wise preventing the API from supporting multiple reporting domains?

There are privacy issues with naively supporting multiple reporting domains, as is detailed in this issue, but the problem seems tractable and there are definitely solutions here that could work.

I don't see any problems implementation wise with these ideas.

[abebis]

Going back to

but there might be better solutions that only require one party to know the correct set of endpoints to declare.

I guess the simplest solution would be to have a single tag on the conversion page sending requests (beacons) to all the reporting domains. This single tag would typically be provided by the DSP, where the advertiser registered the ad and the reporting domains. One drawback compared to the redirect scheme is that the tag needs to first fetch the list of reporting domains from the DSP (requires to use a script instead of a simple pixel tag).
For both solutions obviously a limit should be put on the number of CV registrations (ignore .well-known/register-conversion requests after a certain threshold), similar to what is described in the "Limits on the number of conversion pixels" section of the explainer.