How to add emails to your CDP online profiles without creating a mess

Woman reading email at coffee shop
View here

Summary: A quick method for enriching your online profiles with email addresses involves passing a hashed email or unique identifier via a URL query parameter. However, this approach can cause trouble if the URL is shared or forwarded. This article explains some ways to make it work without corrupting your data.

One of the basic CDP use cases is to convert unknown, or anonymous web visitors to known. That means you have to collect some PII – some personally identifiable information. Usually that’s an email address.

There are a lot of ways to do this. You can capture an email address the visitor enters on your e-newsletter sign-up form, in your shopping cart, or other situations like that. That’s a pretty safe way to associate an email address with a web profile, and then you can use that email address as an identifier and enrich the online profile with data from other sources.

But there’s a faster way to enrich web profiles with email addresses. That involves passing a hash of the email address, or a unique identifier from your ESP, as a query parameter in your email.

Here’s what I mean.

I send out an article with a link to this page.

https://krehbielgroup.com/2024/01/16/5-ways-to-improve-digital-magazines

Now notice this URL.

https://krehbielgroup.com/2024/01/16/5-ways-to-improve-digital-magazines/?email=greg@krehbielgroup.com

This time I’ve passed my email address as a query parameter.

BTW, I’m only showing it this way so you can understand the concept. Don’t send the email address in the open like that. People will freak out. Use some other value, like ID=, and use a proxy for the email address.

The CDP can capture that value from the query parameter and add it to my web profile.

Bingo. I’ve associated an anonymous web profile with an email address.

But have I?

What if the recipient of your email forwards it to somebody else, or posts that URL to social media? Now other people are going to get that same email address in their web profile.

I’ve heard this called an edge case, but I know for a fact that it’s not. I’ve tested it, and if you collect email addresses this way, you’re going to get a lot of junk. It will work fine for a large percentage of your users, but for some users it will be a catastrophe. The worst part of it is that it will be a catastrophe for precisely those users you want to have a really good relationship with, because those are the users who are forwarding your emails and posting your content on social media. Those are your “whales” as my friend Rob Ristagno would say.

So where does that leave us? This is a great method for enriching profiles with an email address, and can quickly help you convert a lot of unknowns to knowns, but it has a very serious flaw. How do we fix it?

First, let’s divide the problem into two different scenarios: clicks from social media, and clicks from emails.

I would simply not use clicks from social media. In other words, if the referer is social media, don’t capture the value in the query parameter. I’m assuming you know what an HTTP referer is. If not, I’ll provide a link below.

Clicks from emails are a little more difficult because there’s no simple way to distinguish clicks from the correct email recipient and clicks from someone who received it as a forward. But here are some options.

  1. If your ESP provides the time when the recipient clicked on the link, and that matches the time when you collected the query parameter, you can be confident you’re collecting the right email address.
  2. You could also use a counter. You can assume that the profile that collects the email ID the most frequently is the correct recipient.
  3. It might spook your readers, but you could also just ask. Something like “Our system tells us your email address is such and so.” This would be very transparent, and would allow you to get consent to use that email address in your online customer journeys, but there are clearly downsides as well.

In short, this is a very powerful CDP use case, but it can create a powerful pile of mess if you don’t use it properly. If you have questions, please give me a call.

Leave a Reply

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