A common allied WWII cipher was to combine a numerical alphabet code with a key word, known only to the message recipient. To crack the code, the enemy would need to have the key word in addition to deciphering the code itself. The key word, for obvious reasons, would change frequently, hopefully leaving the enemy unable to piece together any understanding of allied plans.
In the world of delivering hyper-personalized customer experiences that depend on possessing a deep understanding of an individual customer, the situation captures the importance of persistent database key management. If changing keys (or a key word) precludes a deep understanding, the converse is also true; persistent keys are vital for marketers and business users of customer data to understand how a customer is proceeding through a customer journey by linking various signals to a unique, persistent customer ID that contains all the interactions pertinent to that customer. In this context, customer is understood to mean any party to an interaction a business is trying to understand – an individual, business, a household, a business, patient, member, buyer, employee or even a product.
The “Key” to Persistent Key Management
The logical question with persistent key management, then, is what constitutes the key? If it is, say, an email address and a marketer wants to attach signals to a unique email, the obvious problem or set of problems is that customers change email addresses, have multiple email addresses, or even have a dedicated email that may be used by multiple individuals. The same holds true for using a device ID or a physical address as a persistent key.
One workaround to these problems is to use a set of identifiers as a persistent key, such as a combination of an email and physical address with a phone number, for example. This creates another stumbling block, however, in that there may be several customers for whom the company doesn’t yet have all this information.
To avoid these problems, persistent key management relies on a mechanism for creating a unique ID, rules for attaching the unique ID to a signal and rules for keeping it or replacing it over time – as the customer journey evolves. That is what is meant by persistence; a consistency to ensure that business users are not randomly losing or gaining information about a customer over time because of the vagaries of how the customer identifies themselves, or of how the identity resolution process unfolds.
Persistent key management, then, means that all normal operations of the identity resolution system are designed to provide a consistent – and trustworthy – identity across time in the face of expected changes.
Persistent Key Strategies
The ideal in persistent key management is to assign a unique ID that is not related to any of the data received in the signal. A sequential assignment is one method, such as designating a new ID for each new transaction or other type of signal. Another method is to assign a prefix and numbering system for each signal location, such as WS for web server, POS for point of sale, etc.
Even with these methods of assigning a persistent key, database key management must account for consistent change, ensuring a unique ID remains unique when, say, a customer moves from an anonymous to known record. If Web_X_Y is a unique ID when a customer is anonymous, but the customer at a later point in time logs in and becomes known, perhaps the unique ID then becomes Loyalty_X_Y.
A common way to account for change is to have a unique ID that might be part of the signal attached to the signal itself. In this way, when attaching a record (Web_X_Y) to an overriding record (Loyalty_X_Y) the unique ID remains in the signal, but the centralized unique ID is now associated with the loyalty customer. For example, the original web unique ID has all the signals and information for the customer as they proceed through a journey. When the customer identifies themselves as a loyalty member, all the information associated with the web ID moves to the loyalty ID, and there is now a cross-reference in the main database table that says the loyalty customer is the same person from the web account. No signals are lost.
The mechanism for linking and cross-referencing identities is a centralized key stored inside the primary customer data platform (CDP) database, and the key persists without losing information. It can be replaced as needed, but it preserves all the signals – from web visits, point of sale systems, etc.
Persistent Keys and Consistency
Another consideration in persistent key management is to avoid the temptation to reconstruct a set of persistent keys for every major operation, such as a batch update.
Reconstructing persistent keys is never a good idea if the goal is to provide a consistently relevant, personalized experience throughout a customer journey. A nightly batch feed provides a host of new signals, which will require some automated matching process to build an identity graph to show the various connections. Assigning new keys within that construct prevents a simple, verifiable way to recognize that the John Doe from today’s batch is the same John Doe from yesterday’s batch run. Without an independent mechanism, constructing an identity graph from 50 million new records will lose the important understanding of incremental change from one batch to the next.
A new key assignment might be acceptable if the goal is to simply send a generic blast email to every record that visited a website overnight, but that “key” will lack any contextual understanding of the customer beyond activity in that one channel.
Advanced identity resolution capabilities in the Redpoint CDP account for this issue with predictive, deterministic and probabilistic matching algorithms that are independent of operational updates. Maintaining a separate accounting of which records should be matched or separated prevents the need to assign new keys, while also providing a longitudinal, contextual view of a customer’s movement through a customer journey.
Persistent key management is an important CDP capability for ensuring a consistent, relevant customer experience. We know with certainty that customers will change. They move, they acquire new devices, phone numbers and email addresses. They get married. They are anonymous or known, depending on how and when they engage with a brand. As signals and information are continually added or changing, persistent keys ensure a CDP does not lose any understanding of who the customer really is through change.
