W3C home > Mailing lists > Public > public-tracking@w3.org > July 2012

Re: Frequency Capping

From: Brian O'Kelley <bokelley@appnexus.com>
Date: Thu, 12 Jul 2012 16:26:03 -0700
To: Chris Mejia <chris.mejia@iab.net>, Jonathan Mayer <jmayer@stanford.edu>, David Wainberg - NAI <david@networkadvertising.org>
CC: W3C DNT Working Group Mailing List <public-tracking@w3.org>, Brendan Riordan-Butterworth <Brendan@iab.net>, Mike Zaneis <mike@iab.net>
Message-ID: <CC249EFA.B9475%bokelley@appnexus.com>

I think your points below are valid - we could reorder campaign selection such that we check frequency caps only for the limited set of campaigns that sort to the top on expected value. It would be very expensive, but it would be technically possible.

However, one of the core tenets of performance advertising is the use of frequency data to predict response. It's part of the holy trinity (creative, placement, frequency) that dictates the success of direct response advertising. For performance advertising to work we need to lookup frequency before we figure out the price, and that can't happen the reordered algorithm you suggest. Note that from a privacy perspective, you should be very pleased that our optimization algorithm doesn't use any historical user data or behavioral segmentation (though our clients could explicitly target their own behavioral data outside the algorithm).

I'd be happy to answer any other questions - this is a personal passion of mine!


From: Chris Mejia <chris.mejia@iab.net<mailto:chris.mejia@iab.net>>
To: Jonathan Mayer <jmayer@stanford.edu<mailto:jmayer@stanford.edu>>, David Wainberg - NAI <david@networkadvertising.org<mailto:david@networkadvertising.org>>
Cc: W3C DNT Working Group Mailing List <public-tracking@w3.org<mailto:public-tracking@w3.org>>, Brendan Riordan-Butterworth <Brendan@iab.net<mailto:Brendan@iab.net>>, Mike Zaneis <mike@iab.net<mailto:mike@iab.net>>, Brian O'Kelley <bokelley@appnexus.com<mailto:bokelley@appnexus.com>>
Subject: Re: Frequency Capping


Frequency capping (f-capping) is usually a contractual obligation for the party responsible for delivering the ad (an ad-netork, a publisher, and exchange, etc.) and is almost always required by the advertiser in insertion orders (the insertion order or "IO" is the contract between the parties).  It looks like your assumption below is that f-capping is (only) a 'tactic' to increase ROI for performance campaigns.  While this is sometimes true (yet mostly not), it's actually rarely the real motivation of doing f-capping.  The requirement for f-capping the delivery of a campaign to users is generally contractually obligated by the advertiser, for several good reasons, but most importantly for not annoying the user with multiple servings of the same ad creative, over and over again in one time frame (i.e. in a 24-hour time period).

As f-capping is generally contractually obligated, it's not up to the deliverer of the ad to CHOOSE which campaigns to f-cap— it's a REQUIREMENT to f-cap all campaigns where contractually obligated to do so.  F-capping has happened in television advertising for many years— imagine how annoying it is when the same tv ad spot plays over and over again (in fact this happens, and I'm sure we all find it annoying).

To sum up, while f-capping can sometimes increase ROI for advertisers (it's not necessarily always true), it is most often contractually obligated (per the Insertion Order).  The primary motivation for f-capping is to not annoy the user with repeated serving of the same ad creative during a time period.  In my experience, the vast majority of f-capping is  set at 1:24 or 2:24, etc. (restricting the showing of a particular ad creative, 1 time in 24-hours, or 2-times in 24-hours).

I hope this helps clarify the motivation for f-capping and leads to mutual appreciation for the need.

Kind Regards,


Chris Mejia | Digital Supply Chain Solutions | Ad Technology Group | Interactive Advertising Bureau - IAB

From: Jonathan Mayer <jmayer@stanford.edu<mailto:jmayer@stanford.edu>>
Date: Tue, 10 Jul 2012 14:26:12 -0700
To: David Wainberg - NAI <david@networkadvertising.org<mailto:david@networkadvertising.org>>
Cc: W3C DNT Working Group Mailing List <public-tracking@w3.org<mailto:public-tracking@w3.org>>
Subject: Re: Frequency Capping
Resent-From: W3C DNT Working Group Mailing List <public-tracking@w3.org<mailto:public-tracking@w3.org>>
Resent-Date: Tue, 10 Jul 2012 21:26:46 +0000

I'd sure like to hear more from advertising industry participants about how frequency capping integrates into advertisement selection.  The AppNexus approach, if I read correctly, goes roughly as follows:

1) Begin with the set of all campaigns.

2) Filter by targeting criteria.

3) Filter by frequency capping.

4) Assign an expected revenue to each campaign.

5) Select the campaign with greatest expected revenue.

The approach includes testing the frequency cap of every campaign that matches targeting criteria.  What about, instead, only testing the cap for a subset of those campaigns:

1) Begin with the set of all campaigns.

2) Filter by targeting criteria.

3) Assign an expected revenue to each campaign.

4) Select the n campaigns with greatest expected revenue.

5) Filter by frequency capping.

6) Select the campaign with greatest expected revenue.

Some relevant empirical questions include: How often are the highest revenue campaigns frequency capped?  How well can an ad company predict which high-revenue campaigns will and won't be frequency capped?


On Monday, July 9, 2012 at 11:34 AM, David Wainberg wrote:

Hi All,

In case you haven't seen it already, I recommend Prof. Felten's excellent blog on "Privacy by Design: Frequency Capping." Please also read Brian O'Kelley's post in the comment section explaining what he sees as the technical hurdles for these alternative frequency capping methods. (I may be wrong, but I think Brian is a former student of Prof. Felten.) This kind of detailed technical discussion of these proposals seems very helpful. First, it helps us set reasonable expectations on all sides. Second, and more interesting to me, is that maybe we can have more discussion and collaboration on bringing these sorts of things to production.


Received on Monday, 16 July 2012 05:28:20 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:44:53 UTC