impressionOrigin getting access to conversion report

[pranay-prabhat]

Shouldn't the site owners also get delayed, salted reports on how ads on their site led to conversions on other sites.

impressionOrigin should also get a conversion report just like reportingOrigin.

[johnivdel]

Generally, the party responsible for serving the ads to the page is the one that gets reports. And similarly they are responsible for setting the impression and conversion data fields.

If the impression origin (publisher page), is serving ads themselves, they can set themselves as the reportingOrigin and handle reports.

If the publisher page is using a different 3P to serve ads, that 3P is in control of the impression data and reporting origin fields. My understanding is that normally the 3P then takes on the roll of informing both the publisher and advertiser on ads performance.

If we sent a duplicate report to the publisher, how would they use it? Because the reporting origin (3P) sets the impression data and conversion data, the publisher itself has no way to understand what the reports mean. At most, they could recover the rate at which ads on their site receive reports. This doesn't seem that valuable to me, as in reality the publisher wants more detailed information about performance that only the 3P can provide.

Let me know if you disagree with any of these assumptions.

[pranay-prabhat]

Thanks. So lets break this into 2 parts. Say a publisher and advertiser do a direct deal and the adops team on publisher's side set a campaign for this in Google Ad Manager. The campaign runs on publisher site and publisher wants to know more if ads show on their site led to conversion or brand lift elsewhere. How can this be done? Is GAM supposed to receive this conversion report from Chrome and they can decide if they want to send this to the publisher or not.

Now on programmatic ads, if a DSP sets the impression data and conversion data into its ad response, then maybe we can update the programmatic script on publisher page to append some metadata generated by the publisher and then publisher can get this report too? Or does the current solution expects publishers to reach out to 100s of DSPs to get this data from them?

Thanks,
Pranay.

[abebis]

If we sent a duplicate report to the publisher, how would they use it? Because the reporting origin (3P) sets the impression data and conversion data, the publisher itself has no way to understand what the reports mean.

We were trying to solve that issue in #29. It seemed like an important feature for @csharrison too:

I agree having some scheme to share the impressiondata is useful. From my POV that is probably best achieved using something like sendBeacon (...)

But maybe the main objective of this API is not reporting but optimization and sharing reports is not so important? (compared to PCM which is reporting-only, with its easy-to-share static campaign id instead of an id generated at impression time). Maybe we need PCM in Chrome too.

[pranay-prabhat]

@johnivdel any thoughts to my response above?

[johnivdel]

Say a publisher and advertiser do a direct deal and the adops team on publisher's side set a campaign for this in Google Ad Manager. The campaign runs on publisher site and publisher wants to know more if ads show on their site led to conversion or brand lift elsewhere. How can this be done?

In this scenario, how are the conversions measured today? Does the adtech (GAM) generate the conversions data and display it to the publisher? Does the advertiser configure pixels directly for the publisher, or do they configure with the adtech that is being used(GAM in this case)?

My understanding is that this adtech would receive the conversions data, and then display it to the publisher, which is what already happens.

Now on programmatic ads, if a DSP sets the impression data and conversion data into its ad response, then maybe we can update the programmatic script on publisher page to append some metadata generated by the publisher and then publisher can get this report too? Or does the current solution expects publishers to reach out to 100s of DSPs to get this data from them?

Who does the publisher reach out to today to get this data? Is it correct that the publisher already needs to reach out to someone because they do not have any conversion pixels on the advertiser site?

With this API, we would expect that the existing parties the publisher needs to reach out to would be the ones who serve as the reporting origin, and measure the conversions on their behalf.

[pranay-prabhat]

Sorry @johnivdel for responding late as i wasn't notified about your response. I had discussion with business counterparts in my org and it seems this is a classic case of publisher representation missing in the solutions used previously and solutions being planned for the future as well.

Ad Networks have been owning this data previously because it was all based on third party cookies. Pubs dont create third party cookies across internet but Ad Networks do and hence the reason why they owned and operated on conversion data.

But bottom line is that Pubs dont get comprehensive conversion report for how the ads on their site performed and pubs cannot talk to 100 ad networks or third party agencies which place ads on our sites for conversion data. It could be that ad server placing ads on publisher sites should provide conversion data from chrome to publishers but that doesn't happens today AND this only works for direct sold ads and not programmatic ads.

[pranay-prabhat]

Also about your question on "Is it correct that the publisher already needs to reach out to someone because they do not have any conversion pixels on the advertiser site?" :- I am unclear why do pubs need to put conversion pixel on advertiser site. If chrome knows a user got converted by .well-known redirect from an advertiser server, all i am saying is that if it makes sense for chrome to send conversion report to the impressionOrigin as well of the original impression.

Yes on the point that impressionId of the original impression is set by the AdNetwork and publisher will make no sense of that id. But this is where i am proposing a change where a publisher working with ad server "is aware" of the id of every single ad shown on their site and when the ad is displayed it should have an id which makes sense to the publisher as well and not just the adtech vendor. That same id can be used in conversion reporting

[johnwilander]

WebKit's proposal Private Click Measurement solves or intends to solve the above issues by:

• Sending attribution reports to the click source (publisher in the above discussion) and the advertiser. See: Send report to both click source and destination privacycg/private-click-measurement#53
• Offering a same-site "pixel" conversion method as well as a JavaScript API with which the advertiser can convert whatever it wants, including wild card '*', and there will be no more need for third-party tracking pixels. See: Offer same-site pixel "API" as alternative to a JavaScript API privacycg/private-click-measurement#71

[adtechnology]

I agree with Pranay's suggestion. It doesn't make sense to move pixels back and forth when all the information is in the browser. The publisher should be able to get all conversions and KPIs directly from the sandbox. This makes the internet cleaner and we have less "pixel rubbish"

[pranay-prabhat]

@johnivdel any thoughts on above?

If we want to take it up over a call with you what could be the best place?

Thanks,
Pranay.

[johnivdel]

Per your comment above, if the impression origin and the reporting origin agree on an id to use that is understandable by both parties, I can see how this would be very useful to publishers. It would be great to align with PCM as well.

From a privacy POV, sending a duplicate report to another party doesn't seem to hurt.

There may need to be some mechanism for the advertiser site to control whether to send a duplicate report to the publisher. As it currently stands, the impression origin has a way of consenting to a specific advertiser learning about an action on their site. This is because script on the impression page knows the final url the user navigates to (via the attributionDestination attribute).

The advertiser site doesn't have similar controls by default, and may not know what impression site would get a duplicate report. Because the conversion event info is owned by the advertiser site, they should have some control over whether it gets sent to another party.

One way this could be done is with an advertiser side config that controls the duplicate impression origin report behavior.

[pranay-prabhat]

Thanks @johnivdel . It seems your answer looked promising till here :- "Because the conversion event info is owned by the advertiser site, they should have some control over whether it gets sent to another party.". A publisher will always provide consent to the advertiser as a) they want to of-course show an ad on their site at the very first place for monetization purposes b) an advertiser needs to know for click event so that the eventual conversion make sense to them from attribution perspective.

BUT an advertiser has no incentive to approve original publisher to receive a conversion report and might mostly disallow it. How do we make such an arrangement really work to what we are trying to solve overall.

Thanks,
Pranay.

[darobin]

More generally, to @pranay-prabhat's comment, I disagree with the contention that the conversion even info is somehow "owned" by the advertiser site. Conversion is a process that spans multiple sites, and there is no reason to believe that one site is more entitled to that information that others. There is no such thing as advertiser privacy.

[AramZS]

I agree with @pranay-prabhat and @darobin here. The conversion event is, by definition, owned by both the referring and receiving site and both should be party to the data. @pranay-prabhat is correct in that the current system of going to a third party like a DSP to understand conversions is an artifact of the current ad tech architecture and should not be used in dictating the future of such architecture.

There may need to be some mechanism for the advertiser site to control whether to send a duplicate report to the publisher.

I think this would be harmful. There are malvertisers who would certainly abuse this feature to make it more difficult to detect bad ads or low quality ads that need to be blocked at different levels of the infrastructure.

Further, one of the core problems that I think multiple folks from Google have so ably identified elsewhere in the privacy sandbox is that the system needs to operate on a zero-trust mechanic. That is, we should be aiming to create a healthy advertising ecosystem that has a quality experience for users without any single party in the ad tech system being a single point of trust. Publishers, advertisers and middlemen regularly audit ad conversion reports in the current system because of this lack of trust between parties and it seems to me that making such a report solely in the hands of the advertiser would exacerbate that lack of trust, not resolve it.

Since a conversion event's occurrence would be significantly more accurately (that it occurred) measured in a system like this one, the goal should be to eliminate friction by making that data available to both publishers and advertisers. This would help eliminate multiple specific issues plaguing the ad tech ecosystem that drive it towards more-privacy-invasive methods and instead create an incentive for a move towards more privacy-respecting methods.

[johnivdel]

To clarify on my above comment, by "conversion event info" I was specifically referring the the 3 bits of metadata set by the advertiser site. Sorry for any confusion due to poor word choice.

I agree that the report (64 bit publisher side data + 3 bit advertiser site data) is jointly owned by the publisher and advertiser.

Since a conversion event's occurrence would be significantly more accurately (that it occurred) measured in a system like this one, the goal should be to eliminate friction by making that data available to both publishers and advertisers.

Adding additional controls doesn't necessarily mean adding more friction. A browser could send a duplicate report to the publisher by default, but have a mechanism for the advertiser to opt-out of this behavior.

BUT an advertiser has no incentive to approve original publisher to receive a conversion report and might mostly disallow it. How do we make such an arrangement really work to what we are trying to solve overall.

Is the concern here around the friction of this mechanism, or the fact that such a mechanism exists to begin with? For the former, as noted above, browsers could modify the default behavior.

For the latter, I agree that giving the advertiser site more fine-grained control than the publisher site in deciding who can receive a report is unideal. Maybe a better mechanism is:

• if an attribution report gets generated, it will always get sent to both the reporting origin and impression origin
• the advertiser site has the ability to not generate attribution reports for specific impression origins to begin with (via some browser provided mechanism)

(In other words, if the advertiser site doesn't want to send a duplicate report to the impression origin, they cannot get the report either)

This better aligns the level of consent the publisher/advertiser sites have while still addressing the concerns in my above comment.

[AramZS]

You're saying that you anticipate a case in which the advertiser does not want to measure conversions?

If so... why? Is this a likely case, is it known, has anyone asked for it? I think that the better assumption is that conversion reports will always be needed, and adding extra complexity by allowing advertisers to opt out of measurement is likely to only lead to error. But perhaps I'm missing something. Can you talk a bit to the use case you are thinking of @johnivdel ?

[AramZS]

I thought about this some more and pending a use case from @johnivdel - the only reasons I can see that an advertiser would want to opt-out of conversion tracking is if they are using a product that promises to measure it for them in a different way (which would be unlikely to work and t/f is either privacy-invasive or fraud) or does not want measurements of its ads leaking to the publishers in a way that might show they have malicious instead of traditional goals for their advertisement (fraud).

I think it is fine if an advertisers says 'we don't want this data', but I'm having a really hard time understanding what the use case would be for them not wanting a publisher to have the capability to record such data, other than fraud. On the flip side, publishers are highly incentivized to have this data not just for conversion measurement reasons, but for optimization reasons as well (for example: what ad positions are converting vs what ones don't) that are legitimate. I am admittedly biased here, but I'm not sure what a publisher could do with its status of potential sole ownership of a conversion report that is fraudulent or privacy-invasive?

[slayser8]

I agree with @AramZS on this - I am unsure what privacy or business reason an advertiser would have for not wanting to share this data with the publisher, especially if it means that a publisher could use said data to optimize towards better performance for advertisers. It greatly improve the trust and transparency between parties in this scenario, especially considering publishers share vast amounts of data with the buy side on the performance of their campaigns (and much more as well). Would be great to have further usecases @johnivdel

[johnwilander]

Advertisers not wanting to share attribution data with click sources/publishers is a serious requirement. I was brought up with me for Private Click Measurement and filed here: privacycg/private-click-measurement#65 We discussed it on the last Privacy CG call, heard both sides, and ended up concluding it should be an option for the advertiser to not share campaign performance data. They are the ones paying for the ads and the click source may not be someone they want to share data with.

Imagine the NewEmail company who wants to advertise on PopularSearch and uses PCM or Conversion Measurement API to measure campaign performance. PopularSearch also happens to own PopularEmail and now gets to see its competitor NewEmail’s sales numbers based on PopularSearch ad campaigns.

Or imagine GameConsoleCompanyA running ads on GadgetNews and then GadgetNews sells GameConsoleCompanyA's ad campaign performance data to GameConsoleCompanyB.

Or GameConsoleCompanyA runs ads on GadgetNews, GadgetNews commissions AdTech to process its attribution data, and AdTech sells GameConsoleCompanyA's ad campaign performance data to GameConsoleCompanyB.

In summary, there are advertisers who have legitimate reasons for not wanting to share their advertising+sales data.

[pranay-prabhat]

@johnwilander regarding : -

Or GameConsoleCompanyA runs ads on GadgetNews, GadgetNews commissions AdTech to process its attribution data, and AdTech sells GameConsoleCompanyA's ad campaign performance data to GameConsoleCompanyB.

Isn't the conversion-measurement-api allowing that? i.e. AdTech in conversion-measurement-api solution is anyways getting the conversion report and can sell GameConsoleCompanyA's performance to GameConsoleCompanyB?

@johnivdel regarding your comment : -

(In other words, if the advertiser site doesn't want to send a duplicate report to the impression origin, they cannot get the report either)

Yes this helps reducing the friction where everyone plays fair but i am not sure if i am missing out on any aspect by doing it this way @AramZS ?

[pranay-prabhat]

They are the ones paying for the ads and the click source may not be someone they want to share data with.

When advertisers pay for ads, they are "using" publishers and leverage the hard work publishers do leading to a user visiting the page. I don't understand how this makes sense that advertiser knows whether a publisher a or b or c works for them or not but Publisher will be at the mercy of advertisers get to know if Advertiser a or b or c work well for their monetization or not.

And how does it make sense that advertiser who knows whether pub a or pub b works for them will take conversion data on Pub A and helps Pub B to monetize better with Pub A getting blindsighted?

Bottom line is that @johnivdel likely said the best thing here i.e. both pubs and advertiser agree to get the conversion report OR no one gets anything.

[johnwilander]

They are the ones paying for the ads and the click source may not be someone they want to share data with.

When advertisers pay for ads, they are "using" publishers and leverage the hard work publishers do leading to a user visiting the page. I don't understand how this makes sense that advertiser knows whether a publisher a or b or c works for them or not but Publisher will be at the mercy of advertisers get to know if Advertiser a or b or c work well for their monetization or not.

I’m not saying publishers and their screen real estate aren’t important. On the contrary, advertisers are paying to place their ads there.

And how does it make sense that advertiser who knows whether pub a or pub b works for them will take conversion data on Pub A and helps Pub B to monetize better with Pub A getting blindsighted?

Bottom line is that @johnivdel likely said the best thing here i.e. both pubs and advertiser agree to get the conversion report OR no one gets anything.

What about the use case I just outlined, where the publisher and the advertiser are competitors in the same market – the NewMail vs PopularMail case? Forcing NewMail to share their conversion data will likely mean they can’t use the API on PopularSearch which puts them at a significant disadvantage.

[pranay-prabhat]

What about the use case I just outlined, where the publisher and the advertiser are competitors in the same market – the NewMail vs PopularMail case? Forcing NewMail to share their conversion data will likely mean they can’t use the API on PopularSearch which puts them at a significant disadvantage.

"Forcing NewMail to share their conversion data" :- How will you track what reasons NewMail has to not share this data with publishers? Any advertiser can come up with any xyz reason to not share this data if you allow them to do so.

Also talking about NewMail vs PopularMail. If NewMail is worried about this they are most welcome to not advertise on PopularSearch. If PopularSearch is large and popular enough that still NewMail is compelled to Advertise there then honestly that is harsh reality even today where PopularSearch already has massive data to make it products (i.e. PopularMail) work well anyways.

If we take corner examples like above then we are giving excuses to advertisers to use any reason to not share data. When they partnered with a publisher to market their products then publishers also have a stake in terms of knowing properly how marketing works on their site.

Also an advertiser not sharing this data with publisher can use the data and help other companies who are competitor of the publisher. With Publisher getting blind-sighted.

The clean solution here is to let both parties get conversion data or no one gets if either party disagree.

[johnwilander]

What about the use case I just outlined, where the publisher and the advertiser are competitors in the same market – the NewMail vs PopularMail case? Forcing NewMail to share their conversion data will likely mean they can’t use the API on PopularSearch which puts them at a significant disadvantage.

"Forcing NewMail to share their conversion data" :- How will you track what reasons NewMail has to not share this data with publishers? Any advertiser can come up with any xyz reason to not share this data if you allow them to do so.

Also talking about NewMail vs PopularMail. If NewMail is worried about this they are most welcome to not advertise on PopularSearch. If PopularSearch is large and popular enough that still NewMail is compelled to Advertise there then honestly that is harsh reality even today where PopularSearch already has massive data to make it products (i.e. PopularMail) work well anyways.

Legacy tracking of click-through conversion did not mandate data sharing with the click source. The NewMail vs PopularMail+PopularSearch case is not theoretical in a fundamental sense. It’s a reality today that some advertisers absolutely don’t share their conversion rates and values. If our new APIs don’t allow for that, those advertisers won’t use the APIs. That may be the decision but it should be acknowledged.

The intention is to allow advertisers to control this in PCM.

If we take corner examples like above then we are giving excuses to advertisers to use any reason to not share data. When they partnered with a publisher to market their products then publishers also have a stake in terms of knowing properly how marketing works on their site.

I assume that’ll go into contacts or pricing. No data sharing => different contract.

Also an advertiser not sharing this data with publisher can use the data and help other companies who are competitor of the publisher. With Publisher getting blind-sighted.

The clean solution here is to let both parties get conversion data or no one gets if either party disagree.

[darobin]

I think it's worth pointing out here that "they pay for it" is not a principle of Web architecture, any more than "they developed the audience and organised the inventory" is.

Advertisers sharing conversion rates with a potential competitor may be a problem. Publishers being excluded from conversion data, possibly by the default (or only) setting of advertiser intermediary software is also a problem. (And not a theoretical one, either.)

If constituencies are at odds, the way in which we usually pick is by establishing a priority of constituencies. We don't currently have that for advertising, but we could. I would suggest:

1. Users — the whole Internet is for them, see RFC 8890, over
2. Publishers — the reason advertising exists is to finance our attention commons, otherwise almost no user or publisher would want it, over
3. Advertisers — who bankroll the system, over
4. Intermediaries — who pipe it all together, over
5. Specifiers — but who ever cared about those, over
6. Theoretical purity — LOL, this is the Web AND adtech.

[johnwilander]

I've marked PCM's equivalent issue privacycg/private-click-measurement#65 for re-discussion at the next Privacy CG call.

[AramZS]

Allow me to drill down on the specific case that @johnwilander is talking about here, b/c I do think I need to make sure I've got it right and we can talk about it without muddying the waters:

What we're talking about

We're talking about the specific use case of programmatic buyers interested in conversion-optimizing campaigns on large multi-product conglomerates who own both ad space and products with which advertisers may want to compete and ONLY that case from what I can read. While this concern represents a significant minority of the urls on the web it does represent a significant majority of the impressions buyers target for purchase and therefore is a use case which we should absolutely discuss.

What we're not talking about

We're not talking direct sold ads, because those have a direct contract between buyer and seller that allows them to specify data use and sharing in both directions via contractual obligations regardless of if the data is or isn't available to either side.

We're not talking about programmatic buyers who purchase inventory via programmatic on the vast majority of URLs, which are not owned by vertically integrated multi-product conglomerates.

We're not talking about mediated marketplaces like Etsy or Hosted Shopify, as those entities presumably would have access to this report and are not incentivized to abuse it.

We're not talking about the philosophical debate over if this type of PopularCo vertical integration should be allowed (sadly).

What is the status quo?

So the idea that I see from @johnwilander seems to be that we want to maintain the status quo of PopularCoSearch not getting NewCoEmail conversion data in order to preserve NewCoEmail's potential disruptive advantage against PopularCoEmail.

Nothing about what we are attempting to do here will maintain the status quo. It is inherently disruptive of it and that is because we have collectively decided that disruption of the status quo is good. I agree that the current status quo is bad and needs fixing. So if we want to retain a feature of the status quo, arguing that it exists is not a sufficient reason. We have to say why it is good. But let's talk through both points.

1. Is this the status quo?

Ok... let's dismiss PopularCo and talk about reality for a second. There are two huge companies which both own ad space and arguably have an interest in constantly out-competing conversion-focused products that bid on that ad space. They are the most serious examples we could be concerned with when talking status quo - Facebook and Google.

We know, thanks to their recent announcements that they won't be doing so in Apple apps going forward, that Facebook indeed measures lift, which requires measuring conversions on behalf of their advertisers. Which means in the current status quo Facebook has access to advertisers' conversion reports.

We also can see in their documentation that Google also syncs conversion reports with advertisers, usually through a cookie or pixel or their feature "Floodlight".

And we can take a look at some smaller companies than Google... we can see that say... if you want to advertise on Verizon Media and you are a publication or a phone company they also have access to your conversion data for optimization reasons.

So I think... no, one sided conversion reports are not really currently part of the status quo, except in the most platonic idea of the present. Especially not with the group you are concerned with that could fall into the category of a vertically integrated PopularCo. In fact the vertical integration of PopularCo itself endangers the entire concept. If your sign up for NewCoEmail and start with a PopularCoPhone or PopularCoEmail to sign up, than PopularCo already has that data to join anyway. But even outside that group, conversion reporting in the current state of the web is real time and used for real time optimization on all sites where it is measured... which means that the publisher site must have some level of access to that reporting, even if it is mediated through a third party and used via automation.

2. Is this something we want to preserve / create?

If PopularCo gets NewCo's conversion data about their sole product NewCoEmail then PopularCoEmail could outbid, outmarket or shift product strategy to eliminate NewCoEmail. Therefore a (very) theoretical status quo in which PopularCo does not have access to that data which makes NewCo more competitive and capable of disruption of PopularCo. That makes sense in theory to me. But I don't think it is a very appreciative line in reality.

I agree with @pranay-prabhat here. If NewCo is concerned with this problem... they probably shouldn't be advertising on PopularCo? Absent of something like a fenced frame (which I don't believe either PCM or this proposal ships with) there is no way to really stop PopularCo from aligning basic click measurement + internal first party user data. Besides which there are competitive analysis products that can be used to load ads (even in fenced frame sites) across a variety of sites with a variety of user profiles and collect data that way.

So do we want to create this?

I think a strong argument can be made against creating this imbalanced reporting mechanism. I agree with @pranay-prabhat that if we must have an on/off switch for this feature it should be both sides or none. But I'd rather not have that option either.

Why?

Well, publishers are responsible for the ads that are shown on their site. If an advertiser shows an offensive, malicious, misleading, or phishing ad, generally users do not go to the Ad Server, the Ad Exchange or the Ad Agency to complain about that ad... they go to publishers. Users rightfully see publishers as the point of responsibility with which they have direct contact and who are responsible for securing their experience. This understanding of how users approach ads (or indeed any third party embedded feature) is baked into almost all the privacy proposals at this point by nature of them moving responsibility to the "first party" - the publisher. This is why it makes sense to me to organize constituencies as @darobin does above.

Click tracking and conversion reports are strong signals into activity on a publisher site. Abnormal click rates are, for example, a frequent indicator of fraud. Publishers currently use these signals, along with a variety of others, for optimization purposes--often to compete with PopularCo-like companies--and advertisers generally desire them to do so.

And while you have one stated case for advertiser-only reports, it's worth thinking through what the threat is from that approach:

• It incentivizes and rewards sketchy lead-gen companies to make increasingly manipulative and/or malicious ads to drive conversion without giving the publisher any insight into what is going on that might potentially harm their users. (Hiding abnormally high conversion)

• It creates an opportunity to launch ads that purposefully don't have an interest in converting in the hope of revealing information about the user that could leak through privacy measures. (Hiding privacy violating behavior)

• It creates an opportunity for bid manipulation around low quality or malicious-script-running advertisements (ex: bitcoin miners) that destroy the quality of the publisher site either purposefully or not. (Hiding bad ad behavior)

• Clawback Manipulation - as I noted in the multiple links in my first comment, this gives malicious or scamy companies that manage advertising on behalf of advertisers to become the only point of truth for conversion reporting, a situation which they are clearly very interested in manipulating to their behalf and to the detriment of advertisers and publishers. Unlike the current situation where there are potentially trusted third parties in the mix to handle that conversation, there is no space for those in the current specification, which means there is no way to stop the organization running the ad from lying about conversion and reaping the significant monetary benefits that such lies would accrue them. (Hiding bad market manipulation)

As you can see, there are multiple significant incentives, including monetary incentives that can easily scale to multiple millions of dollars, for an advertiser-only conversion report to be abused.

As such, I can see the concern from the buy side here, but I think it is significantly outweighed by user, publisher and quality-of-the-web interests and even the interests of individual brands who may not often be involved in these discussions.

Sorry for the long response, but I wanted to make my reasoning and concerns here very clear and the problem is complex. Please let me know if I've unintentionally misrepresented anyone's position.

[johnwilander]

So I think... no, one sided conversion reports are not really currently part of the status quo, except in the most platonic idea of the present. Especially not with the group you are concerned with that could fall into the category of a vertically integrated PopularCo.

I may be misunderstanding you but there are absolutely advertisers today who 1) feel they have to run click-through ads on popular search engines and social networks to stay competitive, and 2) have made darn sure that no conversion or sales data goes back to those search engines and social networks, for business reasons.

Let's say the choice was supported in the API and that publisher sites could signal whether or not they accept ads that don't share conversion data. Do you foresee most or even all publishers making the choice to not accept such ads to bid on placement? Would they reject direct sold ads that won't share data? If the API doesn't support the choice, we're making the choice for all publishers (and advertisers).

Your analysis of Publisher vs PublisherAndTrackingAndAdvertisingAndPlatformsAndMessagingAndMoreAndMore is true to a large extent but I can see advertisers not wanting to share conversion/sales data with any publisher website. Not because they view the publishers as a competitors but because they don't want to take on the risk to their business.

(The problem with publishers not knowing which ads are shown on their site will not be solved though conversion reporting since only a fraction of ads are clicked and convert.)

[AramZS]

@johnwilander I think there may be advertisers who feel their conversion data isn't accessible to PopularCo, but that feeling arguably does not reflect the reality we've seen thus far.

How do you see this as a risk to their business in the case of a non-vertically integrated first party with no competing products?

[johnwilander]

@johnwilander I think there may be advertisers who feel their conversion data isn't accessible to PopularCo, but that feeling arguably does not reflect the reality we've seen thus far.

I don't understand what you're saying here – the feeling part. Are you saying these advertisers are indeed sharing their data with publishers and just think that they're not?

How do you see this as a risk to their business in the case of a non-vertically integrated first party with no competing products?

Any website can leak data. It can be hacked, it can share with third-parties that leak the data either deliberately or through a compromise, etc.

[AramZS]

To be clear, I am saying that they are indeed sharing their conversion data with large scale vertically integrated multi-product sites that own an advertising venue, a mobile device provider and an email provider, regardless of what they feel and that is a situation that has been documented in the press.

Edit: Adding a 2nd example here relevant for app-based conversions.

[johnwilander]

To be clear, I am saying that they are indeed sharing their conversion data with large scale vertically integrated multi-product sites that own an advertising venue, a mobile device provider and an email provider, regardless of what they feel and that is a situation that has been documented in the press.

If that's true for all advertisers, that's news to me. Doesn't sound plausible to me. It would mean that there is no way to protect your sales/conversion data if you advertise online. Do you have a link to that information?

[johnwilander]

Sure, it's game over if the publisher owns the browser or the operating system where the ad click and conversion happens, and the publisher leverages that power to extract sales data from the advertiser. However, we're not designing web functionally under such assumptions. 🙂 There are multiple browsers, multiple browser engines, and multiple operating systems. What I'm discussing here is the possibility for an advertiser to not share sales/conversion data with publishers. That possibility assumes that the underlying platform isn't trying to subvert the whole thing.

[johnivdel]

Trying to relate the above discussion back to the API, It seems like the following matrix captures all possibilities for who should receive a report given some configuration (source origin = impression origin / publisher; attributiondestination = advertiser):

Attributiondestination config	Source origin requires duplicate report	Source origin wants duplicate report if possible	Source origin doesn't want duplicate report
Always send duplicate report	Both	Both	Reporting origin
Duplicate report if wanted	Both	Both	Reporting origin
No duplicate report	Neither (?)	Reporting origin	Reporting origin

If we take corner examples like above then we are giving excuses to advertisers to use any reason to not share data. When they partnered with a publisher to market their products then publishers also have a stake in terms of knowing properly how marketing works on their site.

@pranay-prabhat's comment above calls for "Source origin requires duplicate report" to be a browser configuration.

I think a strong argument can be made against creating this imbalanced reporting mechanism. I agree with @pranay-prabhat that if we must have an on/off switch for this feature it should be both sides or none. But I'd rather not have that option either.

Suggests that the source origin should ultimately have the final choice, and that the "Neither" cell should be "Both". @AramZS is that interpretation correct?

Legacy tracking of click-through conversion did not mandate data sharing with the click source. The NewMail vs PopularMail+PopularSearch case is not theoretical in a fundamental sense. It’s a reality today that some advertisers absolutely don’t share their conversion rates and values. If our new APIs don’t allow for that, those advertisers won’t use the APIs. That may be the decision but it should be acknowledged.

Calls for "No duplicate report" to be a browser configuration. @johnwilander it seems like you are arguing that ultimately the final choice should be the attributiondestination's, and that "neither" should be "reporting origin" (or "advertiser" for PCM), is that correct?

I think both of these configurations have valid justifications, and are generally trying to solve for different scenarios with different types of publishers and advertisers.

"Neither" is an unfortunate outcome, but having the browser make a one-size-fits-all decision on what party to prioritize seems less flexible for developers and the ecosystem. As I mentioned above, from the perspective of the web API, both the publisher and advertiser own the data within the attribution report. Prioritizing one party gives that side "true" ownership of the report.

If these configurations were supported, do we think that leaving the resolution of "neither" to the parties involved is a reasonable outcome? For example, if siteA and siteB have a joint configuration that results in "Neither", they can make respective changes/concessions if they want?

What I'm discussing here is the possibility for an advertiser to not share sales/conversion data with publishers. That possibility assumes that the underlying platform isn't trying to subvert the whole thing.

It seems like the key question is whether allowing a publisher to require duplicate reports at the same time makes this inoperable. Per the table above, what you outline is a possibility, but it is not the only option.

Note: how such a mechanism could be integrated with the API is still unclear, but aligning on the desired behavior first makes sense.

[AramZS]

@johnwilander

Sure, it's game over if the publisher owns the browser or the operating system where the ad click and conversion happens, and the publisher leverages that power to extract sales data from the advertiser. However, we're not designing web functionally under such assumptions. 🙂 There are multiple browsers, multiple browser engines, and multiple operating systems.

To be clear, I'm not even talking about subverting the browser to track conversions, I'm talking about the fact that the nature of advertising on a multi-product vertically integrated popular company's website means that conversion data will inevitably flow through one of their systems at some point and be joinable with the rest of their data. The linked journalism makes clear that has indeed happened in the past, so the status quo in which that is not the case doesn't really exist, any claims otherwise not withstanding.

But even beyond that... who is doing the conversion tracking right now? Most advertisers do not run owned and operated reporting suites, analytics tools or even conversion tracking scripts. Those scripts all inevitably run through other companies with which they have to be sharing their data with in the current day. Many of those companies leverage identity graphs which implicitly resell that data--or at least the valuable indicators it produces--often to competitors. There is no situation in which a company is running conversion tracking in the present day where it is not shared with some entity an, for most impressions on the web, that entity is also the advertisement's venue. Where it isn't, it is being mediated by a third party with whom they have to trust that data.

[AramZS]

@johnivdel I think you're proposing that either the source origin or Attributiondestination could ask for both, in which case both would be sent regardless of the configuration on the other side? I think that's acceptable, because it would mean that the only way to remove reporting from the process is that both sides would have to specify it, is that right?

[AramZS]

I think it is likely worth thinking about how that could potentially contribute to market-based pressure from one side on another though. I'd be interested in hearing more opinions on that.

[johnivdel]

@johnivdel I think you're proposing that either the source origin or Attributiondestination could ask for both, in which case both would be sent regardless of the configuration on the other side? I think that's acceptable, because it would mean that the only way to remove reporting from the process is that both sides would have to specify it, is that right?

I'm proposing that both the source origin and attributiondestination need to agree on the duplicate report behavior. If the source origin wants a duplicate report, and the attributiondestination agrees to send it, that is fine.

If the source origin explicitly requires a duplicate report, and the attributiondestination explicitly doesn't want to send it, then there is an issue. Since the two sides couldn't agree, neither should get the report as the report data is owned by both parties. This is the only case in the above table where the two disagree.

The onus would be on the two involved parties to resolve the disagreement, rather than the browser making a choice which would benefit one of the parties.

[abebis]

@AramZS

There is no situation in which a company is running conversion tracking in the present day where it is not shared with some entity

Sharing conversion data with a measurement vendor is quite different from sharing with the ad network or publisher. Advertisers that want to keep conversion data for themselves use a measurement-only tool, and don't put any ad network tracking pixel on their site (Apple tracking search ads conversion is probably a good example).

[pranay-prabhat]

@johnivdel Does chrome plans to make this change to the conversion api? We will love to test this as a part of origin trials.

[pranay-prabhat]

Another attempt @johnivdel @csharrison . I checked meeting notes and could not see any discussion for this issue. We are happy to join over a call to talk about this further but overall getting access to this report will be a big deal for publishers especially if the same concept carries over to view-through conversions as well. If this can be added to future versions of the api we will love to test it out via origin trials.

[johnivdel]

Hi Pranay,

Sorry for the delayed response, this fell off my radar.

There was some discussion at the PrivacyCG F2F on this in regards to PCM that somewhat supports the idea of having both publisher/advertiser agree on the behavior.

Regardless, we still need to come up with an API surface that can be used to provide this configuration on publishers/advertisers sites.

I still need to formalize some thoughts on this, and will follow up with a few potential solutions.

Tangential to the mechanisms for sites to disagree on the duplicate report behavior:

It seems like we will also need to be careful about the default behavior. If the browser defaults to sending a report to the impressionOrigin, those sites may be getting a lot of wasted requests if they do not actually listen for these reports.

@johnwilander is the intention for PCM to send the reports by default to the source origin? Or will source origins have to indicate in some way they want to receive the reports?

[pranay-prabhat]

@johnivdel Trying to get the ball moving here. We as Publishers will hope to get direct access to this conversion data without any dependency on an AdTech vendor. Is this something we hope to test in one of the upcoming enhancements this year?

Regarding the default behavior isn't it possible that publishers only with Y on receive the ping with conversion data?

[johnivdel]

Regarding the default behavior isn't it possible that publishers only with Y on receive the ping with conversion data?

Yes, I think something like that is reasonable but it's not obvious how this should be done: per-event, per-page, per-origin, etc.

I will add this to the agenda for the next call so we can make progress here.

[maudnals]

Discussed during 9/20 WICG meeting:
Today, in some systems, this is configured via Reporting profiles: certain vendors will get impressions and clicks, others would get specific campaigns, etc.

[pranay-prabhat]

@johnivdel Thanks for picking this up. Unfortunately i could not attend the meeting but i went through the meeting notes on Github.

As discussed above and supported by other publishers, the conversion data in detail could be meaningless for impressionOrigin but what matters is the number of conversions based on ad campaigns running on our sites.

I was originally thinking per-origin but per-page will be better. Looking forward to more documentation/updates on this feature.