PCM can only be leveraged for advertising by a few dominant publishers

[Pl-Mrcy]

Hi @johnwilander,

The current PCM specifications make it only useable when the "click source" and the "attribute-on" have a direct relationship. This is only workable - in an advertising context - for ad campaigns running on a very limited number of publisher domains. It is not in the fairly common case where a third party acts on behalf of the advertiser and publishes ads on a wide network of publishers all over the "open web".

In the current state of affairs, all actors are equally constrained when running and measuring the performance of ad campaigns on Safari. This API, serving the needs of a very specific set of actors (big publishers who can maintain their own ad stack) will give them a clear edge over the rest of the industry. Not only will they be able to showcase their performance while others won't be but their numbers will sometimes be unfairly inflated.
Let's consider the following scenario: Advertiser A runs ads through "big publisher" B and a myriad of smaller publishers C, D, E, etc. via an ad tech third-party provider T.

• User clicks first on an A ad on B and gets redirected to A website.
• Then, User clicks on another A ad, printed by T on smallblog.example and gets redirected to A website.
• Later on, User "converts" on A website.
• PCM attributes the conversion to the big publisher B entirely, oblivious of T and smallblog.example contribution (smallblog.example being completely unknown to A).

T being unable to leverage this API, the conversion credits that should be sometimes split between B and T (and the myriad of small publishers it prints ads on) would entirely be assigned to B and overestimate its impact.

This API ends up giving, on Safari, a decisive competitive advantage to already dominant players, owning several links in the value chain, at the expense of smaller actors.

What are your thoughts on this? Is that something that you aspire to fix? Until we found a solution to this issue, we propose to delay the roll-out of this API. A possible solution would be to support calls to third-parties for triggering ad click attributions, as described in Chromes' Conversion Measurement API.

[johnwilander]

Hi! Thanks for filing.

Using third-parties for various things in PCM has been discussed thoroughly since the very beginning. A round up of the latest can be found here: #57. Note that Conversion Measurement API has very different goals for tracking prevention and privacy compared to PCM. That’s mainly why there are two proposals. It should also be noted that WebKit’s position is that sending attribution data to third parties the user has likely never heard of goes against user expectations. They merely know they clicked an ad on site A that took them to site B.

The specific thing you bring up was discussed on the latest Privacy CG biweekly call and I said the intention has been to solve this with the forthcoming JavaScript API which would allow wildcard triggering of attribution. During the call, at least three people brought up that some advertisers/merchants/click destinations are very reluctant to deploy JavaScript for attribution purposes. So I suggested that we match the functionality of the JavaScript API (or parts of it) with a same-site “pixel” way of triggering attribution. That would allow wildcards too.

[Pl-Mrcy]

This wildcard triggering of attribution would work!
When do you think it will be added to PCM? Will it be before the general availability of the API?

[johnwilander]

This wildcard triggering of attribution would work!
When do you think it will be added to PCM? Will it be before the general availability of the API?

Browsers independently decide what they want to ship and when. That's not really a standards issue and this repository is about the proposed standard.

As for adding the wildcard functionality to the spec, we are currently focused on the fraud prevention tokens. Then we'll get to modern ways of triggering attribution and also to sending attribution reports to advertisers.

[johnwilander]

The specific thing you bring up was discussed on the latest Privacy CG biweekly call and I said the intention has been to solve this with the forthcoming JavaScript API which would allow wildcard triggering of attribution. During the call, at least three people brought up that some advertisers/merchants/click destinations are very reluctant to deploy JavaScript for attribution purposes. So I suggested that we match the functionality of the JavaScript API (or parts of it) with a same-site “pixel” way of triggering attribution. That would allow wildcards too.

The above was filed as #71.

[johnwilander]

The work I see related to this is tracked in other issues. Closing.

[tprieur]

Hi @johnwilander ,
I'd like to reopen this issue. Forcing advertisers to have a direct relationship with each publisher means that advertising budgets will mostly fuel large publishers and leave smaller players with very limited advertising revenue.

In an effort to make the Internet as fair as possible, and in my opinion, being able to wildcard the click source should be part of the proposed standard. What is your opinion on that ?

(I think this concern has been discussed in other threads too, but this one is a bit more specific. Please let me know if I need to open another thread or post somewhere else.)

[johnwilander]

Hi @johnwilander , I'd like to reopen this issue. Forcing advertisers to have a direct relationship with each publisher means that advertising budgets will mostly fuel large publishers and leave smaller players with very limited advertising revenue.

In an effort to make the Internet as fair as possible, and in my opinion, being able to wildcard the click source should be part of the proposed standard. What is your opinion on that ?

(I think this concern has been discussed in other threads too, but this one is a bit more specific. Please let me know if I need to open another thread or post somewhere else.)

Hi! Wildcard triggering creates significant complexities when it comes to unlinkable tokens on the destination site.

See my analysis of this in #88 where I for instance say:

A wildcard triggering event must always request a fixed number of signed tokens, for instance one. Otherwise the browser will leak to the destination site from how many source sites it has matching clicks.

[tprieur]

I understand wildcarding raises other concerns, but we can not build an unfair standard just because of complexity. I agree with what is proposed in issue #88, we can limit the number of matching clicks returned by the brower.
Unless I'm mistaken the issue #88 is about the modern API, we should make sure both the API and the legacy pixel work for all publishers.