What is a Key?

A key is a unique identifier, provided at a Touchpoint, for the current customer.

Capturing the same key value for a customer across different devices or Touchpoints enables MXO to link activity and data for that customer to a single customer profile.

By default, MXO provides a single key attribute in a Space, the Customer Key.

In some cases, a customer may have multiple identifiers. For example, within your organization, a customer may be identified by their CRM Contact ID, email address, and membership ID. MXO provides the ability to store these multiple identifiers as keys, against a single customer TID, enabling you to link customer activity across multiple Touchpoints.

MXO uses keys in a number of ways:

To link an anonymous customer, tracked using their TID, to a known customer identifier
To link or merge multiple customer profiles belonging to the same customer
To enable an external system to look up existing customer data within MXO

Whenever an identifier is captured for a customer at a Touchpoint, MXO will either associate that identifier with the current customer, use the identifier to merge previously separate profiles for this customer, or switch the customer identified on this Touchpoint.

How do I create multiple Keys?

You create multiple keys by creating key attributes in MXO. You can create as many key attributes as you like, allowing you to link customers across multiple Touchpoints and devices.

How do I decide what to use as a Key?

When deciding which customer identifier to use as a key, consider the following:

Can you guarantee that the key is a valid key?
Is the key behind an authentication process?
Is the key produced by a known validated source, such as a CRM record?

For example, a good identifier may be a contact ID or other identifier originating from your CRM because you can validate its source.

Whatever you decide to use, you should be confident that at the time of capture, the information provided is valid for this customer. For example, is the contact ID or email address captured as part of an authentication process?

How does MXO work with Keys and TIDs?

The table below highlights a number of typical use cases, showing how MXO works with keys and TIDs.


No.	Use Case	Detail	What does MXO do?
1	New, anonymous, customer.	New, anonymous, customer identified on a Touchpoint. Customer does not have a customer key.	Medallia Experience Orchestration creates a new TID for the Customer.
2	New customer provides a key.	A new customer is identified on a Touchpoint, for the first time. The Customer key is passed to Medallia Experience Orchestration, but does not belong to an existing TID.	Medallia Experience Orchestration creates a new TID for the Customer and associates the key with TID.
3	Existing, anonymous, Web customer, contacts the Call Center for the first time.	Customer already has TID for the Web Touchpoint, saved as a cookie in their browser. Customer contacts the call center for the first time. A CRM key is passed to Medallia Experience Orchestration, but does not belong to an existing TID.	Medallia Experience Orchestration creates a new TID for Customer, and associates the CRM key with that TID. There is still no association with the customer's TID on the browser.
4	Existing, anonymous, Web customer provides a key.	Customer has a TID for the Web Touchpoint. Customer enters their email address, emma@er.com, which is captured by Medallia Experience Orchestration as an Email Address key attribute.	Medallia Experience Orchestration stores the email address as the value for the Email Address key attribute and links that key with the existing TID.
5	Known customer provides an additional key	Customer has the value emma@er.com stored as the Email Address key attribute in Medallia Experience Orchestration. Customer logs in to an online portal and their CRM Contact ID, er23456, is captured by Medallia Experience Orchestration as the Contact ID key attribute.	The new key, er23456, is stored against the existing customer TID. The TID now has two keys associated with it; emmar@er.com and er23456.
6	Known customer provides a different value for an existing key attribute. For example, where multiple customers are using the same device.	Customer has the value emma@er.com stored as the Email Address key attribute in Medallia Experience Orchestration. On the same browser, a customer logs in to an online portal using a different Email Address key attribute value, ciaran@cmc.com.	Medallia Experience Orchestration switches the customer identity in the browser, changing the TID held in the Medallia Experience Orchestration cookie. This ensures that emma@er.com is not associated with the same TID as ciaran@cmc.com. Each customer now has a TID with an associated key.
7	Multiple keys for the same customer are provided on an incoming request.	Medallia Experience Orchestration receives a request containing multiple new keys, for example, both email address and CRM Contact ID.	Medallia Experience Orchestration stores all keys against a single TID.
8	One or more keys on an incoming request match keys already stored for existing TIDs.	Two TIDs for the same customer exist in Medallia Experience Orchestration. The first is associated with the CRM Contact ID, er23456, the second with email address, emma@er.com. Medallia Experience Orchestration receives a request containing both the CRM Contact ID and email address key values.	Medallia Experience Orchestration resolves the incoming key values against the existing TIDs. Medallia Experience Orchestration merges the existing TIDs so all customer activity is linked to a single TID going forward.
9	As Use Case 8, but a new value for an existing attribute is sent on the same request.	Two TIDs for the same customer exist in Medallia Experience Orchestration. The first is associated with the CRM Contact ID, er1234, the second with email address, er@gmail.com. Medallia Experience Orchestration receives a request containing both the CRM Contact ID and email address key values. The request also contains a value for the Preference attribute, "Tennis". One of the TIDs already has the value "Football" stored for the Preference attribute.	Medallia Experience Orchestration resolves the incoming key values against the existing TIDs. Medallia Experience Orchestration merges the existing TIDs so all customer activity is linked to a single TID going forward. Medallia Experience Orchestration stores the latest value for the Preference attribute, "Tennis", regardless of which TID it was originally associated with.
10	Anonymous, mobile, customer moves from mobile app to mobile website on same device.	Anonymous customer uses the mobile app. Customer clicks on link in mobile app that takes them to the mobile website	If the customer does not have a TID for the mobile website, Medallia Experience Orchestration stores the incoming TID and associates all activity and data for both the mobile app and mobile website against this single TID. If the customer already has a TID associated with website activity on this device, Medallia Experience Orchestration merges both TIDs so all customer activity and data is linked to a single TID going forward.
11	Known customer moves from mobile app to mobile website on same device.	Known customer logs in to mobile app, providing an existing key, erm1234. Customer clicks on link in mobile app that takes them direct to the mobile website.	Medallia Experience Orchestration resolves the incoming key value. If the key for the existing customer is already associated with a TID for the mobile app, Medallia Experience Orchestration switches the TID in the browser to the existing TID and merges both the new and existing TIDs to ensure all customer activity and data is linked to a single TID going forward. If the key for the existing customer is not already associated with a TID, Medallia Experience Orchestration uses the new, incoming TID.