Before starting

Each vendor solution identifies browsers via a proprietary COOKIE_ID. This prevents them from sharing user data with other solutions directly. The cookie synchronization allows vendors to share their Unique Identifiers with the Commanders Act CDP.

Commanders Act sends a request to the vendor server to get their COOKIE_ID for a user and then stores the mapping on the Commanders Act servers. Cookie synchronization maps different IDs together and thus enables user data to be shared.

Requirements

• Web service URL: The vendor solution provides Commanders Act with the URL to be called to trigger the webservice and get its COOKIE_ID for the current browser

• Commanders Act Token: Commanders Act provides the vendor with a 32-character unique ID (ex: KD04a85DjH1015yzuAu7pnaoTh5P53iL). This token will be used to send request to the Commanders Act web service.

Process

1) Commanders Act sends a request to the vendor's web service through its JavaScript tag (browser side).

302 redirect URL example
https://tagcommander.sync.partner.com/commanders-act

2) The vendor API sends its COOKIE_ID to http://sync.commander1.com/#PARTNER_TOKEN#/#UID# by replacing on the fly the #UID# in the destination URL. The #TOKEN# is provided by Commanders Act and unique per vendor.

Commanders Act call example
http://sync.commander1.com/KD04a85DjH1015yzuAu7pnaoTh5P53iL/831483791534

3) Commanders Act stores the vendor COOKIE_ID into its cookie sync mapping table. This database keep an history of Commanders Act unique ID & every synchronized vendor COOKIE_ID(s).

4) End users can create segments from DataCommander UI. The COOKIE_IDs will be translated into the vendor's one when extracting the data, so the vendor will be able to re-use them.