Re: ISSUE-111 - Exceptions are broken

Kevin, 

1/ your issue comes in part because of the bundling and because the first 
party gets a clustered exception for the third parties. In web architecture, 
you typically get into those situations when bundling things together and 
restricting people in how they use the web. That's why I don't like Roy's URI 
proposal and like headers better.

The issue also comes from an unlucky assumption that the first party controls 
the third parties it is using. This is only the case for the outsourcing 
scenario.

So normally, I would say that a first party asking for an exception for a 
third party it doesn't control (non-outsourcing partners) is a break in the 
system. Third parties would have to ask for an exception all by themselves. 
They may notify the first party if they get none. But this came up already as 
a suggestion.

2/ This is a serious weakness in the opt-back-in or exception mechanism. 
Because it should be easy for the third parties to at least ask for 
permission. Again, my main issue is to get from DNT=unset to DNT=0. 

3/ As Vincent has pointed out, this will also change the dynamics in the 
market (hopefully). So far the more reckless you collected data, the better 
your economic success. Now imagine that a first party with valuable content 
will try to work with partners that are acceptable to users. So the reasonable 
companies get a chance. This is a very soft incentive for the industry to 
renovate their systems a bit into a more responsible data collection practice. 

4/ It is clear that if they do their own collections, B,X,Y and Z will receive 
their own DNT header and have to cope with it. So I think what you're missing 
is the feedback to the service on whether the services the first party uses 
are acceptable to its users. 

To answer the EU question, there every ad-actor would need their own right to 
collect data and build a profile, this means without consent for the actors, 
hard to say how they could collect the necessary data. Perhaps they are simply 
not dealing with personal data but only with categories and the userID is not 
transported, but only the category announced. But at the end of the day, the 
ad network that obtains the request and sends the ad will have to live with 
the header it receives. 

Does that help?

Rigo

On Thursday 08 March 2012 09:48:08 Kevin Smith wrote:
> I think folks in the advertising business could probably answer this a
> little better as my knowledge on the subject is more academic than from
> experience.  However, according to my understanding (and I can do some more
> internal research if we don't have anyone on the thread who can answer this
> better) - it really depends on each piece of the chain.  I believe each
> piece of the chain will have its own cookie for the user and will collect
> the information it needs to be able to fully monetize that individual user,
> which may be nothing whatsoever (as some parts of the chain are really just
> pass-throughs), or may be a sophisticated profile which it uses to decide
> how much to bid for the chance to show an ad to that user.  In general, I
> do not believe much data flows between the elements of the chain as the
> data that each piece has collected is essentially their competitive
> advantage, but I am confident that this is not a hard and fast rule.  Also,
> since each stop in the chain is trying to maximize their ability to
> monetize the user, they will each have their own algorithms to determine
> the next step in the chain.  (For example, once the request gets to
> ad-service B, according to what it knows about the user, it may send the
> request to auction service C, or C' etc).  I think in general, most of the
> information each step uses is information that they have collected
> themselves, or retrieved from a DMP or similar service.
> 
> In your EU example, do services C and D get all the information they need to
> make a decision from the previous step in the chain, and then discard it
> after the transaction is complete?  There could be some chains that work
> this way, but in reality I believe they are vastly more complex than either
> of us have represented them.  For instance, I do not believe any service
> which performs real-time-bidding is going to rely on information passed
> from the ad-service to make its bid.  They are going to have their own way
> of validating the data.  If they cannot, they are going to bid very
> low.  This is why the entire chain needs to have the exception for any
> element of the chain to really work.  If the ad service has the exception,
> but none of the RTB services do, than they will all bid a minimum bid,
> which in turn means that the 1st party earns a very low CPM and the
> exception did not help them at all.
> 
> Also, in your example below, since exceptions (at least our site level
> exceptions) are tied to the 1st party, B would only be able to record your
> visits to X,Y,and Z if those 1st parties had also been granted exceptions.
> 
> Also note, this is just the advertising chain.  I am guessing there may be
> similar chains for other types of 3rd party services.

Received on Thursday, 8 March 2012 22:04:22 UTC