Idea & Content picked from http://www.adopsinsider.com
Cookie-syncing is necessary because as a standard security process, web servers of any kind can only request cookies that are set to their own domain.
Since the SSP sits between the end-user and all the DSP bidders in a real-time auction however, the DSP needs a way to identify the users it is looking for.
In the example above, a client is integrating their analytics system, order management system, and email system to a DMP for the sake of selling some of their data on a data exchange and remarketing on the exchange through a DSP.
When the user (smiley face) lands on their site, they request the page HTML from the content server (1), which responds to the user with the page content, as well as the DMP’s container tag (2). While the rest of the page is loading, the container tag forces the browser to call the DMP (3), which responds back with a batch of redirects as well as its own cookie for the user (4) to each of the integration points. Those are basically pixel requests so the systems can drop a cookie on that user. The user makes those parallel requests (5), and receives the cookie, along with a callback to the DMP (6). That callback has each system’s unique ID on that user in the URL (ideally, encrypted), which the DMP receives and stores (7). Now the DMP has its own cookie ID (from step 4) synced with each 3rd party system. Now, the DMP can pull data from each system (8) and populate that data against its own cookie ID. The client can do any audience profiling and segmentation in the DMP, create the right cookie pool and move that cookie pool to other systems on demand, using server to server API connections.
Cookie-syncing is necessary because as a standard security process, web servers of any kind can only request cookies that are set to their own domain.
Since the SSP sits between the end-user and all the DSP bidders in a real-time auction however, the DSP needs a way to identify the users it is looking for.
When the user (smiley face) lands on their site, they request the page HTML from the content server (1), which responds to the user with the page content, as well as the DMP’s container tag (2). While the rest of the page is loading, the container tag forces the browser to call the DMP (3), which responds back with a batch of redirects as well as its own cookie for the user (4) to each of the integration points. Those are basically pixel requests so the systems can drop a cookie on that user. The user makes those parallel requests (5), and receives the cookie, along with a callback to the DMP (6). That callback has each system’s unique ID on that user in the URL (ideally, encrypted), which the DMP receives and stores (7). Now the DMP has its own cookie ID (from step 4) synced with each 3rd party system. Now, the DMP can pull data from each system (8) and populate that data against its own cookie ID. The client can do any audience profiling and segmentation in the DMP, create the right cookie pool and move that cookie pool to other systems on demand, using server to server API connections.
great, thanks!
ReplyDelete