RE: An alternative to site-specific user granted exceptions (Issue-111)

The Ad Chaining scenario is really complicated when thinking of 3rd party management. Ad Exchanges and Real Time Ad Platforms complicate this because of the different dynamic interactions that occur with the various ad platforms that vie for the impression opportunity. Couple that with '4th party' scenarios around tracking engagement and analytics within the ad that is eventually served to the user-agent - in my opinion, listing out all 3rd parties in a static list is prohibitive - it literally could be hundreds as you suggest.

I do think '4th party' scenarios are important to consider in more depth, advertisers have a need to understand how successful their creative is in engaging the user, they also enlist the help of other analytics platforms for accounting and validation purposes.

-----Original Message-----
From: TOUBIANA, VINCENT (VINCENT) [mailto:Vincent.Toubiana@alcatel-lucent.com] 
Sent: Wednesday, April 25, 2012 8:02 AM
To: Kevin Smith; public-tracking@w3.org
Subject: RE: An alternative to site-specific user granted exceptions (Issue-111)

Kevin,

I thought that it would help to solve the ad chain issue because the 1st party does not have to know the chain that would be generated dynamically, it could just generate a static list of all the potential third parties that could be called.
Do you have an estimation of how many third parties would have to be listed in that case? If its one or two dozens, that could work, if its hundreds then it might not make sense.

Maybe knowing the root of the chain might be enough (that could also work for explicit/explicit user granted exceptions).

Thank you,

Vincent
________________________________________
From: Kevin Smith [kevsmith@adobe.com]
Sent: Friday, April 20, 2012 6:03 PM
To: TOUBIANA, VINCENT (VINCENT); public-tracking@w3.org
Subject: RE: An alternative to site-specific user granted exceptions (Issue-111)

I like this suggestion.  I have expressed many times that I believe passing in 3rd parties into the specific javascript calls will only work in the very simplest of cases.  I think this will extend the usefulness of the JS API because it is much more scalable to manage your list of 3rd parties in a single location than on a per page per JS request basis.  In practice, if I were forced to use the JS API as is, I would probably mimic this behavior using centralized global JS variables to represent the 3rd party groups.  However, this approach would be much cleaner.

However, I do not understand how it solves the ad chain problem.  If the 1st party does not know who is in the ad chain, and the ad chain is dynamic, then it cannot put the 3rd parties in this doc any more easily than it could put them directly in the JS call.

-----Original Message-----
From: TOUBIANA, VINCENT (VINCENT) [mailto:Vincent.Toubiana@alcatel-lucent.com]
Sent: Tuesday, April 17, 2012 12:04 PM
To: public-tracking@w3.org
Subject: An alternative to site-specific user granted exceptions (Issue-111)


I suggest an alternative to site-specific exceptions (Issue-111). Instead of providing the list of 3rd parties through the JavaScript API, this list could be provided through Tracking Status Representation (available through the well-known URI).
There is already a field to send that list to the UA (See section 5.1.2 in TPE document) but it is currently optional. If we replace the MAY by a MUST, then users could get the list of third parties present on a site before they visit it and then decide if they are ready to grant a site-wide exception.

Pros:
-       User grant exceptions knowing which third parties could track them
-       This does not broke the chain in ad-exchanges
-       Publisher do not have to ask new user granted exceptions when they add third parties
Cons:
-       Users have to check the well known URI more often
-       Users can not provide feedback about the third parties present on a website (a non granted exception is - in my opinion-- an explicit feedback).

I still prefer the site-specific exception mechanism as it gives users more choices, but I believe this solution could be seen as a middle ground.

Vincent

Received on Friday, 27 April 2012 10:32:26 UTC