Cookie Synching

By

Editor’s note: This article was originally posted on the Krux Digital Blog.
Overview

Cookies are the primary mechanism by which publishers, advertisers, ad networks, ad exchanges, demand side platforms and data exchanges store and track information about users.

Cookies are domain specific — in other words, a Cookie set by domain foo.com cannot be read by a server from domain bar.com. This present a problem for server-to-server advertising protocols like RTB, where the bidders cannot read cookies set from their domain because they don’t have access to the user’s browser.

Cookie Synching refers to the process of mapping user Ids from one system to another.  The systems across which the user Ids are mapped could be Ad Networks, DSPs, Ad Exchanges or Data Providers.

Ad Exchanges and DSPs use Cookie-synching to enable the integration of Data Providers with their respective platforms so that all of their partners can benefit from the integration.

The basic underlying assumption with the Cookie-synching process is that all information sharing occurs via HTTP redirects, pixel URLs and cookies.  In order for system A to exchange user data with system B, the 2 systems need to have a common ID.  Since these are disparate systems and they also integrate with other systems, there is no notion of a common user ID.  Initiatives like GUID are a good first step towards solving this problem but until it is widely adopted, it is pretty safe to assume that 2 systems that want to integrate data at a user level cannot do so without some sort of mapping between the user IDs in the 2 systems.

The Cookie-synching process is a mechanism to build such a mapping.  Here is how it works:

  • System A (say an Ad Network) gets access to a user’s browser (as part of an Ad Serving request).  It creates a unique user ID for the user (if one does not already exists; if it does it will be there in the corresponding system A cookie on the user’s browser) and calls a pixel URL supplied by system B (say a Data Exchange or Data Provider).  System A includes the ID of the user as a parameter in the pixel URL call.
  • System B’s pixel URL server reads the ID of the user assigned by System A and creates an ID of it’s own for the user (if one does not already exist; if it does it will be there in the corresponding system B cookie on the user’s browser).  System B can now store the user mapping for this user in it’s database or in the user’s browser using another cookie.
  • A slight variation of this process involves System A storing the mapping also.  In this case, after system B generates it’s user ID, it redirects to a pixel URL supplied by system A and includes the system B user ID.

Use Cases

Re-targeting on Ad Exchanges

The first Cookie-Synching use case that we will explore involves an Advertiser (say Ford) that wants to use a Retargeting company (say Acme Retargeters) to deliver re-marketing messages to users who were on Ford’s website.  Acme Retargeters plans to use an Ad Exchange and RTB to get access to inventory.  In order to implement this retargeting system, Acme needs to match users who were on Ford’s website to the bid requests that it gets from the Ad Exchange.  In order to do so, it needs to do 2 things:

  1. Tag all pages on the Ford website in order to identify Ford users (this results in an Acme User ID cookie being set on the browser of every user who visits the Ford website).
  2. Implement Cookie Synching with the Ad Exchange to map Ad Exchange users to Ford users.

The complete sequence of steps is presented below:

  1. Acme and Ad Exchange implement Cookie Synching — Acme can map the Ad Exchange User ID in the bid request from the Ad Exchange to the Acme ID for the same user
  2. Ford tags all of their pages with Acme’s Pixel Tag (Javascript/IFrame/IMG)
  3. User visits the Ford website
  4. Acme’s tag code gets called and instructs the user’s browser (via a Redirect call) to fetch a 1×1 pixel image from Acme’s servers.  Acme sets a User ID cookie on the user’s browser marking the user as a “Ford User”.
  5. Acme gets a bid request from the Ad Exchange.  Using the Cookie-Synch map and its database of Ford users, it determines that the user is a “Ford User” and serves a Ford Re-marketing message to the user.

Ad Exchange – Data Exchange Partnership

A slightly more complicated use case for Cookie-Synching involves an Ad Exchange that uses RTB (Real-time Bidding) wanting to provide data from a Data Exchange to all bidders as part of the RTB Bid requests.  This does require the Bidders to sign an agreement with the Data Exchange but the bidders don’t need to do any technical integration with the Data Exchange in order to start seeing the appropriate user data in the bid requests sent to them.  The entire workflow is outlined below:

Cookie Synching Use Case 2

  1. User X visits a Data Provider website (say Expedia and searches for a ticket to NY).
  2. Data Exchange tag gets called and Data Exchange assigns an ID to the user (if one doesn’t already exist; if one does, it is read from the corresponding Cookie) and also assigns the user to the “NY Travel Intender” audience segment.
  3. The response to the Data Tag from the Data Exchange results in the following things:
    1. (3.1) Pixel URLs for all Buyers who won the data event auction (please see [[Data Exchange Overview]]).
    2. (3.2) A Pixel URL for the Ad Exchange which gets called by the user’s browser with the ID of the user as assigned by the Data Exchange as a URL parameter.
    3. (3.3) The Ad Exchange now gets access to the user’s browser and creates a User ID cookie of it’s own and stores the mapping between the Ad Exchange User ID and the Data Exchange User ID in persistent storage and/or in another cookie on the user’s browser.
    4. In addition to the above 3 real-time transactions, the Data Exchange also makes its user profile database available to the Ad Exchange.  This is done in 1 of 2 ways:
      1. A periodic snapshot of the database is provided by the Data Exchange to the Ad Exchange
      2. A real-time API is provided by the Data Exchange which can be called by the Ad Exchange during the Ad Call (see step 5 below).
  4. User X visits an Inventory Provider website (say CNN).  CNN uses the Ad Exchange to monetize its remnant inventory.
  5. The Ad Exchange’s Ad Tag gets called to serve an Ad to user X.  At this point, the Ad Exchange constructs a Bid Request and includes all the contextual information about the Ad Request (Ad Size, Content information, etc.) in the Bid Request.  The Ad Exchange also looks up the user profile information supplied by the Data Exchange (either through a real-time call to the Data Exchange or in the offline user profile database that is provided by the Data Exchange) and includes that in the bid request also.
  6. The Ad Exchange sends the Bid Request to all bidders using its RTB protocol.  It collects bids from all the bidders and picks the bidder with the highest bid as the winner — this was an Ad Network that was running a campaign for the Hudson River Tours company and the Ad Network used the Travel data included in the bid request to submit a high bid for the ad request.
  7. The Ad Network serves the Hudson River Tours company Ad to user X.

More Content You Might Enjoy: