Managing Customer Identities in Loyalty Programs

Or why you shouldn’t make emails as your primary customer identifier

On a group chat, someone gave a feedback on an loyalty application I worked on some time ago:

“Your view on the Loyalty app would be appreciated. You cannot change an email address and are forced to change your phone number. Resolution: keep ur new number, use a new email and they will transfer your points… The point of building user apps is to make it a seamless experience for customers. People need to get the basics right”

Sounds familiar?

The Marketing First Approach

What do marketers want? Easy access to ALL of the customer data! When do they want it? YESTERDAY!

Funny as it might sound, but usually, the core problem is exactly that — business requirements that sound logical (I mean, we can only send emails to email ids right?) but are found lacking when the user decides to make changes.

In the grievance raised above, you can imagine how the team handled it. They probably created a new customer, with a new email & phone number and transfer points over. For audits sake, they also added a field old loyalty id and updated it with the previous identifier.

And this will solve the problem in the short term (you’ll need an army of CS execs to manage it, but it works).

In the long term however, if the program wants to understand the users behavior or even segment her based on total transactional value, they’d only see the transactions made under the new id. Additionally, the sign-up numbers are inflated since you have more than one ID associated with a single customer.

The root problem is that a single human is identified by transient identifier.

What’s the fix?

Usage driven approach

Note: I’d like to point out that customer graph (which is the obvious answer), though great at getting a centralized identity for the customer, is piece in the bigger identity engine. I’ll explain that separately in the coming text.

The usage driven approach simplifies the identification of a customer based on how the identifier will be used. Specifically, it holds multiple identifiers, each with the source, the time and the activity to validate its existence.