Re: issue-25

? The ad contract is pretty specific:  7-times frequency cap on each 
creative and a 14-times frequency cap on the whole (6 creative) 
campaign, on a 6-month campaign

That example sounds like a set of performance indicator for individual 
ads delivered to unique browsers, across sites and time.

Rob


Ronan Heffernan schreef op 2013-07-22 14:17:
> This reporting is content-centric, being about the ads and campaigns,
> not about the users, and the reporting would be solely statistical.
>  The report might be a set of counts as to how many users from each
> country saw each ad once, how many saw it twice, etc.  These are only
> counts. No profiles are built about users. No information about users,
> devices, history, etc. is included in and reports or shared with
> advertisers. No user experiences are altered.  
> 
> --ronan
> 
> On Monday, July 22, 2013, Rob van Eijk wrote:
> 
> Ronan,
> 
> You wrote:
> 
> If the ad contract calls for a 7-times frequency cap on each creative 
> and a 14-times frequency cap on the whole (6 creative) campaign, on a 
> 6-month campaign, then the advertiser wants independent verification 
> that that clause was honored. That requires having counts per device, 
> not just "Hey, I think you're new."
> 
> Sounds to me, that the ad contract is user centric, requiring having 
> counts per user impression. The justification for audience measurement 
> has been to allow for calibration.
> The idea of having a unique identifier across sites with the 
> contractual clause you refer to, I fail to see the statistical analysis 
> that the text proposal is based upon.
> 
> Exerpt from the audience meaurement text proposal:
> 
> Audience measurement research creates statistical measures of the reach 
> in relation to the total online population, and frequency of exposure 
> of the content to the online audience, including paid components of web 
> pages.
> 
> Rob
> 
> Ronan Heffernan schreef op 2013-07-22 13:18:
> 
> Mike,
>    There can't be a Last-Modified header except for objects that the
> browser has cached.  If we disable the mechanisms that prevent caching
> (e.g. cache-buster parms), then proxies (corporate, ISP, etc.) will be
> able to serve the pixels.  You are also depending on the browsers to
> still have that object in their cache, otherwise we will be counting
> the user multiple times.  This also has to work with mobile browsers
> and embedded user agents, which may have tiny caches (or no cache),
> and which often have unusual behavior around LastModified, ETag,
> and/or caches surviving a power-cycle.
> 
>    This mechanism also only works if the pixel has the exact same
> URL.  That means that you can't point to the same pixel from multiple
> ad networks or ad servers with different macro values (yes, this is
> done today and will be required going forward), and you can't use both
> HTTP and HTTPS.  You also can't provide unique counts for a campaign
> and a creative, since you will only be able to pass one of those IDs
> or the other without getting multiple over-counts.
> 
>    One of the services that this kind of measurement provides is a
> double-check that frequency-capping rules are working.  This service
> requires knowing how many times each device was exposed to an ad
> and/or campaign.  If the ad contract calls for a 7-times frequency cap
> on each creative and a 14-times frequency cap on the whole (6
> creative) campaign, on a 6-month campaign, then the advertiser wants
> independent verification that that clause was honored.  That requires
> having counts per device, not just "Hey, I think you're new."
> 
>    This is an interesting idea, and if industry can find ways to
> work-around the problems, and can prove that this mechanism works
> better, then you can expect that they will.  Until that is able to
> happen, there is no way to sign-off on such an unproven mechanism,
> especially in light of the apparent problems.
> 
> --ronan
> 
>  
> 
> On Mon, Jul 22, 2013 at 4:20 AM, Mike O'Neill
> <michael.oneill@baycloud.com> wrote:
> 
> Ronan,
> 
>  
> 
> You keep your own counts for ad impressions, they would not need to be 
> held in the browser, and it is up to the server how caching is 
> implemented.  The ETag counts would be useful for frequency capping, 
> though you may not need to do that.
> 
>  
> 
> Here is a demo of unique visitor detection (and low-entropy user-agent 
> specific counting) using cache headers I have knocked together. There 
> is no sharing/use of persistent unique identifiers, and no cookies.
> 
>  
> 
> A new visit is communicated to the server by letting it know the time 
> of the previous visit so the server can update its aggregated counts. 
> There is no need to communicate a unique identifier so the individual 
> cannot be tracked.
> 
>  
> 
> http://cloudclinic.com/HiImDory [1] [1]
> 
>  
> 
> The duration between unique visits is set to 10 seconds to keep it 
> simple, but of course it could be any length of time.
> 
>  
> 
>  
> 
> Mike
> 
>  
> 
>  
> 
> FROM: Ronan Heffernan [mailto:ronansan@gmail.com]
> SENT: 19 July 2013 22:02
> TO: Mike O'Neill; Tracking Protection Working Group WG
> SUBJECT: Re: issue-25
> 
>  
> 
> Mike,
> 
> Having the top-level page in the URL parameters means that the 
> incrementing ETag won't be incremented if the same ad is seen across 
> sites, since the browsers will cache a separate copy for each site 
> (since nearly all caching is URL-based)?  BTW, we also issue a no-cache 
> header, and add a cache-busting parameter, to keep the browsers and 
> intermediate proxies from supplying the pixels out of cache.  These are 
> standard practices.  That means that the browsers should not be caching 
> the pixels or the current ETag value, so there will be no value for the 
> webservers to increment.
> 
> If you are right that these techniques offer a superior way to function 
> in an environment that involves 3rd-party cookie blocking, then 
> industry will adopt them even with the audience measurement permitted 
> use exception.  However, they do not seem to provide the functionality 
> that we need.
> 
> --ronan
> 
>  
> 
>  
> 
> On Fri, Jul 19, 2013 at 3:45 PM, Mike O'Neill 
> <michael.oneill@baycloud.com> wrote:
> 
> Hi Ronan,
> 
>  
> 
> If you read my first example I had a third-party element addressed via 
> a URI containing the first-party page in a query parameter, so making 
> the exchange top level page specific. It is not very complicated and it 
> works.
> 
>  
> 
> In addition to being DNT compliant it also avoids the default 
> third-party cookie blocks which are becoming very common.
> 
>  
> 
> Mike
> 
>  
> 
>  
> 
> FROM: Ronan Heffernan [mailto:ronansan@gmail.com]
> SENT: 19 July 2013 20:02
> 
> TO: Mike O'Neill
> CC: Tracking Protection Working Group WG
> SUBJECT: Re: issue-25
> 
>  
> 
> Mike,
> 
>    I call this improper because ETags already have a purpose and 
> semantics.  If I understand you correctly, we would have to use the 
> exact same URL, so that the browser would use the ETag value that it 
> cached.  This means that we could no longer use "cache-busting" 
> parameters, which means that intermediary proxies could serve the 
> content, which destroys audience measurement.  I understand the desire 
> for really complicated, unproven, solutions, but none of the ones that 
> I have heard so far seem likely to work.  We have a solution that 
> works, and is well proven.
> 
> --ronan
>  
> 
>  
> 
> On Fri, Jul 19, 2013 at 12:30 PM, Mike O'Neill 
> <michael.oneill@baycloud.com> wrote:
> 
> Hi Ronan,
> 
>  
> 
> No, not a unique identifier, which I agree would diminish privacy and 
> should be ruled out along with any other tracking identifier collection 
> when DNT is 1. What I meant was a count value (number of ad 
> impressions) which I assume would have limited entropy i.e. the max 
> value would be << the number of online individuals in scope. How many 
> ad impressions would you need to count? I agree relying on the cache 
> for 6 months would be a stretch, but do you need to do that? At some 
> point there may be some loss of functionality when DNT is 1 but the 
> setting is an important indication of user intent so needs to be 
> honoured.
> 
>  
> 
> How an ETag is generated in not specified in the HTTP spec, so in what 
> way would this be “improper”?
> 
>  
> 
>  
> 
> Mike
> 
> .
> 
>  
> 
>  
> 
>  
> 
> Links:
> ------
> [1] http://cloudclinic.com/HiImDory [1]
> 
> 
> Links:
> ------
> [1] http://cloudclinic.com/HiImDory

Received on Monday, 22 July 2013 12:27:41 UTC