Avoid CDP disaster by following these email guidelines

Checklist

How to match data reliability and CDP use cases to maximize performance.

It’s very easy to make huge mistakes with your customer data if you don’t think carefully about how you collect and use your email addresses. The guidelines and examples below will help you craft the best policy for your organization, enabling you to make the most out of your email data.

The goal of a Customer Data Platform (CDP) is to merge customer records from multiple sources into a single customer view so you can act on that data. Email address is often used as the key for merging those records. But not all email addresses are created equal, and you can capture them a number of different ways.

For example …

  • Login emails
  • Emails captured in the store at purchase
  • E-newsletter signups
  • Inferred emails from clicks on outbound messages
  • Emails imported from your email service provider (ESP)

That last category — email addresses imported from your ESP — can be further divided by the deliverability and quality of the email.

What will you do with all these different types / sources of email addresses?

Should you keep them separate?

Should you merge them into one field?

And which of these are you going to use to merge your customer records?

As with almost everything related to a CDP, the confidence you require in your data depends on how you’re going to use it. Nothing is ever 100 percent certain, but some use cases require more certainty than others.

The #1 rule with a CDP is to match the right data with the right use case.

If your business model is to collect email addresses, link them to some level of interest in a particular topic, and send out promotions on that basis, you don’t have to be all that particular about how you collect the data in your CDP. The ESP will sort the good from the bad.

But if you’re going to display account information (renewal messages, reward points, order history), you need to be much more certain you have it right.

Here are two examples of “levels of confidence” that you can use.

Low confidence: When someone signs up for an e-newsletter, collect the email address from that form submission and write it to the user profile, where you can enrich the address with usage and other behavioral data. That’s it. You’re done. The address you collected might be mickey@disney.com, or it might be the junk email address the person never uses, but you’re not worried about that. This is just the top of the email collection funnel, and you sort and segment somewhere else.

Higher confidence: When someone signs up for an e-newsletter, collect the email address from that form submission and write it to a temporary field. Export it to your ESP. Only add the address to a customer’s record after it has been confirmed to some level of certainty, e.g., didn’t bounce, recipient opened at least one message, or recipient clicked on at least one message.

Let’s say you understand these concepts, and you get with your team and align your data strategy with your use cases, then your CDP genius quits. What happens?

Working out these rules requires a bit of thought, but the on-going maintenance is the bigger problem. Three years from now, when the people who carefully crafted your business rules to match the reliability of your data to the right use cases have moved on, and some new marketing exec finds this treasure trove of email addresses hidden in the CDP, your carefully crafted plan can fall apart.

You’re going to have to document each field and each process in a way that the new guy can understand.

In Summary

There are many ways to capture email addresses in a CDP, and each of them comes with a different level of certainty / validity. That’s perfectly fine, so long as you’re matching the reliability of the data with the use case. Also, you have to document all this so new users don’t mess it all up.

Please contact me if you’d like to talk this over and figure out how to apply these concepts in your organization.

Leave a Reply

Your email address will not be published. Required fields are marked *