INFORMATION TRUST EXCHANGE WORKING PAPERS
Mapping ITEGA relationships
(Initial author: Bill Densmore March 2, 2016,
insight from Rick Lerner,
rewriting, additions, analysis from Don Marti)
This document outlines relationships among key participants in an ITEGA ecosystem -- users, publishers, advertiser and the network services.
The core approach: Publishers create an Audience Profile Book (APB) of anonymous attributes of their users, which is shared with an ITE sharing infrastructure, not unlike a cloud service such as DropBox, or Firefox Sync. The ITE can then work with member ad networks and agencies to provide access to cohorts of like-interest users across parts or all of the ITE -- sorted by interests or geography.
Adverts get passed through to users via the ITE, so the advertiser/agency doesn't know individual users, but is assured of delivery to real people who are contained within one or more interest cohorts. Logged reports of ad views come from the ITE as a trusted third party; these two aspects should reduce most fraud and make higher CPMs more defensible. Also, since the process of collecting and collating user attributes into APB cohorts happens at the network level, it eliminates the need for third-party cookies on user machines -- eliminating privacy compromises and sluggish end-user browser behavior. The publisher is responsible for seeing that ads contracted for delivery to a particular cohort (of which the publisher’s APB has a piece) actually are viewed by the publisher’s users within that cohort. Thus only the publisher has to “know” the digital address of a unique user.
The ITE knows individual users by a unique ID provided by the user's home-base publisher (this is necessary to be able to bill ads (and, futurely content views or subscriptions), but does not have any way of mapping that unique ID to a real person at the home-base publisher level. Again, only the publisher can do that.
The architecture is designed so that user "persona" data is managed by individual publishers, or a collaborating group of publishers (such as Pangaea) in a first-party relationship with their users/subscribers, but that data can be shared on a session basis -- with a user ID that persists for at least a week or longer with advertisers and agencies able to use it as part of real-time-bidding (RTB) processes. The user data would be stored temporarily at a ITE Data Aggregator (potentially Mozilla in alpha) or ITE-contracted data-service provider (DSP) to whom all advertisers/agencies/networks/exchanges would make calls for the data as they are engaged in RTB. In this way the network would not be relying on the reliability of thousands of publisher's servers for real-time user-data services; it would be dependent on one, or perhaps a few, providers of user identity data.
So this should allow publishers to repudiate networks that set third-party cookies on their user's machines and offer this higher-quality alternative. This will also allow users to implement privacy-protection technologies on the browser or device, without interfering with the operation of high-quality advertising gatewayed through first parties -- such as this describes.
Here are some steps in the system operation as planned:
B. ESTABLISHING PERSONA
C. VISITING THIRD-PARTY SERVICES -- NON-ADVERTISING
For a more detailed description of how ITE advertising exchange services will work, see the WORKING document:
-- a method for assembling web-service user demographics and interests in anonymous cohorts
File: Mapping ITE relationships-overview