The main purpose of a customer data platform is to merge all your customer data into one place, where you can orchestrate online and offline campaigns based on customer attributes, transactions, or behavior. As a very simple example, you can find the people who frequent your pages about skiing and send them an email when you get a new ski-related product in stock.
Such a campaign is only possible if you've been able to enrich the customer's online profile with their email address. In other words, your prospect may have purchased something from you, so you have his information in your store, and he may also visit your website. Still, until you can merge those records, you can't use his on-site behavior to send him appropriate messages. Knowing how to enrich an online profile with an email address is a study in itself and beyond the scope of this article, although I discuss it in some depth in this short video.
It's nice to think that once you've attached an email address to an online profile, you can merge customer data on that email address, and voila, you have your single customer view. However, nothing is that easy. Some of your customer data won't have an email address, and people usually have several email addresses that change over time -- due to changing jobs, mergers and acquisitions or simply from creating personal addresses on several different systems. This is where you need to make an important decision. The idealistic goal of a CDP is to merge all your customer data, but the reality is that might not be worth the trouble. It all depends on what you expect your CDP to do and think through that. You need to compare customer data scenarios with your use cases.
The simple path is to make the email addresses unique. You have a separate record in your CDP for each email address. That means you might have multiple records per customer, which seems to contradict the whole point of a CDP -- which is to have a single view of the customer -- but that solution is perfectly okay for some use cases. To get into this a little deeper, it's helpful to discuss the distinction between online and offline profiles. Let's say I worked for CompanyX in 2020, and my email address at that time was email@example.com. While at CompanyX, I attended one of your webinars, so you have a record for me in your customer database that includes that CompanyX email address. In 2021 I left CompanyX and started with CompanyA, where my email address changed to greg.krehbiel@companyA.com.
In 2022, you invested in a CDP and imported all your webinar information, which created a profile for firstname.lastname@example.org (the out-of-date and now useless email address). That same year, I visited your site. Your CDP created a profile based on that visit -- that is, it put a cookie on my web browser and started recording the interactions I had with your website - but it didn't know who I was. When I downloaded your white paper using my current email address -- greg.krehbiel@companyA.com -- I changed from unknown to known (hurray!), but you still don't know that I attended one of your webinars because that account has me as email@example.com.
How are you going to get a single customer view?
Even though the CDP has a profile for firstname.lastname@example.org, who attended your webinar, that profile is essentially useless. The email address is defunct, and it doesn't correspond to any active online profile, so you can't target me as a webinar attendee on your website. If you create a segment of "people who attended webinars," that profile will be included, but it won't do you any good. It won't be actionable. The example points out the limitations of merging profiles based on email addresses. You simply won't get all the information you have on your customers into one record.
As an alternative, let's say the form to download the white paper included name and address. Now -- assuming I used my home address, which stayed the same from 2020 to 2022 -- you have the possibility of merging my CompanyX record with my CompanyA record. Now you can target me on the web as a webinar attendee. The overall point is that you have to think through the many to one problem with email addresses. One person -- Greg Krehbiel -- has many different email addresses and potentially many different touch points with your company that are associated with those different email addresses. If you can't merge those profiles into one record, you won't have a complete view of your company's connection with me.
Does that matter? Maybe, maybe not. My actionable profile -- the one where you have what I do on your website and my current email address -- will not include the fact that I attended your webinar. Is that a big problem? It depends on how often you think it will happen and the consequences of getting something wrong. For example, it's one thing to fail to include me in a list of "past webinar attendees," but it's another to include me in a list of "people who have never attended a webinar." The challenge here is that you can go down quite a rabbit hole trying to solve every edge case and exception. The more you think about it, the easier it is to come up with ordinary events that will mess up your data.
What if there's a typo in an online form to collect an email address?
What happens when a company changes the structure of its email address (e.g., from first initial, last name @ company dot com to first name dot last name @ company dot com)? When someone calls customer service and changes their email address, how will you deal with that when you re-import the data? You can drive yourself crazy thinking of how things can get messed up.
So what do you do?
As mentioned above, the simplest thing is to have one email address per customer profile. But that means you're giving up on the idea of a "single customer view." If that's okay -- if you think through all your use cases, and it doesn't matter too much -- then go with that. Another option is to allow the email field to have multiple email addresses. The only downside to that approach is that email is no longer a unique identifier for your customer profiles. But you can always use something else.
Here's an exercise for you to figure this out. Come up with a list of scenarios where someone's email might change or why they might have multiple emails:
- Changed job.
- New personal email.
- Serious email and junk email.
- IT guy at the company decided to change the format of the emails.
- The company changed its name, etc.
With that list in one hand and your merge rules in the other, review all your use cases. In what situations will you fail to get a "single customer view"? How big of a problem does that pose to your overall strategy, and what do you hope to get out of your CDP? If you don't think long and hard about how you intend to manage your customers' email addresses, your CDP implementation is likely to disappoint you. The guidelines in this article should have put you on a path to uncovering the right solution for your unique requirements.