Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Concern with delayed reporting affects anti-fraud #6

Closed
dzenissoftic opened this issue May 22, 2019 · 7 comments
Closed

Concern with delayed reporting affects anti-fraud #6

dzenissoftic opened this issue May 22, 2019 · 7 comments
Assignees

Comments

@dzenissoftic
Copy link

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
Copy link
Collaborator

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
Copy link
Author

dzenissoftic commented May 23, 2019

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
Copy link
Collaborator

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.

@Zilad
Copy link

Zilad commented May 27, 2019

The time-out as proposed will actually allow the seller of ad placements (publisher, adnetworks) and ad tech parties between buyer and seller to benefit at the cost of the consumer. Also it will create an even greater stigma against ads.
Note i am a big fan of this initiative as a whole, but a few details such as the delayed reporting seem to be based on a high amount of fear + the idea that users do not understand much, which does not seem to be substantiated with proper arguments.

It is information like time of day but also the simple fact the conversion has already happened that will allow buyers (which can be advertisers, agencies, ad networks, ad tech companies and even publishers) to not bombard users with the same or similar ads, simply because they already converted enough. As in, a user visiting a product page after a click could be enough for a campaign to stop targeting a user simply because historic data has shown spending more money will not lead to more revenue.
Removing the realtime conversion attribution will lead to buyers spending more money during that window (24-48h) and sellers profiting from it, while users will wonder why they keep seeing ads they have already clicked on. This is bad user experience in my opinion and one of the reasons why adblockers became popular in the first place --> This is also why I do support this initiative as a whole: In the "old" situation buyers have been able to properly exclude converted users (adtech has made that very easy over the years) but have been extremely sloppy with their campaign configurations. That is why I do understand the proposal of this extreme measure, but it will simply punish buyers that have been running proper campaigns and annoy users even more.

Without being able to properly optimise campaigns and exclude users using realtime conversion attribution, we are simply helping the parties that are on the receiving part of the advertising budgets.

@michael-oneill
Copy link

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
Copy link
Collaborator

johnwilander commented May 27, 2019

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
Copy link
Member

hober commented Apr 30, 2020

Forward-duping to #27.

@hober hober closed this as completed Apr 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants