How to choose your contact unique key?

Why picking your unique key is important?

The unique key is a Splio Customer Platform system field you can use to attach a unique user identifier to a contact. That user identifier will act as a 1-1 mapping identifier between Splio universe and your external systems. The unique key must be:

• Unique and immutable (stable over time)
• Ideally known by most of your systems (e.g. PoS, e-commerce, ERP, CDP ...).

Common considerations when integrating with Splio

We provide a multi-source management platform but keep in mind that:

• A contact is associated to a single unique key (enforcing unicity) and Splio do not manage the unicity of multiple contact keys.
• For the each of your data sources we recommend you to store the identifier in a dedicated custom field, ideally with the last update date.
• Splio is not an identity provider.
• Contacts merge is not possible so the last update of your contact will win and a lookup approach before creating contact in each of your sources is recommended to avoid duplicates.

📘

Sources can be pushed by Connectors, APIs or files (through our Datahub).

By default in Splio, contacts are accessible via API using the contact key, and data synced through Datahub also requires the contact key. We recommend choosing the unique key that is known by most of your systems, especially those already communicating with each other. If not, starting your project with Splio presents a great opportunity to introduce synchronization between your systems, at least on the contact scope. Depending on system capabilities and resources, we also offer other integration patterns.

We advise against choosing the email as the contact key to avoid creating duplicates and to maintain a clean contact history. While it can be an alternative if system synchronization adds complexity, it's essential to consider the trade-off involved.

Below, we describe two architectural patterns that will help you choose the right contact key and approach.

Architectural patterns: overview

In architectural design, one of the critical questions is whether sources exchange the different contact identifiers among themselves, and whether the contact scope is synced for each source. Typically, systems transmit a unique key to all other systems, but there are key patterns to consider.

📘

How to ensure contact uniqueness?

We recommend to apply a lookup in each of your systems before creating the contact, based on the email and the phone to ensure contact uniqueness.

💡

Lookup definition

Here we define a contact lookup as: a process used in data management and integration systems to search for and retrieve information about a specific contact based on certain identifying criteria, typically the contact key, email, or phone number.

For example, if one system has a customer's email address stored incorrectly or doens't ensure unicity (ie. same email can be stored in multiple contacts), a lookup can help find the correct and complete information. Additionally, different systems may use different identifiers for the same customer, and a lookup helps reconcile these differences and maintain data consistency across platforms.

In the context of CDP and Marketing Automation systems, a contact lookup is often performed to find or verify a customer's details before adding new information or updating existing records. This helps ensure data accuracy and prevents duplicate entries.

Recommended pattern: unique key as a custom field

Ideally you have a unique identifier is already known by all the sources which are already communicating with each other. Alternatively, the system must retrieve the contact key, process it, and look it up before pushing the new data.
If not you can rely on an pattern where the first source creates the contact and prefix the identifier with the name of the source to ensure consistency.

🚧

We are working on handling multiple keys unicity but for now each source need to make sure of the unicity. Shopify connectors manges the unicity by the unique key and email. If you are integrating with Shopify in a multiple source architecture, you can read more in this article.

Email as a unique key

Ideally, we do not recommend using the email or the phone number as the unique key since:

• they are not immutable
• some systems don't manage email unicity
• a percentage of your contacts might not have an email attached but are still relevant in your CDP

Another typical edge case in this configuration: as the email can be often be changed and one user can have different email you will systematically loose the order history.