Architecture

1.Terminology

Data Management Platform (DMP) – is a system used by digital advertising buyers and publishers to store and manage audience data.

Demand-Side Platform (DSP) – is a system that allows buyers of digital advertising inventory to manage multiple ad exchanges and data exchange accounts through one interface.

Data Audience Platform (DAP) – is a DMP that collects segmented audience profile data in the Blockchain and identifies segments for the DSP.

AD Exchange (EX) – is a sales channel between DSP’s and SSP’s. This is a technology platform that facilitates automated auction-based pricing and buying in real-time.

EX-Pixel – is a tracking pixel that is loaded when a user visits a website and is used by AD Exchange to identify visitor ad place on web page.

EX-User-ID – is a unique parameter that is generated by the AD Exchange for each visitor.

EX-Name – is a unique parameter that identify AD Exchange.

Pixel-ID – is a unique user identification hash that is generated by DAP for each user.

Cookie-Syncing – is a process that do mapping user cookies from AD Exchange to DAP.

2.Data Audience Platform (DAP) Structure

DAP contains main structural modules:

  • Data Management Platform (DMP)
  • Blockchain (Hyperledger)
  • Data Choice Token – DCT (Ethereum ERC20)
  • Cookie-Syncing (Mapping cookies)

2.1. Data Management Platform (DMP)

DMP provides a web interface for users and API communication channels for the Demand- Side Platforms and Cookie Syncing. DMP works with anonymized user data that is stored in the blockchain network.

DMP communicates with:

  • Users: DMP provides a Web Application where the users can register and enter their profile data. DMP generates a main unique identifier for each user: Pixel-ID.

DMP stores Pixel-ID in user browser cookies

  • KYC provider: DMP sends requests to the KYC provider for user data verification
  • Blockchain: DMP stores anonymized user data into Blockchain for each Pixel-ID. DMP can get segments for the Pixel-ID’s from blockchain. Please see segmentation process description below in the section “Blockchain”.
  • Cookie-Syncing: DMP gets requests from Cookie-Syncing. Cookie-Syncing does mapping user cookies and sends Pixel-ID, EX-User-ID, EX-Name to the DMP. Please see more details below in section “Cookie Syncing”.
  • DSP’s: DMP provides segment collections to the DSP’s. DMP gets requests from DSP’s about segment relations for user (EX-User-ID / EX-Name). DMP gets the request data (EX-User-ID, EX-Name, Segment) from DSP. DMP analyses and compares DSP request with the stored Pixel-ID data. DMP returns YES if the user relates to a Segment. DMP returns NO if user doesn’t relate to a Segment. Please see more details below in section “Description DAP process”
DMP consists of:
  • Client Side (Web Application):
    1. Sign Up + Sign In + Sign Out
    2. User Data Wizard
  • Server Side:
  1. Client API – for server communication with Client Side
  2. Cookie-Syncing API – for communication with Cookie-Syncing
  3. DSP API – for communication with Demand-Side Platforms
  4. Local database – for storing Pixel-ID, EX-User-ID, EX-N
2.2. Blockchain

Segmented user data is stored on to the Blockchain network. The list of segments is predefined and preloaded into the blockchain network. Blockchain communicates with the DMP only. Only the DMP has access to this blockchain. Blockchain is a private network and allows joining new nodes upon admin approval. We recommend using HYPERLEDGER as the Blockchain solution.

Hyperledger Fabric allows creation of permissioned blockchain with high performance that achieves 3500 TPS (transactions per second). Hyperledger is supported by IBM, American Express, Baidu, Intel, J.P Morgan, etc. – We are also in discussions over another blockchain solution to allow a higher transactions per second.

2.3. Cookie Syncing

Cookie syncing is a process that maps user cookies from AD Exchange to the DAP.

DAP has a special Cookie-Syncing script that do cookie syncing: Pixel-ID, EX-User-ID and EX-Name.

Cookie syncing step-by-step:

  • DMP provides “Cookie-Syncing URL” through DSP to the AD
  • User visits a website that contains an
  • Browser sends a pixel request through SSP to AD
  • AD Exchange sends back EX Pixel and creates an EX-User-ID cookie. User visits a website that contains an ad
  • Ad Exchange redirects the request to the “Cookie-Syncing URL” on the DAP’s side, passing EX-User-ID, EX-Name in the URL
  • Cookie-Syncing reads user Pixel-ID cookie and reads EX-User-ID, EX-Name passed from the AD Exchange.
  • Cookie-Syncing sends request with mapped user cookies to the DMP: Pixel-ID, EX-User-ID, EX-Name
  • DMP stores request data to fast local database as relation: (EX-Name, EX-User-ID) => Pixel-ID.

One unique Pixel-ID can be related to many unique keys (EX-Name, EX-User-ID)

2.1.   Data Choice Token – DCT

Users get Data Choice Token – DCT when:

  • Add user data
  • Update user data
  • Take part in surveys

We are creating the following:

  • Ethereum Smart Contract: ERC20 Token
  • Ethereum Smart Contract: ICO
3.   Description – DAP process
3.1.   User submits registration form using DMP web interface

User becomes registered user after submitting registration/login form. User should use Email

+ Password or Google OAuth account.

3.2.   User submits user data using DMP wizard

Registered user fills data inputs step by step in DMP wizard. Data input collections are configurable by administrator.

3.3.   DMP generates unique Pixel-ID and stores user data in Blockchain

All user data stored in blockchain with relations Segment -> Pixel-ID’s.

3.4.   Data verification

DMP verifies user data using KYC provider.

3.1.   User gets Data Choice Tokens

User gets Data Choice Tokens, when Data verification is completed. DMP sends request to Ethereum Data Choice Smart Contract to send some quantity of tokens to user. This quantity of tokens depends on quantity and quality submitted user data.

3.2.   User gets Pixel-ID to browser cookies

DMP sets Pixel-ID to user’s browser cookies in current browser. DMP sends email/SMS with magic link to user. User opens magic link in all devices/browsers. User gets Pixel-ID to cookies for all devices/browser.

DMP updates lifetime Pixel-ID in cookies each time user visits DMP. DMP updates lifetime Pixel-ID in cookies each time DAP pixel is fired.

DMP stores all information about user devices/browsers. DMP does monitoring user devices/browsers activities (using Cookie-Syncing). If user stops using some device/browser, DMP sends email/SMS with magic link for restoring Pixel-ID cookies

3.3.   User opens some website page in browser

EX Pixels are fired by AD Exchanges on each page that opened in browser. Number of EX Pixels on one page depends on number of ad places.

3.4.   Cookie-Syncing process for each AD Exchange

AD Exchange starts Cookie-Syncing process. Cookie-Syncing script gets EX-Name, EX- User-ID from AD Exchange and gets Pixel-ID from user browser cookies.

Please see more details in section “Cookie Syncing”.

3.5.   Cookie-Syncing sends data to DMP

Cookie-Syncing script sends syncing data (EX-Name, EX-User-ID, Pixel-ID) to DMP.

3.6.       DMP stores Cookie-Syncing data in local database

DMP gets sync data (EX-Name, EX-User-ID, Pixel-ID). DMP stores this data in fast local database with the relations (EX-Name, EX-User-ID) => Pixel ID.

One unique Pixel-ID can be related to many unique keys (EX-Name, EX-User-ID)

DMP waits when DSP asks about ad place with such parameters: (EX-Name, EX-User-ID)

3.11.       DMP gets request from DSP about ad place segment information. DMP sends response to DSP

DMP gets DSP request about ad place with parameters (EX-Name, EX-User-ID, Segment):

  • DMP finds Pixel-ID with such parameters (EX-Name, EX-User-ID) in local
  • DMP identifies that (EX-Name, EX-User-ID) relates to Pixel-ID.
  • DMP compares requested DSP Segment with Pixel-ID segments in

DMP sends response to DSP:

  • YES: if Pixel-ID relates to DSP
  • NO: if Pixel-ID doesn’t relate to DSP
Privacy Policy Cookie Policy