Concern with delayed reporting affects anti-fraud

[dzenissoftic]

If I understood correctly, the conversions will be delayed 24-48h.
The problem with this is that time between click and conversion can sometimes be used as a sign of fradulent traffic.
E.g. if you get conversion within 10 seconds from a funnel that requires user to complete the purchase of a product, it is highly unlikely this is a valid conversion.
Depending on placement in the funnel, it might be expected that most conversions are received in the first hour. We can use this information to identify those where this is not the case. Example, if we see conversions coming out evenly in every hour, where based on placement, it is assumed that most is coming in the first hour, then this is a sign of potential fradulent traffic.

I am wondering if there is a potential solution for this.

[johnwilander]

We have two main reasons for the 24-48 hour delay.

1. Privacy. If the report goes out instantly or near instantly, it will be easy to match the third-party pixel request with the attribution report. At that point, the third-party is likely to still be running JavaScript on the site the conversion happened and can leverage that power to try to establish cross-site tracking data based on the conversion report it just received.

2. Support for multiple conversions. As soon as a report is sent out, the ad click is consumed. This means there will only ever be one attribution report sent for an ad click. If we allowed multiple reports for one ad click, they could be abused stitch up a high entropy user ID.
   To support multiple conversions under these restrictions, the website is allowed to re-convert an ad click as many times as it wants and submit a priority parameter to instruct the browser which of these conversions is most important to report. If we have no delay, the first conversion will consume the ad click and subsequent conversions will have nothing to match against.

Do you see alternate solutions to the two concerns above?

[dzenissoftic]

I think you are aware of this, but another issue with 24-48h delay is the fact that site owners (search.example in your example) will have to wait at least 48h to understand how the AD is performing. This will reduce monetization of the site because of the following:

1. site owner could be running wrong AD for 48h and therefore missing out on the lost revenue.
2. once site owner finds a specific AD that works OK, site owner will be reluctant to test any new ADs because of the risk of losing 48h of traffic. This will impact Advertisers as well, because it will be harder for them to get site-owners to test their AD.

Multiple conversion issue is a separate problem.
For example, the advertiser might want to track multiple events in order to understand quality of the traffic. In case of AD for mobile game, the examples would be: CTR, Install event, Level 1 event, In-App purchase.
Only at In-App purchase, the Advertiser makes money, but getting to that first in-app purchase might take days. However, in order to quickly optimize, the advertisers will usually watch at stats before that funnel. For example, if they make changes in the app and CTR or number of Install events considerably drops, then it's safe to assume that in-app purchases will drop as well. However, if they receive only one of these events, then it will be very hard to predict the final revenue from in-app purchases. The only way will be, again, waiting until those final conversions actually happen. This might be days and sometimes a week. All of this is preventing Advertiser from making quick changes, which will result in Advertiser losing more money and potentially increasing the cost of their service to offset the fact that they are losing money.

I do understand that with real time conversions, it would be possible to attribute the click, but accuracy of such attribution grows exponentially with time. So you might achieve the same/very similar effect even if you cut down the time in half and make it 12-24h, probably even less.

I don't see alternate solutions though. Will be thinking about this.

[johnwilander]

With a shorter delay like 12-24 hours, the report will reveal during which 12 hours of the day the conversion happened. We’d like to avoid such time-of-day inference and only reveal during which 24 hours the conversion happened, obscuring time of day.

[michael-oneill]

The user cannot be targeted because they are not “singled-out”. Only the browser knows if its user has converted an ad, and advertisers or anyone else are only informed of aggregated counts.

Frequency counting/ad limiting would be a good enhancement, as would impression counting, but these must be enacted by the browser with no personal data transferred.

Fraud detection is necessary also, which should be possible – see my original proposal: https://github.com/w3c/web-advertising/blob/master/admetrics.md

[johnwilander]

Michael is right. An explicit design goal of this feature is that no party should learn or know both that this user clicked the ad and that this user converted. The combination of those two pieces of data constitutes cross-site tracking, i.e. data on what the user has done on two different websites.

Browsers with privacy protections already prevent the site where ads are placed, the ad network, and the advertiser site from knowing this combined information. Privacy Preserving Ad Click Attribution is a net addition of data under such circumstances and thus cannot regress the user experience.

In browsers with poor or no privacy protections, all three parties (site with ads, ad network, and advertiser) can know all the data on both sites.

[hober]

Forward-duping to #27.