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.
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.
302 redirect URL examplehttps://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 examplehttp://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.