This is useful as it would help with payment disputes. To that end maybe there should be a match id so reports received by both parties can be compared. The id could just be used to match the reports, there would be no way to track the user.

It's a bit unclear how this would help in a dispute. The advertiser and publisher have completely opposite incentives in the topic, historically this has been resolved by the SSP in the middle which either puts up the cash difference or is seen as reliable accountant of with incentives aligned with each side. Currently in adtech for example, despite all javascript being around at the same time you often seen 5% discrepancies between parties. Requests fail all the time and so on. There's no guarantee that the reports will be delivered transactionally to both parties anyway.

It also doesn't seem more transparent than sending a request to a third party. The data being sent is already in aggregate and contains very little identifiable information so it's not clear what threat is being avoided.

Mobile IDFAs already share data server side and clearly lead to surprises about who has access to that as many WaPo or NYT articles have uncovered. Sharing data client side, and having that be part of an explicit spec offers more opportunity for control on the user as well. It seems the justification of being able to choke one neck (pub or advertiser) because they've shared my data without my consent is a different compromise than the specs so far have been trying to achieve, which is to spare all necks since they won't be able to share much of useful at all or to leave control to the user and move it out of backside deals.

The user is maybe somewhat aware of the first 2 parties, they went to a site and clicked an ad, then initiated a conversion. But not the intermediary, unless that it is somehow drawn to their attention (which would probably get in the way).

I was suggesting some way to link the reports to help the commercial aspects, but without sending information to a third-party, who would at least get to know the user's source IP address.

The 2 parties could forward their reports onward to a third-party but without the user's IP. If reports could be matched, this gives a potential tie-breaking role to a third-party without the browser having to conspire in sending personal data.

The linkability could be via a digest signed with a third-party managed public key, with a different digest sent to each party.
This would make sure only the third-party could match.

The premise that somehow the ad can be placed on a page by the advertiser having a relationship with the publisher I think is somewhat flawed...

There's millions of publishers on the web, is the expectation here that each advertiser needs to somehow grow direct relationships with all of those publishers? Or is the expectation that any publisher will need to build enough infrastructure to manage demand for tens of millions of businesses that advertise today on web?

The advertising market evolved the way it did because it's more efficient to have intermediaries manage relationships between millions of publishers and tens/hundreds of millions of businesses globally. Also the technology being discussed in all of these specifications is the opposite of easy to use or implement, so again is the expectation here that any publisher and advertiser will be able to implement these pieces of technology and have them be as reliable? The third parties managing advertising was around long before cookies were used to personalize ads for example (remember ad networks?), so this should be at minimum a sign that they do something useful aside from just aggregating data.

It is a fairly easy bet to assume that without third parties managing the placement of ads you will see a significant shrinkage of the advertiser and publisher numbers, or full centralization of market power in the hands of only the companies that can afford building this technology to sustain themselves and that offer services where they advertise on.

The spec in question has already greatly reduced the information that can be obtained from conversion measurement to basically 1 byte, I totally get being afraid of the industry later trying to find exploits that will enable tracking again and I'm very comfortable with the idea of doing our best to avoid it, but we should aim at creating something practical that could possibly work for the impacted parties, otherwise this really creates incentives to look for workarounds even harder since the market need remains (like the war on drugs, nobody wants drugs rampant in a country, but regulating them is more effective at reducing their usage than trying to ban them, as multiple countries and states have proven now).

If you don't want the third party to receive the IP address then pass the request through a proxy of choice that will mask it, there are already plenty of requests sent to a central location to validate SSL certificates or, as we just learned, allow applications to be launched on a computer, if that single point of centralization of traffic is alright then why not just use a proxy and transmit the data to third parties as well which would allow this whole process to be simple and vastly more transparent to the end user.

This is not an argument against the existence of intermediaries, my point is that we should not design a system where personal data has to be sent to them.

If advertiser and publisher require an intermediary there is nothing to stop them forwarding reports to them, taking their own policy/ legal environment on privacy into account - so without the IP addresses etc.

The linking info could be sent as long as it could not contain personal data. A one time value sent by the browser in the 2 reports, encypted so only the third-party could read it would not be linkable to a person, just between the 2 reports.

If we have to rely on an IP proxy that opens another can of worms - like who manages and pays for it, how can everyone trust it etc.

Well, I'm not exactly sure how an intermediary can operate without having their own source of this reporting making it consistent across parties that they work with. And I'm also not exactly sure dealing on server side deals is more transparent, or better, in any way compared to having this data transmission happen in-browser.

You can hide the content of what passes through the proxy by encrypting it with the third party public key and sending it through the proxy, thus removing the confidentiality problem.

The problem with the IP proxy is finding a party to manage it who can be trusted by all stakeholders, including the user.

If the intermediary needs something to match the reports, then it would be better to use a dedicated report id which can be designed to be unlinkable to the user

Hey John,

Representing many advertisers on Shopify, I think this feature would be great. I wonder if/how DSPs may choose to blend PCM reporting with other available metrics. Advertisers would benefit from having access to this measurement data directly. Although, we would admiteably be dependent on campaign id mappings from the DSPs. Historically advertisers could replicate this reporting through measurement on click-through UTM decoration, but we are now see growing adoption solely of click ids, which can obfuscate campaign data from advertisers.

Relatedly, I wonder if PCM would ever be a viable solution to multi-channel measurement? Specifically meaning, giving attribution to one or more touchpoints in buyer journeys with advertisements spanning multiple platforms. This would perhaps be especially beneficial if source_engagement_type ever expanded to view. A recurring challenge for advertisers operating on multiple platforms is siloed reporting. If I sell 100 widgets, DSPa may take credit for 80 and DSPb may take credit for the other 85. These results could be based on both post-click and post-view measurement. Sophisticated advertisers may attempt to build their own attribution models leveraging event-level impression logs from ad tech platforms and complex identity graphs. This can help isolate the efficacy of a given platform, at a given time, when a buyer journey spans multiple ad platforms.

If PCM ever evolved it’s measurement capabilities to broker unbiased causal (aggregated) post-view model(s) with campaigns spanning multiple platforms; it would likely be every advertiser’s default attribution system.

As a developer at Amazon, this functionality would allow us to avoid having to get this information from the publisher. Eventually we will get this information, it's just a matter of getting it from the publisher vs direct to our report servers. So not implementing this functionality does NOT affect privacy just convenience for the Advertiser (in this case Amazon).

@johnwilander are there any updates on the advertiser receiving the attribution reports? Publishers like FB are already leveraging (see their QA here). Especially valuable will be the App to Web that aligns with consumer digital behavior. And it would align with the direction SKAN. It's important for the destination site (advertiser site) to collect the source site (publisher/app) source ID in the reporting to align the cost data that comes back from the publisher.

Let's remember it's the advertiser who is paying for the "free content" on the web. Not the publishers. Let's have transparent, aggregated information for all parties involved.

Both sides get the attribution report — the click source and the click destination.

Apologizes...I'm trying to locate the details for the destination to start to build out the collection. The destination (or advertiser) uses a third-party to help build out the analytics similar to how when setting up SKAN a third-party (MMP) can manage the process. Is that possible for the web? It seems there has been discussions/thread on the topic.

No third party reporting. The click source and the click destination get the report.

SKAdNetwork is not a (proposed) web standard, hence not discussed here.

The privacy risks of third-party reporting on the web has been discussed at length here on GitHub. The web has no way of statically designating a single third-party reporting endpoint. Therefore websites could use different endpoints for different users to put users in buckets and boost the amount of data getting through. Effectively, the reporting domain can be used to transfer data.

So we would have to get the destination to forward the reports to third-party that is trusted by the destination. Ok. Thanks.