Thanks for the report.

Could you provide an example of the syntax you're using to perform the source registration? It would be helpful to know which of the various API surfaces you're encountering this with, e.g. <a> / <img> / <script> with or without the attributionsrc attribute or via fetch or window.open from JS.

Hi @apasel422 , i'm working with @alois-bissuel and i'm able to provide some info about this.

Source registration for clicks happen via window.open using the window features (3rd parameter). Here's a real example with the actual attributionsrc used:

window.open("https://actual-click-destination.com", "_blank", "attributionsrc=https://measurement-api.criteo.com/register-source?impressionId%3D62e3a6b745430c1aec0611ef31f61b00%26partner_domain%3Dlaredoute.fr%26external_uid%3D0d134b41-edcf-49b1-86d3-e7c7317e2573%26partner_id%3D782%26source_type%3Dnavigation");

NB: This is called during a click handler function that is dynamically attached (using js) to the link element after DOM is loaded.

For displays registrations, we simply have a <img> tag with the attributionsrc attribute, pointing on a similar endpoint.

Thanks for helping, let me know if you need anything else.

window.open("https://actual-click-destination.com", "_blank", "attributionsrc=https://measurement-api.criteo.com/register-source?impressionId%3D62e3a6b745430c1aec0611ef31f61b00%26partner_domain%3Dlaredoute.fr%26external_uid%3D0d134b41-edcf-49b1-86d3-e7c7317e2573%26partner_id%3D782%26source_type%3Dnavigation");

I'm getting an HTTP 400 error when I manually navigate to the attributionsrc URL here. Is that expected?

Thanks for helping, let me know if you need anything else.

Is there any possibility of providing the URL of a real page on which you're experiencing the discrepancy in endpoint calls?

Hello @apasel422 and thank you for checking this.

The HTTP 400 is "normal", the url is generated for EMEA and won't work from the US or elsewhere. It's working fine for us in Paris.

Getting (and sharing) a real publisher page containing a Criteo URL is a bit tricky, "thanks" to the nature of personalized advertising and the multiple layers of intermediate adtechs. @alois-bissuel explained the steps here #38 (comment)

I'll try to describe a "canonical" example as best i can.

Hello @apasel422,
We finally managed to reproduce a case where our attribution API is not called, seems that it's more a problem with chrome beta 104, 105, these are the steps to follow:

1. Download chrome beta and be among beta users of privacy-sanbox, you have to see and accept the window inviting you to test privacy-sandbox features, please don't activate chrome://flags/#enable-experimental-web-platform-features and chrome://flags/#privacy-sandbox-ads-apis flags manually otherwise you will not see the bug.
2. Open this ad for instance the browser will not call the source endpoint to register a view (https://measurement-api.criteo.com/register-source in this case) the call will be performed if you activate those flags manually, trigger endpoints are still triggered even without activating the mentioned flags.

Hope this helps, please don't hesitate to reach out for any further details
Again thanks for the support

Thanks for the details.

CC @johnivdel who knows more about the flag configuration.

Thanks for the support,
I forgot to mention that I'm using Chrome beta 104.0.5112.79 64-bit (image bellow)

Instead of using the ad that I provided you with you can also use this url it should trigger a event source registration directly after page load.

Thanks for providing the link, able to reproduce this case locally in M104+, will share more information when available, thanks!

After looking into this on my end, it seems like the browser is trying to parse the attributionsrc= attribute before the origin trial token is added to the page. Could you clarify that the script which adds the token is executed prior the script (or html) which creates the ad?

Hello @johnivdel,
Thanks for the support !
@fabienbk who is in charge of front-end integration is on vacation right now we are trying our best to answer you as soon as we can.

The bug scenario we provided you with tests the integration on the ad web page and shows that we are only loosing displays, reality is that we are loosing both displays and clicks for those specific chrome versions, we found that when being re-targeted by Criteo ads on some publishers (Ad is inside an IFrame) we do not see neither displays nor clicks, could you please help us investigating this ? here are the replication steps:

1. Delete all browsing data from your chrome beta browser to avoid being re-targeted by another company
2. Visit this advertiser website and generate some events (view product list, view product and then add to cart)
3. Go to this publisher website and of course accept cookies 🍪, you will be able to see now the advertiser Ad, just to be sure that this add is served by Criteo click on Ad Choises you will normally see this
   

you will notice that our API is not called for neither clicks nor displays where as it is called for clicks when the ad is loaded as the main web page as here
Again thanks a lot !

Hi @johnivdel

Indeed we register the event source before the token is actually parsed. Thanks for the hint which enabled us to find this bug. We will fix it soon.

Still we do not see many navigation sources. One of our current hint is that there is an issue with the permissions policy system.
Here is a small demo website illustrating the issue. It contains two identical Criteo ads with and without permissions.
Using a beta Chrome version with no flags activated and the privacy sandbox enabled in the settings (chrome://settings/privacySandbox), we see that there is no permissions policy called attribution-reporting in the Application tab of the developer panel. The attribution-reporting API does not work.
I need to enable the Experimental web platform features in the flags panel (chrome://flags/#enable-experimental-web-platform-features) to get the permissions policy system working (if you click then on the ad where the permission policy is correctly set up, the attribution reporting API will work as intended, provided you accept the cookie on the advertiser website).

Can you reproduce the issue on your side?

We do not see this issue on the trigger side.

EDIT: I looked at the official documentation again and saw that the correct flag for debugging should be chrome://flags/#privacy-sandbox-ads-apis instead.
After some reinstall of my beta Chrome version to land on one where I am in the test population, I still have the issue of permissions policy. It looks like attribution-reporting is not allowed on the main page, which somehow contradicts the official documentation:

The API will be enabled by default in the top-level context and in same-origin children.

The issue on the demo site is that the origin trial is not enabled in the top-level context.

The Permission Policy, similar the the Attribution Reporting API itself, is also gated on the origin trial.

The "attribution-reporting" permissions policies cannot be delegated to the ad iframe unless there is a valid OT token within the document embedding the iframe.

The documentation you linked does not cover this explicitly, and could probably use updating.

Thanks for the answer.
I added a token in my example page, and indeed the attribution-reporting permission is available from the top page, and everything works as intended
One further question: does the token on the main page need to be from the same origin as the one serving the iFrame? I have seen some webpages where other parties include a valid token on the main page, but we cannot use the API.
A final question: has this system of gating the permissions policy system on the main page by a token always been in place, or was it introduced in v104?

With regard to the first question:

does the token on the main page need to be from the same origin as the one serving the iFrame?

For code to access a trial feature, the browser needs to have (already) seen a token registered for the same origin as the code.

So — if you're accessing a feature from an iframe inline in a script element, the browser needs to see a token registered for that origin. If you're including code from an external file (either from the same or a different origin as the iframe) the browser needs a token registered for that origin.

If you use a third-party token, make sure that it's provided via an external script, not a meta tag or inline script: see developer.chrome.com/docs/web-platform/origin-trial-troubleshooting/#token-third-script

Hope that makes sense. Let me know if it doesn't answer your question!

Three demos:
• Token provided in an iframe: ot-iframe.glitch.me
• Token registered for the origin of the containing page, does not allow feature access in an iframe: ot-meta-iframe.glitch.me
• Page including three iframes that each attempt to access a Chrome origin trial feature. Each iframe provides a trial token in a different way: ot-iframe-3p.glitch.me

Thanks @samdutton for the anwser. It makes sense, but I am not sure to fully grasp the intricacies of the interaction between tokens and permissions policy.
Let me frame an example:
publisher.com sells ad space to two adtechs, adtech1.com and adtech2.com.
Adtech1 is very well integrated with publisher.com, so that publisher.com calls a script of adtech1.com which declares the OT token in the top-level context. Adtech2 cannot do this.
Both adtechs have ads inside iFrames with the necessary permission policy (ie allow="attribution-reporting") and declare their third-party token inside their iFrame.

Would adtech2 be able to use the attribution-reporting API in that case?

In the absence of adtech1, I understand that the permission policy attribution-reporting would not be enabled in the top-level context, hence the inability of adtech2 to use the API.

As an addendum to my question, let's consider the same example, but this time publisher.com uses an SSP (ie an intermediary selling the publisher's advertising space programmatically). This means that adtech's iFrames are embedded within an SSP's iFrame.
If I understand things correctly, if the SSP does not bother registering for an OT token and adding it to its iFrame (even though it correctly sets the permission policy system), the adtech within the SSP's iFrame won't be able to use the API during the OT. Am I correct?

Closing, as I believe it is covered in #52.