Re: issue-25

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 <http://cloudclinic.com/HiImDory> [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 <http://cloudclinic.com/HiImDory>
>>
>