Re: TPE Handling Out-of-Band Consent (including ISSUE-152)

Regarding our panel sizes, I can't disclose anything that isn't publicly
posted, but here is some public-facing info:

"""
In the U.S., Nielsen’s online panel measures the activity of more than
200,000 Internet users across more than 30,000 sites, and extends to more
than 500,000 panelists worldwide.

http://www.nielsen.com/us/en/nielsen-solutions/nielsen-measurement/nielsen-online-measurement.html
"""

Having multiple research projects (with independent panels) collecting on
the same platforms complicates things further.  The distributed server
resources cannot perform those kinds of lookups (or even much smaller
lookups) within the round-trip time that is required (contractually, in
some cases) to avoid destroying the users' experience, and to measure
accurately.  Also, as I have tried to explain before (perhaps poorly), the
information necessary to determine if someone is a panelist (e.g. IP
address, recently-assigned cookies, etc.) may not have been collected back
into the backend systems until after the web browsing to be measured has
already occurred.

If anyone has some really great performance-engineering tips, I'm always
looking to learn new things (especially if they have solved the sticky
problem of time-travel), but in my experience these are insurmountable
technical obstacles to real-time OOBC determination for Internet-scale
research.

--ronan


On Mon, Mar 25, 2013 at 1:55 PM, Dan Auerbach <dan@eff.org> wrote:

>  Hi Ronan,
>
> I'm unclear as to why you can't periodically push the OOBC users to the
> front-end servers, enabling a fast lookup. How many OOBC users do you have?
> Can you discuss details of how the front-end server and logging pipelines
> each work? We certainly don't want to ask something that's impossible, but
> on the flip side, it is reasonable to expect some amount of re-engineering
> to comply with DNT. To figure out which situation we are in, providing more
> details would be necessary. I also agree with others that using in-band
> mechanisms seems like a good solution.
>
> Cheers,
> Dan
>
>