RE: A First-Party List API for Site-Specific Exceptions (ISSUE-59, ISSUE-109, ISSUE-111, ISSUE-113, ISSUE-114)

They do not need to know the exact amount of revenue a pageview can bring (I don't believe I ever said that) - rather, they need to know to what degree they will be able to monetize the visitor - on in other words to what degree the3rd parties they employ on their site will be able to perform the function for which they were included.

This seems very straightforward - the entire reason for even having exceptions is that some sites will not be willing to show the same content to those for whom their 3rd parties will not function.  (ie they will not give away content for free to those they cannot monetize - this is just one example - but probably one of the most common).  If this were not so - if users had the same experience and received the same content, there would be no incentive for them to grant an exception.  This implies that the site will serve different content to visitors who send a DNT:1 header to the site's 3rd parties, than to those who send a DNT:0.  In order to decide what content to show, the site therefore needs to know ahead of time what signal its 3rd parties will receive.  Otherwise, it will have already rendered all of its contents before it knows what contents to serve up.  In other words, polling would prevent the primary (if not only) function that exceptions are intended to provide.

Aside from that - even if it worked for the 1st party, I have explained on other threads that it will not work for the 3rd parties themselves.  Polling implies that you send a 'light' request to a 3rd party asking at least the following 2 questions - 1) how will you respond to the DNT signal you receive on this request and 2) which additional 3rd parties will you include or redirect to.  Question #1 is fairly easy.  Question #2 cannot be answered from a 'light' request.  Many nodes in the chain determine the next node based on what it knows about the user.  A guy who likes motorcycles may have a completely different ad chain than a guy who likes pianos.


-----Original Message-----
From: Jonathan Mayer [mailto:jmayer@stanford.edu] 
Sent: Saturday, March 17, 2012 9:47 PM
To: Kevin Smith
Cc: Sid Stamm; Tracking Protection Working Group WG
Subject: Re: A First-Party List API for Site-Specific Exceptions (ISSUE-59, ISSUE-109, ISSUE-111, ISSUE-113, ISSUE-114)

A clarifying note on that second paragraph - a publisher may well care about DNT settings that reduce the revenue it can expect, on average, from a user (e.g. if the user has DNT enabled for behavioral ad companies that generate most of the publisher's revenue).  That's a very different (and much easier) analysis than determining how much revenue a specific page load will bring.

Jonathan

On Mar 17, 2012, at 8:36 PM, Jonathan Mayer wrote:

> A polling approach and a list approach converge when the space of potential third parties is known.  There are performance and privacy tradeoffs involved, but the same information could be available.
> 
> I'm not sure why you think a first-party publisher needs to know, in advance, the precise third-party ad revenue it will make from a specific visitor loading a specific page.  Publishers almost always don't know that now, and it's not a problem.  Moreover, I can't imagine a publisher ever would say, "Sorry, we couldn't find ad partners just now willing to pay enough, so we're not going to show you this page."  But even if publishers did need per-visit predictions of revenue, I don't see how DNT would complicate delivering that functionality in an ad network, ad exchange, series of ad companies, or any other market configuration.
> 
> Jonathan
> 
> On Mar 15, 2012, at 9:18 AM, Kevin Smith wrote:
> 
>> ** I still maintain that polling is a completely unacceptable approach because
>> 1) The first party has to wait until the all of the ads and redirects and 3rd parties have returned (or returned their status which wont work either) before they know what to do.  This is too late.  The first party needs to know on the initial request.

>> 
>> 2) It just won't work.  The ad chains are dynamic.  Each step uses business logic to determine the next step.  You cannot ping the next step in the chain and say 'what is your DNT status and who is the next service on the list'.  It does not work that way.  These services have to have all of the information they will get in a normal request to process it and determine the next service in line.  So again a) you cannot get the list to ask for exceptions, b) that list may change per ad so you would always be popping up new exception requests, and c) again you would have to wait for the chain to return before you knew who was in the chain and how they would react to a DNT status.
> 
>

Received on Friday, 23 March 2012 16:43:04 UTC