Identifying unique persons across all of your channels, platforms, and systems is the very foundation of a Customer Data Platform (CDP). This article will introduce you to how profile unification works at Raptor when data is ingested into the CDP and when you manage and activate your audiences.
Profile Unification
When engaging with Raptor, you will come across the acronym RUP. RUP is short for Raptor Unified Profile and is the engine that matches person identifiers across channels and consolidates them into the same unique profile as data streams into the CDP from your various sources. Now, based on these profiles, you can form audiences in the Audience Builder, look up profile metrics in the Single Customer View, create CLV models, activate audiences, etc.
Profile Unification succeeds out of a deterministic approach, which means that person identifiers must be identical across systems to be consolidated into the same profile. Here is an example:
- Person X visits your website from a laptop. This will create a cookie ID A that is picked up by Raptor's tracking script and forms an anonymous profile in your CDP.
- Person X revisits your site some days later, but this time from a smartphone. This visit creates a new anonymous profile since the cookie ID created by the smartphone is different from the one set by the laptop browser. We'll call it cookie ID B.
- This time, user X purchases from your site and leaves an e-mail address at check-out. Now, the e-mail address and Cookie ID B are stitched together into the same profile, and the user is no longer anonymous since an e-mail address is a unique identifier.
- After a couple of months and several visits on your website, person X also makes a purchase from the laptop by logging in using the e-mail address from before. The full visit history on the no longer anonymous person is now attached to the profile in the CDP by adding interactions with cookie ID A picked up by the tracking script.
- Person X has along the way also created a profile on your site and signed up for your newsletter. By ingesting mail openings, mail clicks and profile details into the CDP, the profile will be enriched with information that is very useful when building audiences and finding patterns across your customers and their behavior.
Unique identifiers
When planning which identifiers should go into the profile unification, it is important to think about uniqueness versus non-uniqueness. Normally, you will have a master ID/customer ID from e.g. your CRM system that will uniquely identify a profile (either a person or an account). In other cases, you can use an email address as a unique identifier. In that case, you should be aware that if your customers change email addresses, a new profile will be created without the opportunity to connect the new profile to the data of the old profile.
Setting a person identifier as non-unique means that a profile can contain multiple different instances of that identifier. This will be the case with cookie IDs. A non-unique ID cannot, however, exist on two different profiles at the same time. For example:
- If a cookie ID has been seen by the profile unification system along with profile A, but is later seen along with profile B, the cookie ID (and the interactions associated with that cookie ID) will shift from profile A to profile B.
This logic ensures the most updated affiliation between a profile in the CDP and the actions performed by the person most recently associated to the profile.
Validation
Validation of your person identifiers is extremely important to avoid wrong data contaminating your CDP. As soon as contaminated person identifiers have been ingested it is very hard to clean up, leaving no choice but to create a new account.
When creating person identifiers you will have a range of validation options. Use these options to ensure that only correct data will stream into the CDP.
For example:
- The customer ID from your CRM system always consists of 10-12 characters, both numbers and letters, never spaces, no special characters. Apply these rules:
- Minimum number of characters: 10
- Maximum number of characters: 12
- Allow letters (a-z)
- Allow numbers (0-9)
- Do not allow spaces
- Do not allow special characters
Apply as many rules as possible. The purpose of the validation is to ensure that wrong or flawed data is filtered away before entering the CDP. If data violating the validation rules starts streaming through the Data Manager, the dataflow will fail and you have a chance of correcting the errors leading to the failed dataflow.
Identifiers can be of different types. They can be GUID, Email address or Generic. GUID and Email address are validated automatically by the system, but when using the Generic type, you will need to a build strong set of validation rules yourself. Reach out to Raptor Support if you have questions or doubts about validation or person identifiers in general: support@raptorservices.com