THRON & Cookie Syncing – THRON HELP

Introduction

What is cookie syncing and which platforms are involved

One of the intrinsic characteristics of THRON is its ability to follow the entire visualization path of each user across all the touchpoints of the brand, allowing for a complete knowledge of its behavior, its interests and its positioning in the funnel instant by instant.

This characteristic is the more effective the greater the knowledge one has of the end user. Typically, within each organization there are different tools that collect, each on its behalf, information on the identities of end users.

The aim of this article is to explain how to achieve a synchronization between THRON and any system that collects identity information in order to create a mutual benefit. Historically, this action is commonly referred to as “Cookie Syncing” even in those cases where cookies are not technically involved in the process. Cookies are basically text strings that a server sends to a user's device while he is visiting a certain page. These text strings allow the device to "remind" the server of the user's browsing experience, and thus plan a personalized customer experience during subsequent visits.

Typically each system associates each device with a unique ID, which in addition to allowing you to identify every single user, allows different profiling software to exchange information.

Here are some examples of softwares that are able to exchange information through the cookie syncing methodology:

DMP (Data Management Platform): platforms which store and analyse data that will help you identifying your audience and creating segments to be targeted with relevant messages; a DMP is usually present when advertising content is managed and distributed. A DMP mixes first‑ and third‑party data from any source, organizing and synchronizing identities coming from 3^rd‑party apps. All this data, once categorized by the DMP itself, can be furtherly enriched and refined.
CDP (Customer Data Platform): platforms that collect first-party data, belonging to a specific company and coming from all of the brand’s touchpoints and data sources; their purpose is to tie these details to the actual unique user, collecting data regarding user’s behaviours, actions and interests coming from online or offline interactions, and making such data available to other software platforms.
CMS (Web Content Management System) or CRM/Marketing Automation platforms: platforms that collect customer surfing patterns and provide a rule-based engine to customize webpages according to such rules.

Why integrating THRON with such platforms

As already mentioned, one of the peculiar characteristics of THRON is to be able to follow the entire visualization path of all users, and to aggregate the path of the anonymous device with that of the profiled user, once he has made a call to action and then provided his identity. THRON enables these steps by its unique Content Intelligence framework.

The accurate analysis of the topics covered by the contents that the user has viewed, allows the Artificial Intelligence engines to create a very precise "snapshot" of this user, capable of representing instant by instant its real interests.

Once provided to the platforms mentioned above, this information can bring significant benefits to your entire marketing and sales strategy:

Measure content performance for the complete user journey, highlighting correlations between content and user actions: What happened to a user that clicked on a banner, after he landed on a landing-page? Did he complete a purchase? Did he subscribe? How?
THRON can answer those questions and provide the integration platform with detailed and up-to-date elements, while the integration platform can provide THRON with the profile data gathered from paid channels or from the corporate owned channels.

Improve segment management by adding THRON 1^st party data and fuel interest-based rules for segment definition: DMP audience segments are usually limited to socio‑demographic information and a general-purpose interest definition. By adding THRON data you can evolve segments by detailing business specific interests and other persona definition parameters. As per CDPs, since they already work on first‑party data, this integration will further refine the details on the contacts basing on the browsing habits and history for the specific contact.

Link 1^st and 3^rd party segmentation: THRON can help unify the details coming from the different sources, integrating and improving them to furtherly refine the knowledge on the segments and on the contacts in the integration platform.

Integration scopes

As already stated in the introduction of this article, the main goal of integration through cookie syncing is to create a consistent representation of contacts between the two platforms; it is therefore important to focus on the events that might change contact related data.

For each one of these events, an integration action might be required. The following list describes the cases to be considered; for a better understanding we will refer, from now on, to "devices" when talking about anonymous contacts which have not yet provided their identity, while "contacts" means those already profiled:

General browsing: every time a device is browsing on a webpage that is being tracked by both THRON and the integration platform (e.g. user landing on website after clicking on an ad banner, user browsing a page on the brand site)
Contact update on the integration platform: every time a device or contact’s identity/attribute is modified on the integration platform (e.g. by adding contact details on its administration tool, manually inserting details in the CMP console)
THRON contact update: every time a device or contact’s identity/attribute is modified in THRON (e.g. behaviour engine tagging contacts because of their content usage patterns)
CTA event: every time a contact accesses content or performs a call-to-action (custom event) during his/her session (e.g. adds product to cart, completes purchase, subscribes to newsletter)
Identity event: every time a contact provides an identity data during his/her session (e.g. login, logout or form submission)

How to perform the integration:

[dropdown:Case one: General browsing]

This step is a prerequisite to enable all the cases described before; the concept varies between the different platforms to be integrated.

The integration for all the platforms starts with the same main requirement, that is joining the identities between THRON and the platform itself,

Specific platform considerations

Cookie syncing and DMPs

The fundamental step for integrating a DMP and one advertising platform is the cookie syncing process; the very same process must be replicated between the integration platform and THRON.

Browser cookies are domain specific; this means that the ones created by one application cannot be read by another application (they are on different domains) thus leading the two applications to refer to the same contact with different “identities”, each mapped to a specific cookie.

One of the main duties of a DMP platform is precisely that of uniting the identities by performing a “syncing” on the browser cookies coming from the different platform. This syncing phase gathers all the IDs on the different systems and maps them to a global, specific ID on the DMP that will be used as a central reference to devices/contacts for management.

Customer Data Platforms

In the case of a CDP platform, this step is very similar (the main difference being that the CDP treats first-party data only); the task is to link the user identities between the CDP and THRON (by sharing the user identifier).

Other integrations

The approach described below is universal and can therefore be replicated in all other integration cases, with any type of platform, provided that it exposes APIs that can be invoked to obtain contact information. If this is not possible, please contact our technical support to evaluate your needs and check if we can point you at a certified partner who can follow you in the integration.

How to link the identities between THRON and the integration platform

To achieve this result, you will need to link the identity assigned to the contact by the integration platform to the one assigned by THRON via the following process:

Request THRON the ID assigned to the device and, if available, the related contact
Request the integration platform the ID assigned to the contact (usually done by reading the cookie or invoking the specific platform’s API method) and, if available, the related attributes
Check if a profiled contact with the same identities is already available in THRON, if so update it by adding the integration platform ID as identity key and the relevant attributes as tags
If a profiled contact doesn’t exist in THRON yet, create a new THRON contact and attach to it the integration platform ID as an identity key and the relevant attributes as tags

The above steps should be executed during the contact’s browsing phase for each webpage; a good practice is to include a JavaScript snippet on webpage templates.

Suggested approach

This paragraph provides, for each possible case, the implementation reference.

Case: Contact is anonymous both in THRON and the integration platform

Action: Link the IDs

How to implement: Most 3^rd party solutions have no way to sync devices (anonymous contacts), in case it provides an unique device ID you could use this as an identification key and move to the next case (anonymous in THRON but identified in the integration platform).

Case: Contact is anonymous in THRON but profiled in the integration platform

Action: Update THRON contact identity and assign tags

How to implement:

Update the THRON contact’s identity (its name) by invoking the contact/update method in the xcontact service
Connect to it a specific identifier coming from the integration platform; this identifier is a key/value association (for example "EXT_ID": "abcdef"). To attach such identity keys you will need to invoke the contact/addKey method in the xcontact service. You may then refer to this contact by specifying the associated key/value element in the contacts’ list or detail functions.
Identify which THRON tags need to be attached to the contact by checking the association between concepts mapped on the integration platform and the ones mapped on THRON; check the paragraph “Mapping concepts between the integration platform and THRON” below
Add the relevant tags to the THRON contact by invoking the itag/insert or itag/bulkInsert methods in the xintelligence webservice.

Case: Contact is profiled in THRON and in the integration platform but there’s no link between the two

Action: Update THRON contact by providing the ID on the integration platform and assign tags

How to implement:

Connect to the THRON’s contact the specific identifier coming from the integration platform as a key/value association (see above)
Identify the THRON tags to be attached to the contact by checking the association between concepts mapped on the integration platform and the ones mapped on THRON; check the paragraph “Mapping concepts between the integration platform and THRON” below
Add the relevant tags to the THRON contact by invoking the itag/insert or itag/bulkInsert methods in the xintelligence webservice.

[/dropdown][dropdown:Case Two: Contact is updated on the integration platform]

Once that the contact has been created on THRON and its identity on the integration platform has been linked, you may enrich the contact with information derived from the integration platform attributes. This is especially important when a contact has been modified directly on the integration platform side (for example, as a result of a “personas tag” being applied manually on the integration platform console): to preserve the data consistency the integration platform has to propagate the result to THRON.

The contact’s attributes updating process, executed by the integration platform, should trigger a logic that understands which THRON tags will best describe the contact after the change and apply the tagging accordingly. Check the following paragraph for further details.

The subsequent association between the concept in the integration platform and the tag in THRON will be performed by invoking one of the methods described in the “How to link a tag to a specific entity” article in the Help portal. Please check the article “Tag Center” in the Help portal for more details.

Mapping concepts between the integration platform and THRON

To ensure a consistent representation of the features for the contacts in the two systems it is important to map the concepts defined in the integration platform to the specific entities to be applied to the contacts in THRON.

You can assign an “external ID” to the tags; as seen for the contacts above, the external ID is a specific identifier coming from the integration platform; this identifier is a key/value association (for example "EXT_CONCEPT_ID": "ghijkl"). To assign an external ID to a tag you will invoke the itagdefinition/addExternalId method in the xintelligence service; you may then refer to this tag by specifying the associated key/value element in the tags list or detail functions.

If there isn’t a tag in the classification which can be mapped to a concept, you may create it by invoking the itagdefinition/insert method in the xintelligence service.

Check the page “How to map concepts coming from third-party systems” in the Help Portal for further detail.

Suggested approach

The most common process used to manage this step is described as follows:

Fetch, from the integration platform, all the contacts updated on the integration platform itself since the last “batch run”
Compute which THRON tags should be assigned to each contact (see the paragraph “Mapping concepts between the integration platform and THRON”)Mapping concepts between the integration platform and THRON”)
Fetch, from THRON, all the THRON contacts whose identities match with the list from step 1
Compute, for each contact, which tag to add and (if needed) to remove
Add the correct tags on the contact in THRON and remove the tags that should be removed (if applicable)

Often the process doesn’t include the tag removal (which could be performed at step 5) because of the transitory nature of contacts/devices and the additional workload needed to process which tags have to be removed. In case you want to manage tag removal, it’s important to identify a way to separate tags added by this process from tags added in other ways because of the need to ensure you will remove just tags added by this process (do not risk to remove tags used by other applications).[/dropdown][dropdown:Case Three: Contact is updated in THRON]

Once that the contact has been created on THRON and its identity on the integration platform has been linked, you may enrich its contact with information provided by THRON’s behavioural engine (as an example); remember we need to ensure we are able to preserve the data consistency between the two platforms.

This case is almost a symmetrical case of the previous one, but there are some differences.

THRON updates contact tags on several occasions:

when the behavioural engine attaches tags to the contact, tracking user interactions with the content (this is an automatic process which might happen on a daily basis)
when contacts are tagged because of some call-to-action execution
when contacts are manually tagged by THRON users

Suggested approach

The most common process used to manage this step is described as follows:

Fetch, from THRON, all the contacts updated since the last “batch run”
Fetch, from the integration platform, all the THRON contacts whose identities match with the list from step 1
For each contact whose identity matches, add the relevant attributes to the contact in the integration platform
Create new contacts that are not present in the integration platform (whose identity does not match)

Given the (usually) big quantity of contacts and devices, the contacts’ export function in THRON provides paged results; you will need to perform a series of function calls, each one with a specific “page identifier”, to scan the list of contacts in THRON. Moreover, we suggest you to perform a complete contacts’ export only when needed; it is much more efficient to export only the contacts that have been created or modified since a specific timestamp, thus performing an incremental export.

A full export of the contacts will take into account all the contacts defined in the customer instance and will be performed by invoking the sync/export method in the xcontact service; for each page of contacts you will need to filter out all the contacts without the specific identity key linked to the identifier in the integration platform (check the “Step one” above). At the end of this exporting phase you will need to take note of the timestamp at which the exporting process has ended; it will be necessary in the subsequent phase.

The incremental export process takes into account only the contacts that have been updated since the last check; these exports (executed on a scheduled basis) will return only the added, removed or updated contacts. This step will be performed by invoking the sync/updatedContacts method in the xcontact service, passing the timestamp in which the last execution has ended (and thus updating this timestamp at every invocation).

These export phases will return only the (anonymous or identified) contacts associated to the devices which carry the identifier in the integration platform as an identity key; each contact will return the list of intelligence tags, which will then be used to enrich the contact in the integration platform.

Please check the “How to sync your contacts with a CRM or a Marketing Automation tool” page in the Help Portal.[/dropdown][dropdown: Case Four: Track call-to-actions]

One of the steps needed to preserve the data consistency is to synchronize the call-to-actions: tracking of these actions will allow you to gather information on what content and topics have influenced your contacts’ decision‑making process, refining the knowledge you have of the contact.

When the user performs goal-related actions (such as form submission, purchases), such actions must be sent both to THRON and the integration platform; this step will also enable the Behaviour Engine and Recommendation Engine to associate the contact with the “most relevant topics” by checking the navigation history of each contact.

It’s important to perform such actions in real-time whenever possible to ensure the real-time recommendation of THRON can leverage this additional detail and ensuring the most accurate results.

Suggested approach

When users perform an action on the website (e.g. Form submission, add-to-cart button press, etc.) you will want to add tracking codes for such events; most of the times this will be implemented thanks to “tag managers” (such as Google Tag Manager) to ease the maintenance of the webpage HTML and JS code.

The THRON tracking library allows you to record user-content interactions as well as to track call-to-actions.

Please check the articles “THRON Tracking Library” and “CTA Integration” on the THRON Help Portal for further details.[/dropdown][dropdown:Case Five: Manage contact identity in real-time]

When the user performs identity-related actions (such as login or logout), the final state of the identity should be made consistent among both THRON and the integration platform.

Two main events can affect contact identity:

Login/form submission: events that provide the platforms with details that describe how to uniquely identify the contact (e.g. Username, email, CRM id, etc.)
Logout: events that notify the platforms that the user is changing his/her identity or switching to an anonymous state (especially important for family shared devices)

Suggested approach

This paragraph provides, for each possible case, the implementation reference.

Case: Anonymous contact provides his/her identity

Action: Switch from anonymous to identified contact

How to implement: Invoke the contact/update method in the xcontact service. If the contact is anonymous, this invocation will change its status to identified.

Case: Identified contact provides further details about his/her identity

Action: Add more identity data to contact

How to implement: Connect a specific identifier coming from the integration platform to the contact; this identifier is a key/value association (for example "EXT_ID": "abcdef"). To attach such identity keys you will need to invoke the contact/addKey method in the xcontact service.

You may then refer to this contact by specifying the associated key/value element in the contacts’ list or detail functions.

Case: Identified contact disconnects (logs out) from his/her identity

Action: Disconnect identity from device

How to implement: Remove the specific identifier in the integration platform from the THRON’s contact; the removal needs to be performed by invoking the contact/removeKey method in the xcontact webservice, referring to the specific key.[/dropdown]

In-depth information: