Greg Krehbiel, Author at MarTech Marketing Strategy, Marketing Technology, Marketing Transformation Mon, 06 Jun 2022 15:09:58 +0000 en-US hourly 1 https://wordpress.org/?v=5.9.3 How to manage email addresses in a customer data platform https://martech.org/how-to-manage-email-addresses-in-a-customer-data-platform/ Mon, 06 Jun 2022 15:09:50 +0000 https://martech.org/?p=352744 Some advice on finding the right solution for your unique requirements.

The post How to manage email addresses in a customer data platform appeared first on MarTech.

]]>
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


Get the daily newsletter digital marketers rely on.

Processing...Please wait.


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. 

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 gkrehbiel@companyx.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 gkrehbiel@companyx.com (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 gkrehbiel@companyx.com. 

How are you going to get a single customer view? 

Even though the CDP has a profile for gkrehbiel@companyx.com, 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.

The post How to manage email addresses in a customer data platform appeared first on MarTech.

]]>
Prepare for CDP implementation using a template for use cases https://martech.org/prepare-for-cdp-implementation-using-a-template-for-use-cases/ Thu, 12 May 2022 17:02:26 +0000 https://martech.org/?p=352320 Sharpen focus during the consideration phase by organizing the tasks and goals that a new CDP can deliver on.

The post Prepare for CDP implementation using a template for use cases appeared first on MarTech.

]]>
When considering a customer data platform, many people ask questions like:

  • How do I pick the right one?
  • Do I need a data lake along with a CDP?
  • How much of my current tech stack can a CDP replace?

Those are all good questions, but there is no generic answer that will work for every company. It depends on your business model, your current tech stack, and what you want to do with your customer data. In other words, it depends on the use cases.

“But wait,” you say. “What exactly is a customer data platform?” 

The CDP Institute defines a CDP as “packaged software that creates a persistent, unified customer database that is accessible to other systems.” In a perfect world, it creates a single customer view from all your customer data, no matter where that comes from – your email service provider, your store, your fulfillment system, customer web behavior, etc. It stores this information in a format that enables you to act upon that enriched, comprehensive, single view of the customer.

That’s the goal, anyway. In reality, you’re never going to merge all your data. It’s a question of degrees. And that’s okay.

Read next: What is a CDP?

Why do you need a CDP?

A CDP can help you do some very useful stuff.

  • Find out which of your paying subscribers that frequent your website haven’t yet signed up for your email newsletter, allowing you to target them on your website to invite them to sign up.
  • Personalize messages based on interests, order history, or other characteristics.
  • Present better and more targeted cross- and upsell offers.
  • Create new options for advertisers by creating new segments of users based on common interests.

But before you pull out the checkbook, there’s some work to be done, and this applies whether you already have a CDP or are considering one.

Why you need to write CDP use cases

You need to define how you hope this technology is going to help you and your customers. That is, you need to write up your use cases, with as much specificity as possible.

By starting with use cases, you avoid the “bright shiny object” problem and focus on genuine business requirements. Through this process, you’ll discover what functions you need a CDP to perform, and therefore whether you really need one, and you’ll be able to get a better handle on whether it’s worth the investment.

If you already have a CDP, creating a disciplined structure for use case documentation and review will smooth your operations considerably.

There are many ways to write up use cases, but I’ve summarized my recommended structure below to help you get the process started. I say “to get started” because this document is only the beginning. You’ll write up your use cases in the format I outline below as a preliminary matter, to decide if they’re worth pursuing, or to decide if the CDP can meet your requirements. If you decide to go ahead with them, you’ll have to create a much more detailed document when it comes to implementation.

Generic use case template

You should create a form using the elements I list here and ask everyone in your organization to use this form when they propose a new use case. Thinking through each of these elements will help you define exactly what you want to do and how.

Summarize it with a story. Use a very structured format, like this: As a [role], I want to [action] so [result]. For example, “As an email marketing manager, I want to display a sign-up widget for our retirement e-newsletter to everyone who has recently viewed retirement content on the website so I can increase the reach of our retirement e-newsletter.”

Make the business case. Explain why this use case is necessary now, and how it will:

  • increase your revenue,
  • improve customer service,
  • help you discover new (possibly ancillary) product ideas,
  • create better reports, etc.

Refine the summary with specific details

The devil really is in the details when it comes to CDP use cases. If you ask the salesman, “Can your CDP do ____?” the answer will almost surely be yes. It’s only when you dig into the details that you find the limitations and potential problems. 

For the example in the story above, additional details might include the following.

  • What constitutes “retirement content,” and how will the CDP recognize it? (E.g., is it tagged?)
  • Can the CDP react immediately to a tag on the first-page view?
  • What are the specs on the widget?
    • How and where should it be displayed?
    • What words and images should be used?
    • How big is it?
  • Do you want to A/B test different versions of the widget?
  • What is the path for the data to get from the widget into the CDP and into your ESP? Which system is the “source of truth”?
  • How will you measure results?
  • How long should the campaign run?

The more details you provide, the better.

Identify relevant customer data and its source

For some use cases, all you’ll need is data from within the CDP. You might create segments of users based on favorite topics, when they visit the site, or how often. Other use cases will require data from your other systems. Explain that as carefully as you can.

  • If you want to target on-screen messages to people who have marked your e-newsletter as spam (some people do that by mistake), you’ll need data from your ESP.
  • If you want to target customers with high lifetime value, you may need data from your fulfillment system.
  • If you want to evaluate the behavior of prospects who have recently downloaded a whitepaper, you might need an import from Salesforce.

In any case, think about the systems that house the data you need to make this use case successful, and then look carefully at how that data is stored. Will it need to be cleaned up, or transformed in some way? Can you get it in real-time, or does it have to be batched? Does the system from which you want the data have an API, or will you need to build a connection?

Read next: M&T Bank’s use cases for their CDP implementation

Can you re-purpose existing segments?

If you already have a CDP, you may have already defined the right segment of users. If so, list it here.

But be cautious! It’s crucial that you carefully document how a segment is created and what it’s designed for. It’s very easy for a segment name to be misleading. For instance, does the category “all subscribers” include both paid and free e-newsletter signups? Does it include people who have attended webinars? Does the segment “active subscribers” include people in grace, undeliverable orders, or unpaid orders?

Those are simple examples of how messy it can get. Things quickly become far more complicated than that, so make sure segment definitions are well documented.

Success criteria for the CDP

How will you know that this use case did what you wanted it to do? How will you track the actions you are seeking? What reports are required? What metrics constitute a success?

If possible, you also want to specify revenue goals – especially if you’re in the consideration phase and want to determine the potential return on investment of a CDP.

You’ll need more later

That outline is for the consideration phase. That is, do you want to pursue this use case or not, and can the CDP deliver on what you need?

Once it comes to implementation, you’ll need a more extensive template that includes other details, like specific language for an offer, design specifications, internal approvals that are required, and possible follow-on uses.

By taking a disciplined approach to use cases, you will have a much easier time evaluating CDPs, or getting the most out of the one you already have.


Get the daily newsletter digital marketers rely on.

Processing...Please wait.


The post Prepare for CDP implementation using a template for use cases appeared first on MarTech.

]]>