attributionsrc in creatives

[dmdabbs]

This isn't an ARA issue per se, but speaks to testing/using it at full scale.

DSPs should be able to instrument embedding code to register event sources on their own. Not necessarily so for navigation sources. Some DSPs do have in-house creative offerings, and so complete control to ensure attributionsrc is set in a usable way for that delivery. For advertiser-provided creative, quite often Google 'dcm' assets, the creative needs support and an entry point for the DSP.

So I'm suggesting a DCM ARA support straw man. For example...

<ins class='dcmads'
   style='display:inline-block;width:300px;height:250px'
   data-dcm-placement='N7480.1664088DOUBLECLICK.NETTEST/B8299600.114131924'
   data-dcm-param-custom_key='custom_value'
   data-dcm-rendering-mode='iframe'
   data-dcm-https-only data-dcm-click-tracker='%%CLICK_URL%%'
   data-dcm-attributionsrc='%%ATTRIBUTIONSRC%%'
>
 <script src='https://www.googletagservices.com/dcm/dcmads.js'></script>
</ins>

If a DSP's %%CLICK_URL%% handler can set attribution headers when it 302s (probably to their exchange partner) then they can simply set an empty string. Otherwise %%ATTRIBUTIONSRC%% substitutes their attribution registration endpoint URL. The creative internals would handle the value properly,

// dynamically instrument the <a>
anchorElement.setAttribute('attributionsrc', attributionsrc );

or in the case of window.open taking care to escape the URL,

const attributionsrcEncoded = encodeURIComponent(attributionsrc);
window.open(
   clickTag,
   "_blank",
   `attributionsrc=${attributionsrcEncoded}`
);

[jfggit]

This is an interesting point because I think in some scenarios this would cause conflict between the DSP and the third-party tracker. In practice, the third-party click tracker probably just becomes a redirect in the clickthrough, probably along with the DSP's own click tracker. A few scenarios:

1. Both DSP and third-party want single-ping registration (i.e. the clickthrough navigation itself should be registered). This works nicely out of the box, because if the DSP makes the clickthrough registration eligible, the later redirects are also eligible.
2. The DSP wants double-ping registration and third-party wants single-ping. I think this has an issue, as if you're setting attributionsrc with some non-empty URL, then only that URL gets registration while the clickthrough navigation itself is not eligible, correct? So this is a non-compatible case; both parties can't measure in the way that they want. At best, the DSP could attempt to support this by sending a fetch/img ping for the third-party click tracker, but that would require removing it from the redirect chain entirely and may be undesirable (plus this affects how it is registered with the browser).
3. The DSP wants single-ping and the third-party wants double-ping. I think this is also incompatible for the same reason. Only one of the pings when using non-empty attributionsrc is actually registration eligible.
4. The DSP and third-party both want double-ping. I think this potentially works, but only if the DSP's attributionsrc URL can redirect to the third-party's attributionsrc URL (similar to click tracking), which may not be the case out of the box.

Just want to confirm my understanding here is correct, particularly that if a non-empty attributionsrc is used, the partner event is not eligible for registration.

[dmdabbs]

2. The DSP wants double-ping registration and third-party wants single-ping. I think this has an issue, as if you're setting attributionsrc with some non-empty URL, then only that URL gets registration while the clickthrough navigation itself is not eligible, correct?

AIUI, presence of an attributionsrc attribute (with or without url value) ensures that Chrome will a) send the Attribution-Eligible request header on both the request initiated by the instrumented element (<a>nchor or window.open) and of course the attributionsrc url and also b) both those request chains' redirects will be attribution-eligible.

[jfggit]

Ah, ok. In that case, it seems like this probably mostly works out, except that maybe there isn't necessarily a universal understanding that such URLs as in point 4 should be composable/redirectable.

[csharrison]

Closing out this issue since it isn't directly related to an issue in ARA. My preference would be to find a different forum for specific deployment-specific questions. @jfggit / @dmdabbs do you think that's reasonable?

[dmdabbs]

Yes @csharrison, that's reasonable. I filed here knowing it was only ARA-related in hopes to connnect with Google Ads folks. Can you sugest an alternate forum?

[csharrison]

I am not sure to be honest. Maybe @jfggit can comment on that? It's possible that https://github.com/GoogleChromeLabs/privacy-sandbox-dev-support/issues could work as a potential venue, but it also doesn't seem like an amazing fit.

Let me also loop in @maudnals who might have some thoughts.

[captify-mgruau]

Hi @csharrison, just wanted to reopen this issue as it's still happening, and we're at the stage where this is blocking adoption by regular Ad Tech actors. There is no point for us as a company to invest resources for implementation if such a common use case as 3rd party creatives served from DCM is not accounted for.

Besides, having a Google team not support 3rd party actors in the ecosystem for this feature will likely not be a great look for CMA eyeballs.

Is there something you as a team can do to secure commitment from DCM to support this?

[jfggit]

@captify-mgruau @dmdabbs
If you're passing a click tracker through data-dcm-click-tracker then that tracking URL should already very often be eligible for registration as it's on the same navigation chain as the DCM clickthrough, which is itself often set up for registration (a small number of rarer creative types are not yet supported). Is it possible to do ARA registration with through the existing click tracker?

[captify-mgruau]

Hi @jfggit, the registration process requires us to not just update the URL but also add attributionsrc within the tag.

Example from the demo site:

The click tracker URL macro would allow us to update /register-source-href in this screenshot but not to add attributionsrc.

Are you saying that DCM will automatically add attributionsrc and that there is no need for the buyer to add this themselves in this scenario?

[jfggit]

So for a DCM tag like the one linked in the original comment, there is a mechanism for passing in a third-party click tracking URL that will be injected into the clickthrough chain. Generally these are written so there is a hanging parameter or the like that allows for the next link in the chain, with the last being the actual landing page for the ad. For example, maybe we have:

DCM click tracker: https://doubleclick.net/click?id=123&url=
Third-party click tracker: https://3p.net/click?id=456&u=
Landing page: https://landingpage.com

The actual URL used for the clickthrough on the ad would be the concatenation of these three URLs in the given order (along with URI escaping as needed), with each party redirecting to the next for counting and ultimately navigation purposes.

Because DCM is also registering clicks through ARA, the click element might be rendered as:

<a href="[concatenated URL]" attributionsrc>[AD CREATIVE]</a>

This allows the DCM click tracker to register with ARA, but also the third-party click tracker (and technically the landing page) because registration eligibility passes across redirects.

So if you're serving a DCM tag and injecting a click tracker with the data-dcm-click-tracker mechanism, you should very often already be getting the Attribution-Reporting-Eligible: navigation-source header on your requests.

[captify-mgruau]

Thanks @jfggit , this makes sense for us; we'll try applying it in practice but on paper this should work.