Ample customer feedback supports the notion that people dislike highly repetitive ads. Not only that, advertisers do not want to spend their ad budgets showing the same ad to the same user again and again. They would prefer to show an ad a couple of times to a 1000 people rather than a 100 times to a few dozen. This is the motivation for Frequency Capping.
Advertisers would like to limit the frequency of their ads in several ways. First, they want to limit the number of times a user sees a specific ad, any ad from a given campaign or any ad from the company. For each of these, they want the limits to apply for different time intervals, with common intervals being within the same hour, day or week. For example, an advertiser might not want a specific ad shown to the same user more than twice in an hour, 5 times in a day or 10 times in a week. They may also request that the user not see more than 5 ads from the same campaign within an hour, 15 times in a day or 30 in a week. They might also want to limit their ads from all campaigns to 10 in an hour, 25 in a day and 50 in a week. In some cases, they may also want to impose different limits if the the user clicked on one of the ads without converting (perhaps not displaying any more of their ads to the user within the next hour). If the user converts (with or without a click), then functionality such as that described in Private Exclusion Targeting Rendered Exclusively Locally (PETREL) should apply.
- Russell Stringham (rstringh@adobe.com)
There are a number of proposals for private conversion measurement including Private Click Measurement (Webkit/Apple), Conversion Measurement API (Chrome/Google) and Private Lift Measurement. These require that the browser keep track of ads that were previously clicked (and could easily be extended to ads that were viewed). If the browser is keeping this information anyway, then it would be a fairly small enhancement for the ad network to include the frequency caps for an ad along with the other ad metadata when it serves an ad. The browser could examine its ad history for this specific ad, specific campaign or other ads from this advertiser and compare the number found in the appropriate time ranges to the specified frequency caps.
If an ad is found to have exceeded its frequency cap, the browser would need a different ad to display. If it were to simply request a new ad, that would increase the page load time, as this would require another request to the ad network and another round of ad bidding. The result might be the same ad again or another ad that is also over its frequency cap, creating further delays.
Instead when the ad network responds to an ad request from a browser with an ad that includes frequency caps, it should provide one or more alternate ads as well. The browser should check each ad until it finds one that has not exceeded its frequency cap. The ad network can guarantee that the browser finds an ad to display by making sure that the last ad in its list does not have a frequency cap. A more complex alternative would be to follow the example of Two Uncorrelated Requests, Then Locally-Executed Decision On Victory (TURTLEDOVE) in allowing the ad network to provide some JavaScript that would decide which ad to display when all have their frequency caps exceeded.
When the ad network provides more than one ad, the browser would need to report back which was actually displayed, so that only the advertiser for the displayed ad is billed.
If an ad network sets the frequency cap to a small value for a series of its ads, then it may be able to identify a user based on the ads that user has already seen. The ad network can determine that the user has seen particular ads if the browser checks the list of ads provided by the ad network in order and then reports the first that it has not seen too many times. However, I have not been able to come up with a plausible implementation of this attack at scale, except for the special case of identifying that someone is a returning visitor to a site (within the previous week), even though there are no cookies or local storage values to indicate this. It works by serving two ads. The first has an ad specific frequency cap of once per week and the second has no frequency cap. If the first ad is shown, the user has not been there in the previous week. If the second is shown then the user is a returning visitor. The publisher may use small or hidden ads as part of this type of attack as a form of covert tracking. The browser should not report back on which ad was displayed if the ad was too small to be seen or is otherwise not visible.
The browser can make this attack more difficult by randomly selecting to display any of the ads that have not been seen too many times, rather than checking the ads in order. However, that will often result in display of an ad that bid less than some of the other ads, reducing publisher revenue. If the browser selects the first ad under its cap 95% of the time, and another the other 5% of the time, publisher revenue is less impacted.
As another option, the browser could add some noise to the specified caps, sometimes treating the cap as exceeded when it is still slightly under the cap, or perhaps 5% of the time allowing the cap to be exceeded by 1 or 2 views. This generally has a smaller impact on publisher revenue, but may display some ads more often than desired by the advertiser (i.e. the advertiser is paying for ads they didn't want displayed).
To completely avoid the revenue impacts of not selecting the ad below the cap with the highest bid, the browser could delay reporting back the ad that it chose to display, by using functionality similar to how it reports conversion measurements (see the conversion measurement links above). With these techniques, the browser would report the selected ad at a later time in a way that cannot be associated with the browser. This creates a complication for advertisers that are near the limit of their advertising budgets, because until the ad views are reported, they won't know if they have reached their limit or not, and so won't know if they can afford to bid for additional ad spots. As at least some of the time, this delayed reporting will not occur (for example, user doesn't use this browser again for several weeks), the advertiser will never be billed for these ad views and the publisher won't be paid.
People often convert only after they have seen an ad several times. There may be a range of ad views that corresponds to the best conversion rates. So it may be more effective to favor showing an ad to a user who has already seen it versus showing it to someone who has not. If the ad platform provides multiple potential ads for a particular spot, in addition to providing a frequency cap, it could also provide a desired minimum number of views. After eliminating any ads that have been viewed too many times, the browser could next look to see if any of the ads have been viewed at least once, but fewer than the desired minimum. If so, it could favor one of these ads over other ads, even if they we earlier in the list. Similarly, if an ad has specified a desired minimum number of views, the browser could reduce its chance of being selected if it has not already been viewed at least once.
Since an ad that appears later in the list may end up being selected in either of these cases, the publisher may be paid less for the ad versus an ad earlier in the list. However, the advertiser may actually have been willing to pay more for this subsequent ad view than for a first view or a view after the desired minimum is reached. To support this case, when the browser notifies the ad platform about the ad view, it could indicate if the ad had been seen previously or not, and whether the number of views was below the desired minimum or not, which would allow the ad platform to adjust the ad price appropriately. To assist in selecting the highest paying ad, the ad platform could include two increments with each ad that has a desired minimum. The first would indicate the number of places up in the list that the ad should move if it has been seen at least once, but below its minimum. The second would indicate how much it should move up (or with a negative increment, down), if it has exceeded its minimum, but not its cap. If multiple ads move by the same amount, their relative order would not change.
Functionality similar to TURTLEDOVE could instead be used to perform an in-browser auction to select from among the ads that are below their frequency cap, where the number of times a given ad has been viewed and the minimum desired number of views could be two parameters used by the JavaScript for bidding in the auction.
Advertisers don't want to limit the showing of an ad to the user too many times simply on a single device; they want to make sure that the ad is viewed the appropriate number of times by that user, period. By combining this proposal with Cross-Browser Anonymous Conversion Reporting, when details about ads seen in one of a user's browsers are shared with their other browsers, this data can be evaluated when deciding if an ad has been seen too many times across all their browsers and apply frequency cap limits appropriately. The same applies for frequency optimization. The main issue will be the latency in the data shared between browsers, during which time an ad may be displayed too many times because one browser is not yet aware of recent views on another of the user's browsers.