What is a martech stack? 

A marketing technology (or martech) stack is the collection of technology and software tools a company uses to manage and execute its marketing activities. Here’s a list of typical components. 

• Email service provider (ESP) 
• Customer relations management (CRM) 
• Marketing automation 
• Tools for A/B testing 
• Content management system (CMS) 
• Analytics 
• Social media tools 
• Adtech tools 
• Customer data platform (CDP) 
• Customer experience tools 
• Data visualization tools 

But I’m not starting from scratch

You probably already have some of these technologies unless you’re a start-up. But whether you’re starting from scratch or building on an existing system, components of your stack are likely to have overlapping functionality. An ESP might have marketing automation components or social media tools, and a CDP might have built-in analytics and its own ESP. 

So even if you did start from scratch, you’d still run into the problem of duplicative functionality. After all, nobody mandates the capabilities any marketing software provides. Just because a vendor calls their technology a customer data platform doesn’t mean it has the functions you want or expect in a CDP. 

Creating your map

One way to navigate this confusion is to map what you need and what various services provide. Here’s a very simple example. 

The objective is to create a comprehensive map showing your capabilities and those you want. To create the map you’ll need for your own custom martech stack, start by making a list of all the stack components you think you might need. Use the list I provided above as a starting point. 

In each of the rows, list the functions you need. In the columns, list marketing tech applications. This sounds difficult, but you can get a head start using MarTechBot. For example, you can ask MarTechBot to list the top 10 functions and capabilities of an ESP. Here’s the list MarTechBot came up with: 

1. Email creation and design: ESPs offer a variety of templates and tools to create visually appealing and engaging emails.

2. List management: ESPs allow you to manage your email list, segment it based on various criteria and maintain its hygiene.

3. Email automation: ESPs offer automation features that allow you to send triggered emails based on subscriber behavior, such as welcome emails, abandoned cart emails and more.

4. Reporting and analytics: ESPs provide detailed reports and analytics on email performance, including open rates, click-through rates and conversion rates.

5. Integration with other marketing tools: ESPs integrate with other marketing tools, such as CRM systems, social media platforms and landing page builders, to provide a seamless marketing experience.

6. A/B testing: ESPs allow you to test different versions of your emails to see which one performs better.

7. Personalization: ESPs offer personalization features that allow you to tailor your emails to individual subscribers based on their preferences and behavior.

8. Deliverability: ESPs have tools and features to ensure that your emails are delivered to your subscribers’ inboxes and not marked as spam.

9. Mobile optimization: ESPs offer mobile-responsive email templates and tools to ensure that your emails look great on mobile devices.

10. API access: ESPs provide API access to allow you to integrate your email marketing with other systems and applications.

https://martech.org/martechbot/

The list won’t be perfect. For example, I don’t see “send my email campaigns” on this list. But it will provide a good starting place. 

Review and optimize

As you go through the AI-created list, do two things. 

• Highlight the functions you require (don’t delete the others). 
• Add your own requirements to the list. 

There are a couple of reasons not to delete the functions you don’t need. First, they’ll keep coming up anyway, so you might as well have a place for them. Second, just because you don’t need or want them now doesn’t mean you might not in the future. Creating a comprehensive document will help you in the long run. 

Follow this same procedure for each of the technologies on your list. You’ll quickly notice lots of overlap between these lists. ESPs, CRMs and CDPs might all have marketing automation capabilities. You’ll also notice that some of the technologies you use will have functions that don’t fit in their category. For example, your ESP might be able to make limited content recommendations or have SMS capabilities. 

That’s fine. Just decide where you want each function to live according to your understanding of how that technology should work. Again, there’s no official list of what each technology is supposed to do. 

You can readily imagine that this burgeoning technology map is going to become a big spreadsheet. 

Once you have all the capabilities in rows, list the technologies you use at the top of each column and fill in the intersecting boxes. You could use a checkmark to indicate that the technology has that capability and use cell colors to indicate things like: 

• This is what we use and we like it.
• This is what we use and we don’t like it. 
• This technology can do this, but it doesn’t meet our needs.
• We should move this function here. 
• Etc. 

You’ll devise plenty of ways to characterize each of these entries. 

Getting all the details about how a particular technology provides a given capability in a single spreadsheet cell will be hard. Using colors as a guide will help, but you’ll need additional notes and explanations. You could put the additional information in a comment field, or you could provide it in a second document, with a reference to the appropriate spreadsheet cell. 

Now you have a chart that visually overviews your current tech stack. From this chart, you can see a few things: 

• Capabilities that need to be upgraded. 
• Technologies with more capabilities than you need or use (possibly because they’re already done by something else). This might indicate an opportunity to find a cheaper option that only does what you need or to negotiate a cheaper rate for that technology. 
• Desired capabilities that don’t currently have a home. This indicates where you need to start looking for new services. 
• Capabilities you have from an incumbent technology but aren’t using. These might represent simple opportunities to improve how you run your business. 
• Capabilities you haven’t considered.

This document you eventually build will become a useful tool for internal use and reference (especially when there’s staff turnover!), but it also helps you to evaluate prospective technologies. What gaps do you need to fill? What services can fill those gaps? 

By the way, MarTechBot can help with that as well. Ask something like, “What services can help me track user engagement on my website?” 

As long as you don’t include proprietary information in this map or any accompanying documents, it can be a useful addendum to an RFP. When prospective vendors see what you’re currently doing, they can make more intelligent recommendations about how their services can fit in. 

The post A practical guide to building a marketing technology stack appeared first on MarTech.

Here’s how to develop the best recommendation strategy for your site, content and audience. Most off-the-shelf content recommendation engines will not have all the capabilities discussed here, but knowing what’s possible will help you find the best solution for your business. 

What is content recommendation? 

Content recommendation systems suggest additional content to visitors based on what they will likely be interested in. For example:

• YouTube and Netflix use content recommendations to suggest additional videos and TV shows to their users based on their viewing history.
• Spotify finds patterns in musical tastes and recommends similar songs.
• My daughter says TikTok is amazingly good at finding relevant content for her. 

The goal in all these cases is to keep the visitor engaged with yet another compelling piece of content on your platform. But this raises two critical questions: 

• How does the system know what to recommend? 
• What is the context of the recommendation? 

How content recommendation works

Content recommendation relies on data analysis to accurately predict what content a user is likely to engage with. In general, it collects data on user behavior, such as what pages they’ve visited, what they’ve clicked on and how much time they’ve spent on each page. It can then generate different kinds of recommendations, including: 

• Popular articles on the site right now. 
• Popular articles in a specific category.
• Popular articles by a specific author.
• Articles read by visitors who read the current article. 
• Articles that visitors with similar browsing histories have read.
• Popular articles for people with a specific job title. 
• Articles read by people who are like the reader. 
• Articles read by people in a specific geographic area.  

Each option might have a different use for various content or on distinct areas of your website. You’ll notice that some of them (like “most popular on the site right now”) rely on simple analytics, while others (“people like you like these articles”) are based on look-a-like modeling. 

Drive-bys vs. regulars 

If your site is like most, a lot of visitors read one article and then leave. Getting some of those “drive-bys” to stay for one more page view can make a huge difference in your site traffic. Good content recommendation is one way to address that issue. 

The trouble is that you don’t know as much about the drive-bys. They have no history on your site, so it’s harder to do look-a-like modeling. But there are some options. 

• You can use third-party cookie/audience data for however long that is still available. 
• You can use data from the HTTP header, such as geolocation or referrer. 
• You can rely on general site statistics from your other readers. 

You have many more options with your regular visitors. In addition to everything you can do with the drive-bys, you can make predictions based on their unique browsing history, for example: 

• Show content similar to the content they have already viewed (in the same category, by the same author, with the same tags or keywords, etc.) 
• Compare their browsing history with those with similar browsing history and show the most popular articles among that larger group. 
• If you have demographic data on your regulars (i.e., job title), you can show the most popular articles for people with that job title. 

Multiple audiences

Many sites have two or more distinct audiences: free users vs. paid users, or B2B vs. B2C prospects. If that’s the case for your site, keeping them separate ensures you make the most relevant content recommendations. 

Here’s why. Consider a site about medications with content for consumers and doctors. You want to segregate those stats to recommend doctor content for doctors and consumer content for consumers. 

How to classify content 

The magic behind content recommendation relies on classifying content to match your and the reader’s goals. Content can be classified in several different ways, such as: 

• Words in the title. 
• Keywords or tags. 
• Word density in the article. 
• Categories. 
• Author. 
• Long vs. short articles. 

How the content is classified might affect your use case. For example, if your site has long articles and excerpts, you might not want to recommend long articles to people who prefer to read excerpts. 

Types of content recommendation algorithms 

There are various types of AI-based content recommendation algorithms that you can use to improve your website. Here are some of the most common ones. 

Collaborative filtering recommends content based on the behavior and preferences of similar users. It analyzes the historical behavior of users and recommends content that users with similar preferences have interacted with.

Content-based filtering recommends content similar to the user’s previously consumed content. It analyzes the content of the page the user is currently viewing and recommends similar content based on keywords, tags and other relevant information.

Hybrid recommendation combines collaborative filtering and content-based filtering to provide more accurate and diverse recommendations. It considers both user preferences and the characteristics of the content being viewed to make better recommendations.

Popularity-based filtering recommends content based on the popularity of the content. It recommends the most popular content viewed, shared or interacted with by many users. Combining popularity-based filtering with other types – for example, this content is most popular among people with this job title – is a very powerful tool. 

Knowledge-based filtering recommends content based on user profiles and preferences. It relies on user data and feedback to provide recommendations that match the user’s interests, such as previous purchases, ratings and reviews. 

Reinforcement learning recommends content based on the user’s actions and feedback. It learns from user interactions and feedback to improve its recommendations over time. 

Dig deeper: The ROI of recommendation engines for marketing

Choosing a content recommendation engine

As mentioned above, it’s unlikely that any given vendor can provide all of these options. Think about how you want to deploy content recommendations on your site, given your audience, your content and the range of possible options and decide which methods are most likely to work for your unique situation. Take that list to potential vendors and try to find the best match. 

Be sure to put the reader first 

One of the challenges in creating a successful content recommendation strategy is to ensure you’re putting the reader’s goals first. It’s too easy to fall into the trap of thinking about what you want the reader to do to promote your business model.

Instead, put yourself in the reader’s shoes and design your content recommendation strategy around what will help the reader find the content they want to find. That will be the best for your business in the long run. Addressing the reader’s needs will increase engagement, which is the primary goal. 

The post How to increase website engagement with content recommendations appeared first on MarTech.

When creating a ‘golden record’ ruins the customer experience 

Sometimes, stitching together all of a customer’s information into a single profile can accidentally interfere with your use cases. Let me illustrate.

While planning a family trip, I added my daughter Anne as a guest on the reservation through her personal email address. But she received a reminder about the trip from the travel company in her work email, which made her nervous. Why did they send the reminder to her work email? Who told them about her work email?  

Near as I can tell, this is what happened. Anne had created an account with the travel company using her work email for a work-related event. Somewhere along the way, the travel company added her personal email to that profile. When I added her personal email to the guest list, the travel company attached that action to her profile, so when it came time to send out a reminder, it used the default email in that profile, which was her work address. In other words, in an over-zealous attempt to create a “golden record” for Anne, they forgot the purpose of the use case: to send a reminder to the guest email that’s entered for the event. 

Take another example. Joe is a good customer. He’s an office manager, and he buys things from your store for his company. But he has a side hustle and buys many of the same things for personal use. He keeps those accounts separate, using separate email addresses. Merging those records doesn’t help your relationship with Joe. It annoys the heck out of him and gets him in trouble with accounting. 

Dig deeper: The myth of the single customer record

And then there’s my experience. I work as a consultant for many different companies. Sometimes I need accounts on the same service for different clients on different email addresses. Some services won’t allow a customer to have multiple accounts with the same phone number for two-factor authentication. So I must find a workaround that doesn’t help the service provider or me. 

These are all examples where merging records around a person can ruin a customer experience. On the other hand, there are instances where you better merge the records. For instance, if you’re a restaurant delivering food and know that Sam has an allergy, you must ensure that information migrates across all Sam’s accounts. 

Merging customer records: When to do it and how

The bottom line is clear: use cases are more important than identity. But how do you know when and what to merge? I’ve created two frameworks to work through these issues: the device framework and the person framework. By thinking through each use case with both frameworks, you can develop the correct procedures for merging records. 

Device framework 

The device framework is how most people work through customer data issues. 

Device profile: A device makes a request to your site. Your CDP creates a profile for that device and collects information about it. At this level, you can segment on things like operating system, geography, screen size, etc. 

Activity: If that device makes multiple requests, you can enrich the profile with other information, such as the kind of content accessed. With this activity information, you can segment on things like “likes videos” or “accesses tax content.” 

Identifiers: Some of the device’s activities help to narrow down who is behind that device. For example, a device might make a request to your site after clicking on one of your emails. That helps to create narrower segments and, in some cases, helps you to identify the person. Identifiers can be used to create powerful segments, like “everyone who is registered for our e-newsletter.” 

Person: Some identifiers make a strong connection to a person, while others only hint at the person’s identity. As you collect identifiers, you can sometimes resolve the profile down to a particular person with more or less certainty, depending on the nature of the identifiers you have collected. Once you have a profile identified with a person, you can develop use cases such as presenting renewal offers near expiration. 

People

The person framework helps you avoid the abovementioned problems, like Anne’s concern about misusing her work email or my troubles with two-factor authentication. This framework requires us to step out of a data-centered world and think about the real lives of actual people. 

Person: Rather than starting with a device profile and trying to resolve it down to a person, we start with a person and imagine how that person behaves in the real world. Let’s return to Joe, your good customer who purchases office equipment for work and his home business. 

Devices: Joe has two phones: one from the office and one for personal use. He’s careful to do office work on one and home/personal work on the other. Joe also has an office PC but a Mac at home. Again, he uses one for office work and the other for his own ventures. 

Identifiers: Joe is cautious about keeping things separate. His office email is for office work, his personal email is for friends and family and he has another email address for his side hustle. Joe does not want these merged or confused. 

Personas: Rather than thinking of Joe as a single person, you have to think of Joe’s three distinct personas: Office Joe, Personal Joe and Side Hustle Joe. 

Dig deeper: 19 CDP use cases that can annoy or engage your customers

Using these frameworks for your use cases 

Now that we have the basics let’s take one use case and work it through both frameworks. The use case is: “Send relevant job listings to all mechanical engineers who opt into our job postings email.” 

Device framework 

The top of the device funnel doesn’t help much with this use case because we can’t identify mechanical engineers by what kind of device they use. Once we get to the activity level, we can find profiles that frequent content relevant to mechanical engineers.

We can use on-site quizzes or simple questionnaires to gather identifiers. In this case, job title. Once we have the job title, we can create a segment of mechanical engineers and promote the “sign up for job listings for mechanical engineers” email list. 

That’s good enough for this use case. We don’t need to resolve identity down to the person, although a name might be suitable for personalizing the emails. Resolving things down to the person might create a problem, as we’ll see. 

Person framework 

Julia, our mechanical engineer, works for a company that doesn’t take kindly to people looking around for new gigs. The IT department monitors all the emails that come to office addresses. Because of this, Julia is careful to keep her work and personal lives separate. 

While she only has one laptop, she does all her office work in Chrome and all her personal browsing (from home) in Firefox. She signs up for the job posts email on her personal account, but not on her work account. 

If an overzealous data scientist merged these two accounts into one profile for Julia and started sending the job-post emails to Julia’s work address, Julia would not be happy. 

Rethink profile merging with these frameworks

People are more complicated than your data structure recognizes, so it’s essential to view your use cases from two perspectives: 

• From the data side (the device framework).
• By imagining the life experiences and concerns of real people who often act online through different personas. 

Make sure you structure your data, merge rules and use cases to allow people to act within whatever personas suit them. Don’t try too hard to create a single profile for each person in every case. 

The post Why and how you should rethink profile merging appeared first on MarTech.

If you’re considering a CDP, there are a lot to choose from, and they come in several different flavors. The unique quirks of any given CDP are usually determined by its origin story. Most CDPs started as something else and tacked on additional services to become full-fledged CDPs. The one that started as an email service provider (ESP) will be a different animal than the one that started as a recommendation engine. They also differ in whether they focus more on B2B, B2C, retail, publishing, etc. 

One way to cut through the fog is to distinguish these services by their back-end and front-end components. 

Back-end vs. front-end

Back-end components include the technical infrastructure and processes that are used to collect, store, harmonize, and manage customer data. This category typically includes data integration, warehousing, governance, and security features. The back-end component is responsible for ensuring that customer data is accurate, complete, and accessible, with the goal of merging disparate records from multiple sources to create a single customer view. 

The front-end component of a CDP can be divided into marketer-facing and customer-facing features. The marketer-facing side would include data visualization and reporting, while the customer-facing side might include recommendation engines, paywall management, and custom content displays. 

Some CDPs are almost exclusively back-end, with almost no customer-facing front-end features. Other CDPs include lots of front-end “activations.” To make it more complicated, all of these functions are available from stand-alone, dedicated services. 

The trick to evaluating a CDP is to figure out which components are necessary for your use cases, and which need to be part of the CDP itself. 

For example, a CDP might have a built-in ESP. That may or may not be a good thing for you. If one of your use cases requires you to send an email the moment a user takes an action on your website, you’ll either need the CDP to be able to send the email, or you’ll need a real-time connection to an external ESP. 

It’s helpful to think of a CDP the way you might think of a vacation resort. The resort owner wants to be able to say that the resort has some activity, like a water slide, so they build a token water slide on the property. It’s not going to be as good as the dedicated water slide down the road, but it’s also not down the road. It’s right there on the resort. 

In the same way, the ESP that’s built into a CDP is probably not going to have as many features as a dedicated ESP, but that doesn’t matter. What matters is which solution fulfills the requirements of your use cases. 

To make it even more complicated, there are a lot of “CDP-like” services that do some of the work of a CDP. 

To navigate this confusing mess, consider a few use cases and see how the back-end vs. front-end metric can help. 

Recommendation engines for content

Adding customized recommendations to an article on your website can enhance a visitor’s experience with your brand and increase page views. 

The functionality required by that use case depends on what data the recommendation engine will use. 

If you want to recommend articles based (at least in part) on which e-newsletters the customer receives, or which products the customer subscribes to, you’ll need a back-end connection with the ESP and/or the fulfillment system, and you’ll need the ability to merge the user’s online profile with that data. But if you only want to make recommendations based on the user’s web behavior, you don’t need that back-end function, and you might not even need a CDP. Many stand-alone recommendation engines can handle that. 

Questions to ask: 

• Does this use case require back-end data management? 
• Is the CDP’s front-end function good enough, or do I need a dedicated service? 
• Does the CDP integrate with that dedicated service? 

“Customers who bought this…”

In the retail space, vendors want to provide product recommendations, which can increase the value of each order. 

If the recommendations are based (at least in part) on the customer’s order history, the recommendation engine needs that back-end data. If the recommendations are simply based on averages across all customers, specific information about the customer’s purchase history is irrelevant. 

Managing a paywall

Publishers who don’t wish to rely exclusively on ad revenue to fund the creation of their content may offer access to premium content for a fee. This requires the creation and maintenance of accounts to manage access to this content. 

In many cases, those accounts will need to be coordinated with other accounts, such as a magazine subscription. For example, a magazine subscriber might get through the paywall for free, or at a discounted rate. In that case, the paywall management system will have to integrate with back-end data from the magazine fulfillment system. 

Landing page optimization

A/B or multivariate landing page tests can dramatically increase the success of an online store, online forms, and e-newsletter sign-up pages. Services that facilitate the creation and deployment of such tests usually do not distinguish between customers and non-customers, and that seems to work for most situations. In those cases, you don’t need a CDP. 

However, if you have reason to believe that your customers are significantly different than the average web visitor, you might need your landing page optimization calculation to show different stats for different groups. 

For example, a website with medical content might have a split audience that includes medical professionals and ordinary citizens. You wouldn’t want the results of an A/B test on a landing page for a report written for doctors to include stats on how everyone else responded. In this case, back-end information on the audience might be crucial. 

Dig deeper: What is a CDP and how does it give marketers the coveted ‘single view’ of their customers?

Surveys

Surveys can help you understand your customers, which can help you provide better service. Many CDPs can manage surveys, but very few CDPs can compete with the functionality of a dedicated survey platform. How does this affect your evaluation of potential CDP vendors? 

Questions to ask: 

• Will my surveys be enhanced by incorporating back-end customer data? (E.g., not asking things you already know, or asking different questions to different audiences.) 
• Is it important to be able to extend the survey process over time through progressive profiling? 

Building a worksheet

I hope these examples have prompted you to imagine a worksheet somewhat like this. 

This is an overly simple example, but you can use this general idea to customize a worksheet for your specific requirements. 

The key is to start with use cases and think them through in terms of front-end and back-end functions, also considering 3rd-party alternatives. The more your use cases require back-end functions, the more you’re likely to need a CDP. And once you’ve created this document, it will make the RFP/discovery process much easier. 

The post How to create a CDP worksheet from your use cases appeared first on MarTech.

“I’m sure I told you that!”

It’s also a problem in business. It’s very easy to assume that everyone else knows what you know. Here are some examples of where this particular bias can crop up in business situations, along with some proposed solutions. 

Dig deeper: How marketers can use cognitive biases to influence customer decisions

Customer service

My friend Ralph had a job at a fast-food restaurant in high school and he would sometimes complain at the lunch table about dealing with customers. Someone would ask if they could get a complimentary cup, and Ralph would get frustrated and point to the obvious sign that said “no complimentary cups.” 

The thing is, the sign is very obvious if you’ve worked there 15 hours a week for three months. It’s not as obvious if it’s your first visit. You can’t expect people to read every sign everywhere they go. 

Solutions 

• Regularly remind your staff that they have special knowledge and familiarity that your customers don’t have. 
• Find a way to track where customers are getting confused and either find a better way to communicate with them or amend your policy to fit their preconceptions. After all, what’s more expensive, giving away a free cup or having frustrated staff and customers? 

Website design

The curse of knowledge also interferes with web, app and ecommerce design. What’s obvious to the programmer, or the designer, is not necessarily obvious to the customer — especially those “intuitive” things we’re all supposed to know somehow. 

When I got a new phone a while ago, I had to look up instructions to change some of the settings and some of them started with something like “go to your home screen,” which just made me have to look up “where is the home screen on a Pixel?” 

Don’t assume your customers know what you know. 

Solutions 

• Where possible, use the standard features everyone is used to. Or in other words, when in doubt, copy Amazon. 
• Before you roll out a design change or a new feature, have several people who know nothing about the project review it. 
• Have Apple users test your Android instructions and vice versa. 
• Create reporting mechanisms to track problems. If you expect people to follow a certain path, check to see if they’re behaving the way you expected. 
• Make it easy for customers to report when they’re confused or frustrated. 
• Reinforce the attitude that if a customer misunderstands, you have not communicated well enough. 

Dig deeper: 4 cognitive biases and psychological drivers for influencing behavior

Project management

I’m afraid I’m guilty of this one. “The updates are always in that spreadsheet I shared with you during the kickoff meeting. Didn’t you bookmark it?” 

Just because you said something doesn’t mean people heard you, understood you or took action based on what you said. A project manager is in the project every day. It’s obvious to the project manager that we need X before Y, that we already decided on 1 vs. 2 and that Z is due on Tuesday. It’s not obvious to people who have other worries and responsibilities. 

The curse of knowledge can also go the other way, where the technical people are aware of a problem, but the project manager is out of the loop. 

Solutions 

• Overcommunicate. Yes, it’s annoying, but it’s better than miscommunication. 
• Include links to important project documents in your regular updates. Make sure people know where they can find updates. 
• Project managers should check in with the technical people to hear their perspectives on looming problems. 

Buzzwords and industry lingo 

Do your salesmen speak in incomprehensible gibberish because they use buzzwords and acronyms? They might think it makes them sound like they know what they’re talking about, or maybe they’re so used to the buzzwords that they can’t help it, but it’s turning off many of your prospects. 

Solutions 

• Make it a habit to use the full name for something before you use the acronym. 
• Stop yourself when you use an industry buzzword and find another way to say the same thing. In addition to not sounding like a tool, you’ll expand your vocabulary and end up understanding the concept better. 

Taking offense over breaches of etiquette

I don’t play golf, but I understand there are a lot of rules for business meetings on the golf course. One of them is that you don’t talk business while you’re playing golf. I didn’t know that until yesterday, so if someone invited me on a golf trip, I might mess up and talk business on the 7th hole. 

There are lots of situations where we fear being the “ugly American” who doesn’t know the local customs, but the problem can go the other way as well. Just like the foreigner can think the American is being rude when the truth is that he simply doesn’t understand the expectations, we can mistakenly assume someone is being rude when they don’t understand our norms. 

Solutions:

• Never assume malice when ignorance is a good enough explanation. 
• Before you do something new, take a few minutes to learn the rules, including the social norms. 

It cuts the other way as well 

You don’t want to assume that people know things you know, but it can be annoying if you go too far the other way. For example, I recently heard a vendor speak to an association of publishers. These folk probably know more about subscriptions than anybody on the planet. The vendor spent five minutes explaining what a subscription is. That can be annoying. 

In other words, while you don’t want to assume everyone knows what you know, you also don’t want to treat educated, professional people like novices. It can be a hard balance to strike, but if you frequently remind yourself about that pesky “curse of knowledge,” you’ll do great. 

Dig deeper: Using psychology and better data practices to get customers closer to purchase

The post How ‘the curse of knowledge’ may be hurting your business and what to do about it appeared first on MarTech.

• Buying something that’s not exactly what you want and working around its shortcomings.
• Building your own custom system.
• Buying something you can customize. 

Beware of the dangers of either of those custom options. Think long and hard about what you’re getting into. 

In this article, I’ll explain some of the common pitfalls and provide a checklist to help you with the decision. 

Off-the-shelf doesn’t always work 

Many industries and businesses have unique requirements that don’t fit into a standard model. For example, many online stores don’t provide all the variables necessary to manage subscriptions. 

Your industry might require special reporting, have unique identification requirements, or be subject to special auditing rules.

Commercial software vendors may never have heard of your specific requirements or don’t consider companies with needs like yours a large enough part of the market to worry about. 

That might suggest you need a custom solution. And building a custom solution has a lot of benefits.

The most obvious is that it allows you to build exactly what you need and nothing more. It gives you more control, but that control brings costs and liabilities you should bear in mind. 

Dig deeper: The great martech debate: Build vs. buy

The danger of ‘build your own’ 

After you’ve been through 14 demos of products that simply don’t accommodate your business model and your requirements, it’s very tempting to say, “let’s build our own!” 

Before you do, consider these potential pitfalls. 

• Congratulations, you’re now in the technology business. Now you need to worry about changes to operating systems, security threats, new devices and protocols, emerging technologies and trends, and you need to retain the staff to stay on top of all those things. Also, IT is not one discipline. You’ll need to maintain competency in many different areas. 
• You have two options. Hire your own developers, or outsource the work to a development shop. In either case, developers are expensive, and if you don’t understand the technology you want to build, it can be very difficult to find the right developers (or the right shop) at a fair price. 
• “Hiring staff” doesn’t solve the problem. A new team must learn your development process, business strategy, and systems. 
• How to build this new wonder is just as important as what you want to build. Is learning that new discipline worth the cost? 
• Your additional costs don’t end with new staff. You’ll need development and staging servers if you choose to do the work in-house. You’ll need test workstations. The hardware and hosting requirements can add up. 
• Being in the IT business means you’ll have to budget your IT expenses against unknown technology changes or problems. Apple may issue an update that breaks your system. Colorado may pass a new privacy law. Paying a monthly fee to have someone else worry about that can free your staff to stick to your business. 
• The type of developer you need to design a custom system is not necessarily the same person who’ll want to maintain it. The first is a creative thinker who likes challenges. The second is a manager who resists change and likes order and consistency. 
• Even if you build your own custom software, you will likely need to integrate with one or more external systems, like a payment gateway or an email service provider. These integrations will require periodic updates as well. 

The additional dangers of ‘buy and customize’ 

Some of the problems above apply when you buy and customize a third-party solution, but there may be others when you try to customize off-the-shelf software. 

• Does your customization void your warranty or your service agreement? Will the provider still give technical support after you’ve customized their system? 
• When the app you purchased does an upgrade, it won’t have your customization in mind, and your add-ons might not work anymore, or they may require substantial re-engineering. It might not even be clear why your customization doesn’t work with the new version. (I remember one of my developers spending a day discovering that our script didn’t work because one piece of software changed the way it managed line feeds in an XML document.) 
• The app you purchased probably integrates with other systems. Will your customizations work with those integrations? 
• What do you do when the third-party software provider you’ve purchased goes out of business? What are your options to acquire and maintain the application yourself, and how expensive is that? 

Dig deeper: How marketers can build a data-driven technology stack

A build-your-own checklist 

Before you build your own or buy and customize, go through each of these carefully as a gut check. 

1. Explain the problem and why and how your current solution is not meeting expectations 

Writing out the “why” of a customization can expose whether it’s truly required. 

A company I knew used to run two different fulfillment account systems because one of their 50+ titles had to have distinct reporting. Or so they thought. Then one day, while reviewing company operations, the fulfillment division said, “It would be so much easier if we didn’t have to use two systems.” 

The company’s president responded, “I always thought that was your requirement.” 

Whatever operational requirement suggests a customized solution in 2022 might not apply in 2024. Make sure you keep a record of these things. 

2. Research other solutions 

Surely you’re not the only company with this problem. 

How are your competitors dealing with it? Can you license their solution? 

3. Distinguish necessary from whimsical customizations 

The “customers” for your new software are both external and internal. Make sure you understand the internal processes that are affected by this new technology. 

However, it’s one thing to accommodate a business requirement. It’s another thing to try to make all your staff happy. Remember, computers are very good at doing one thing a million times. Marketers want to do a million things at one time. 

Every customization comes with cost and risk. Keep them in check, and consider the ROI on every proposed customization. Realize that the investment in your customization includes the upfront cost and the ongoing maintenance and update costs. 

Be very specific about the cost of the customization and the reasonably expected benefit. As my friend Frank used to say, “we’ll do all this work, and all this setup, and we’ll get one order.” 

Finally, don’t confuse “customization” with a wish list. Each customization has to justify itself. 

4. Reflect on the virtue of simplicity 

Apple and Kindle radically reduced the complexity of magazine fulfillment. Their systems don’t account for many of the functions that a standard fulfillment house would consider table stakes. 

Was this arrogance on the part of Apple and Kindle? Or did they decide that all those bells and whistles weren’t worth the trouble?  

When you’re considering a “nice to have” function or feature, be sure to compare that with the elegance of simplicity. 

5. Document your customizations

You’re very likely to lose the developers who created your custom system, and the people who come afterward need to know how things work. Make sure everything is well documented. 

Also, to the extent you need to integrate your customizations with another system, good documentation will be key — for your developers and your partners’ developers. 

The post Marketing software: Think three times before you customize appeared first on MarTech.

Whether you’re just starting or still contemplating a relationship with a CDP provider, you’ll regret it if you don’t take some common implementation issues into account.

Read through these common CDP mistakes carefully, and have an honest — and skeptical — conversation about each one. (And be sure to share this document with your data team.)

Mistake 1: Rushing it

It’s good business to get early wins and show a quick return on investment, but a NASA engineer I grew up with used to say, “We’re in a great big hurry, so go slow, take your time, and do it right the first time.” 

Undoing a catastrophe costs a lot more than taking your time to get your use cases in order, documenting assumptions, testing hypotheses and thinking things through.  

Mistake 2: Having no concept of identity

The basic function of a CDP is to create the mythical “golden record” for each of your customers. In order to do that, you need a way to merge records from different sources. On what basis will you merge those records?

Each person has several email addresses (which change over time) and uses several devices (which are sometimes shared, and also change over time). What ties those data points together in a way that points to a single person?

Nothing.

Or at least nothing perfectly. Get comfortable with that reality, or you’ll drive yourself crazy.

Consequently, it’s a mistake to build your strategy around identity. You’ll never have one record for one person, but for many use cases, it simply doesn’t matter that you don’t. Develop your use cases and build your concept of identity around what’s necessary to drive the use case — not the reverse.

In some cases, the user’s email address will be the best choice. Other options include a unique third-party ID, your own unique ID, or even a postal address.

Whatever you use, it needs to fit in with a long-term customer strategy you can track over the customer’s entire lifecycle. But it won’t be perfect no matter what you do.

Dig deeper: 19 CDP use cases that can annoy or engage your customers

Mistake 3: Not taking into account other ‘sources of truth’

CDPs sell themselves as the single source of truth for your customer data. That doesn’t mean you have to use them that way. It’s possible that you’ll have different sources of truth for different use cases. 

For example:

• Your ESP might be the source of truth for e-newsletter sign-ups and opt-outs, even though you also have that information in your CDP.
• Your fulfillment system might remain the source of truth for subscription information even though you import it all into your CDP. 

Along those lines, it’s a good idea to tag or label information so you know where it came from. 

Dig deeper: What is a CDP and how does it give marketers the coveted ‘single view’ of their customers?

Mistake 4: Overlooking analytics

People say “what gets measured gets done,” so it’s important to measure and report on the things that drive your business. We’re inclined to think that measurement should be simple when we’re dealing with data and computers, but nothing could be further from the truth. Just look at the mess in online advertising.

When dealing with a CDP, there’s a lot of data exchange back and forth between different systems. But you don’t always get a 1:1 connection. So even though you’re importing all your customer data from your disparate systems into a CDP, you need to ask which measurement of that data is the most relevant to your business. It might not always be the CDP. 

Mistake 5: Organizational silos and lack of internal buy-in

A CDP often falls under the purview of the marketing department, even though it requires heavy IT involvement.

Stop and ask yourself how well your marketing department gets along with your IT department. Is that going to be a problem? (Answer: probably.)

Don’t forget that your own organizational silos might become your biggest barrier to success.

When you run into a glitch, you don’t want all your directors defending their own vendor relationships and pointing fingers at everyone else. You need to create an environment where all the affected parties have a stake in the success of the CDP, so they keep one another informed.

This is particularly important with your development and operational people. Make sure they’re okay:

• With the technology.
• How it will affect page speed.
• How it will integrate with existing systems.
• Whether it will impact latency.
• How your web page loads.

If you don’t involve IT up front, blame yourself if they become blockers later.

Dig deeper: 5 ways marketing and IT can work better together

Mistake 6: Having nobody in charge

A CDP will affect several departments in your organization, and while they all have to buy in and cooperate, you still need a single project manager. 

“Shared responsibility” can’t mean “nobody is in charge.” 

Mistake 7: Forgetting time-based data capabilities

Some CDPs give a “right-now,” snapshot view of your customer information, which is good for many use cases, but a big problem for others. 

If you run a subscription site, you want to track and report on a customer’s status over time. 

If that’s important to you, make sure your CDP can manage that, and make sure to incorporate that into your data structure.

Mistake 8: Not looking into capacity issues

If you have 25 brands, and they all feed into one email service provider on an as-needed basis, you might hit a hiccup from time to time while doing an update.

But if you consolidate those 25 brands into one customer database, which sends the complete file every day, you might run into capacity problems you didn’t expect.

The point of a CDP is to provide a central place for your customer data. You should ensure that the CDP can handle all those connections coming in.

At the same time, you also have to be aware of the big connection going back out – from the CDP to all those other services. Can they handle the volume?

Mistake 9: Believing the CDP’s claims that they can ‘integrate with everybody’

There are so many vendors doing so many things, it’s unreasonable to expect your CDP to have an existing relationship with every vendor you use. But it’s dangerous to assume they’ll play well together.

If your prospective CDP does not already have experience with one of your vendors, be very cautious. Integration teams and universal APIs are no substitute for diligent testing. Make sure your CDP can work with all your vendors.

Mistake 10: Not confirming how you will be charged

Billing problems probably won’t surface during implementation, when you’re on your honeymoon with the CDP, but think carefully about how they intend to bill you.

Make sure you’re being billed for things that are driving your business and contributing to success — not just for “total rows of data,” or something you don’t actually care about.

Along those same lines, make sure there’s a way to purge old data that isn’t relevant anymore.

The post 10 CDP implementation mistakes to avoid appeared first on MarTech.

On the one hand, many consumers don’t want websites to collect their data. On the other, they want us to show things that are relevant to them and not show ads for the boot they just purchased. Both require that we collect their data.

We can’t expect consumers to understand the technology that goes on behind the scenes, but we can keep track of what they consider creepy and what they consider cool and create a user experience they will appreciate and enjoy.

This calls for a change of attitude. Instead of thinking about data as a way to increase sales, think about it as a way to create an amazing customer experience. Set aside your KPIs for a minute and ask how consumers want you to use their information for their benefit. Make it your ambition to earn the right to store customer data by using it in a way the customer likes. 

After reviewing customer surveys about creepy and cool marketing, I’ve come to the following general observations, which can help you create CDP use cases that your customers will love. 

Let’s start with some creepy and potentially annoying use cases you may want to avoid.

Creepy

1. Using location data

For example, “Hey, you’re close to our store. Come in now for a free gift.” This is too much like stalking.

2. Apps that listen to what you’re saying

I don’t know if this happens in the real world, but there’s a perception that if you talk about getting a new pair of sneakers and your phone is nearby, you’ll get lots of sneaker ads. I’m pretty sure this is just confirmation bias, but it’s good to keep in mind that people find that sort of thing creepy. If that tech is or becomes available, stay away from it, or anything that reinforces that sort of impression.

3. Using third-party data

People have a decent idea of what personal information they’ve given your site and your brand. When you use information that’s been collected from other sites, that’s creepy. I know you don’t want to hear that because third-party data can be valuable to sales and marketing. It’s also creepy.

Potentially annoying

4. Inferring a habit from a single transaction

It’s easy for marketers to assume that if someone purchases a cat toy, they probably have a cat. But people also give gifts. It might be wise to hold off on your conclusions until you have a little more certainty. One swallow doesn’t make a spring.

Along those lines, delay making too many conclusions based on limited user behavior. After a user has visited your site for a while, it’s reasonable to customize their experience based on that data. They know you’re tracking what they’re doing, but if you customize too soon, you can get it wrong, which becomes annoying. I don’t know exactly where to draw that line, but this perspective deserves a place in your deliberations.

Dig deeper: How marketers can use behavioral data to improve customer experiences

Now, here are cool use cases you need to leverage more often.

Cool

5. Recommendations based on usage or past purchases

Think of Amazon, Netflix and Spotify. “People who bought/viewed/listened to this also liked this other thing.” Such recommendations can be very helpful. I love it when Spotify tells me about other artists I might like. However, this use case might only apply to situations where there is a very large catalog. It’s not so helpful for a site that only has a small number of products.

6. Loyalty programs

They’re not just for airlines any more. Loyalty programs have become more common for all kinds of products and services. The basic idea is that you reward people who are good/repeat customers.

7. Points and rewards

I don’t like point and reward systems, but I’m a focus group of one. The majority of people do like this sort of thing, so you should consider how it might apply to your business. However, what will you do with the people like me who don’t like them? If 70% of your visitors like something and 30% hate it, it might be prudent to allow people to opt out. If you don’t, it moves your point system to the “annoying” category for that 30%. 

8. Personalized service

Along the lines of the previous point, people want you to treat them as individuals — but only if they’ve volunteered the information that allows you to do that! Don’t take liberties. Personalize the experience based on first-party data you’ve collected. Make them feel known, valued and appreciated as an individual.

9. Discounts

You can tie in your discount program with points and rewards. Provide better discounts to people who are more loyal and engaged.

10. Customized coupons and free gifts

“Customized” means you have enough data to make the right inference. Remember the cat toy that was given as a gift by the non-cat owner? Don’t offer that person free guides on cat care. 

11. Contests

People enjoy free gifts, but they enjoy them even more when they feel they’ve done something to earn them — like winning a contest. If your business lends itself to this sort of thing, think of ways you can collect first-party data when people enter a contest. 

12. Exclusive and early access

If you produce timely content, early access for loyal members is a big benefit. If your content is not as time-dependent, reserve some of it as exclusive access for your best customers.

13. Communicating in the channel they prefer

Some of your friends and family respond to texts, some to emails, some to Whatsapp and some even pick up the phone. There are many options for messaging and people have their preferences. Allow your customers to choose how you will contact them.

14. Abandoned cart reminders

I don’t like these, but a lot of people do. Try them, but make sure to allow people to opt out of abandoned cart reminders without opting out of any of your other emails.

15. A chance to win a prize

People love prizes and they love feeling lucky. Your site visitors will hand over their personal information in exchange for the chance to win something.

16. Focus on retention

It’s cheaper to keep a customer than to acquire one, so ensure your use cases are geared toward pleasing your loyal and engaged customers. The last thing you want to do is make it seem as if it’s better to be a stranger than a friend. 

17. Be proactive about access

If people are paying for your content, reach out to them if they’re not accessing it. Keep track of whether paying subscribers are opening your emails and logging in to your site. If they’re not, contact them. It’s better to solve the problem now than to wait until they don’t renew because they’re not using your service.

18. Foster community

A shared interest is a pathway to friendship. If you run a specialty site, you have a great opportunity to create a community around that topic. But be clear-eyed about the commitment; it’s a lot of work. Moderating the comments on a discussion board is time-consuming and expensive, but if you can create a community where people feel valued and welcomed, it might be worth it.

19. Don’t neglect pure entertainment

Depending on your audience, you probably don’t have to make everything serious all the time. Sometimes people want to play. Games can be a great way to engage your customers and a great opportunity to collect first-party data. 

Dig deeper: Customers aren’t satisfied: Fewer than 35% say they’re happy with brands

Don’t forget incognito browsers and ad blockers

Some of the adtech that allows you to capture user data is thwarted by incognito browsers, security plugins and so on. About 26% of internet users blocked ads in 2019 and that percentage continues to grow. Cheetah Digital reports a 50% year-over-year increase in the use of incognito mode. 

You can’t blame them. Some marketing techniques are obnoxious. Also, people like to get free stuff and they want to find the secret entrance.

Don’t make this a contest, or an adversarial relationship. If your business model requires you to charge people for access to your content and visitors are trying to find ways around that, don’t chide or accuse. Explain it in a friendly way.  

“We know that some websites provide content for free. We’ve chosen a different model that allows us to provide personalized service to our subscribers. Please log in [turn off your ad blocker, use a regular browser, etc.] to view our content.”

Summing it all up 

If I raise chickens and you grow wheat, I have more chickens than I need and you have more wheat than you need. It’s in both our best interests to trade. 

Think of data the same way. You have a service to provide. Your customers have information. Make it a fair trade that’s beneficial to both of you. 

The post 19 CDP use cases that can annoy or engage your customers appeared first on MarTech.

CDP pricing is complicated for two reasons. 

• CDPs do different sorts of things. 
• CDPs have different “origin stories,” and their pricing is often a relic of what they used to be and do. 

A CDP that started as an email service provider might base its price on events, like emails sent, page views, clicks, etc. A CDP that originated as an analytics platform might base its price on total web traffic, while a CDP that used to be a data warehouse might set its price by how many profiles are under management. 

There are many other price models, including by:

• Profiles of “known” individuals. 
• The number of user records in the database.
• API calls and the volume of incoming data.
• The components used, like the data clean room or the built-in ESP.  

You will have to get a custom quote from each vendor you’re considering, but the quote won’t tell the whole story. 

Why the CDP’s origin story matters

MarTech defines a CDP as “a marketer-managed system designed to collect customer data from all sources, normalize it and build unique, unified profiles of each individual customer. The result is a persistent, unified customer database that shares data with other marketing technology systems.”

Most CDPs started off as something else and added or acquired functionality to become full-fledged CDPs. Knowing a CDP’s origin story gives you insight into:

• How the application is priced.
• The company’s culture and biases.
• How they’re likely to view their work.
• Their services.

If there’s a conflict, it can become a hidden cost in added development time and workarounds. A good fit can be better than a good price. Vendors that specialize in a CDP tailored for your business and industry may be ideal in the long run. 

The ‘best-of-breed’ decision

If you’re in the market for a CDP, you probably have solutions for some of what CDPs offer. For example, you might already have a service to manage a paywall, which most CDPs can also do. 

Early on, you’ll have to make the best-of-breed vs. Swiss Army knife choice.  

Some CDPs stick to a narrow focus. They provide a consistent, single view of the customer (which is a myth — but never mind that for now). These best-of-breed CDPs rely on other applications to send emails, cleanse data, create interactions on the website, build forms, provide content recommendations, and so on. They position themselves as “best-of-breed” in their narrow focus and expect you to use other solutions for other tasks. 

Swiss Army knife CDPs incorporate some or all of the functions mentioned above into their solutions. The drawback? You may use functionality provided by your CDP vendor when a solution offered by another vendor dedicated exclusively to providing that function or service would be a better choice. Let’s face it, the can opener on a Swiss Army knife isn’t best-of-breed, but it will get the job done when it’s the one you have in your pocket!  

There’s no simple solution to this choice. It’s tempting to think it’s wise to use best-of-breed solutions for every function. But, aside from the fact that “good enough” is often good enough, that can be impractical. 

• There’s no guarantee all these services will integrate seamlessly. 
• Contracting with multiple vendors may be prohibitively expensive. 
• There’s no guarantee these other companies won’t merge, change their focus, or go out of business. 
• What’s best-of-breed today may not be best-of-breed tomorrow. 

All of this is relevant to pricing because the cost of the CDP isn’t only what you’re quoted. You also have to consider what you can save by eliminating duplicative services (provided you can get out of the contract) or what you might have to add to get all the functionality you’re searching for.  

Here are two examples. CDPs that send email might save you the money you’re currently spending on an ESP. But a CDP that doesn’t have a clean integration with an essential service might result in development or middleware costs. 

Start with use cases

These and many other factors add complexity to CDP pricing. It depends on your size and the services you’re looking for, so you have to start the process by developing use cases. What will you do with a CDP and what return on investment are you hoping to get? Documenting these cases will help you list all the functions you require. 

With use cases in hand, you can add and subtract costs from a CDP bid based on what current services you can discard and what additional services you’ll need. 

Enough already! What’s a CDP going to cost? 

The minimum investment for a CDP is about $5,000 per month. It will go up from there based on volume and so on. It’s quite easy to get into multiples of six figures annually or more, so you should only invest in a CDP if your use cases are likely to result in substantial savings or additional revenue. 

If the price tag scares you, don’t let that stop you from investigating. You might not need a full CDP. By working on your use cases and considering what functions are required to make them happen, you might discover things you can build yourself — or some “not quite CDP” solutions that solve your requirements. 

The best thing about considering a CDP is that it requires you to think about what you’re doing, why and what benefit those current or potential activities would bring to your company and your customer. That exercise can sharpen your focus, and you might discover revenue opportunities that make the price sting a little less. 

The post How much does a customer data platform cost? appeared first on MarTech.

It’s a lovely vision, but rarely achieved. And that’s perfectly okay. Most companies won’t achieve the goal of one record for each customer, but will find ways to cope with the limitations that prevent the creation of golden records.

Let’s use this common CDP use case to illustrate the complexity: Identifying customers among the hoards of anonymous visitors to your website. 

It’s a challenge. Anonymity was central to the internet’s design. And while there are lots of ways to identify anonymous website visitors, they all have their limitations. 

Imagine Robert Williams, our leading man and swing dance aficionado, interacts with Ella, publisher of (the fictitious, I believe) Ella’s Swing Dance Magazine.

Robert meets Ella on his commute to work. She tells him he ought to read her magazine. On his lunch break, Robert searches for the magazine website on the desktop he uses at the office. When Robert’s web browser makes a request to Ella’s Swing Dance Magazine website, Ella’s CDP puts a cookie on that device and creates a user profile. The profile includes the following information: 

Profile 1

IP address: 25.23.108.5
User-Agent: Mozilla/5.0 (Linux NT 10.0)
Referrer: https://www.google.com

The record might also include what pages were visited, and what type of content the visitor seems to prefer. The visitor is still anonymous to Ella’s CDP. The profile is one of the millions of unknown visitors.

When Robert gets home that evening, he types the URL of Ella’s website into his iPad. Her CDP dutifully puts a cookie on that device and creates a new profile. But on this visit, Robert decides to sign up for Ella’s free e-newsletter with one of his junk email addresses. The CDP captures the email address from the form submission and creates a second profile, which has more information than the first. 

Profile 2

IP address: 32.12.100.21
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6)
Referrer: [blank]
Email: bob2387@hotmail.com
Name: Bob Williams

However, nothing in this second records enables Ella’s CDP to conclude the records are tied to the same individual. The records were created on different devices at different times, and share no information identifying Robert. 

Two weeks later, Robert and Ella are jitterbugging at Mobtown Ballroom. Ella has a few copies of her magazine, and Robert takes one home. He signs up for a print subscription using one of the blow-in cards. Ella’s fulfillment service dutifully records this new subscriber data, which is then imported into the CDP, creating Robert’s third profile with still more information:

Profile 3

Name: Robert Williams
Address: 123 Main Street
City: Bowie
State: Maryland
Zip: 20715
Phone: (301) 555-1212
Email: me@robertwilliams.com

This profile has valuable information, including a new email address. But this profile has no data from online activity, so it doesn’t help with online ad targeting or customer journey data.  

Robert now has three profiles in Ella’s CDP. There’s no way to merge any of them. We know they’re all Robert. The CDP doesn’t.

Fortunately, Ella’s magazine has the good sense to include some special online content for print subscribers as a way to link offline and online behavior. A QR code printed in the magazine allows Robert to view a video on the website about the Travelling Charleston. Robert scans the QR code with his iPad. That takes him to the website, where the CDP recognizes the cookie it put on that device earlier.

Bingo! Now Ella’s CDP can merge the iPad profile (#2) with the subscription information (#3). Several good things happen as a result: 

1. Robert’s three profiles have been consolidated into two
2. Robert has become a known user in Ella’s CDP
3. Ella’s CDP knows that Robert uses two different email addresses
4. Robert’s subscription information (offline behavior) and the profile created when he accessed Ella’s site from his iPad (online behavior) are now linked. 

The record created from Robert’s desktop remains anonymous.

Looking for a CDP? Download our buyer’s guide today and learn everything you need to know.

Note that, in this scenario, Ella’s CDP has been configured to accept multiple emails in a customer’s profile. Some companies designate the email address as a unique field – allowing only one per profile. In that case, the records would not merge, and Robert’s subscription information would remain in its own profile, not connected to any online activity.

Will Ella’s CDP ever be able to attach Robert’s work computer to his online profile? Maybe. For example, if Robert opens one of Ella’s e-newsletters on his work computer, the CDP might (depending on how strict it is about such things) recognize that as Robert and merge the profiles. 

Identifying individuals from their online and offline behaviors and creating single records may seem complicated, but it’s quite a bit less confusing than what happens in real life. Consider the complexity added when Robert’s smartphone and home desktop are added to the equation.

Merging records: deterministic vs. probabilistic method. Which is right for you? 

The “golden record” that the CDP salesman is waving in front of you assumes that all these different sources of information can be merged, but they need to have a field in the record to merge on. What’s that going to be?

Most companies opt for an email address as the best piece of personally identifiable information on which to merge records. But as we’ve seen, and as we all know, people have multiple email addresses. They also change over time. 

If you stick with a strictly deterministic matching method, you’ll need to match a unique field (like an email address or a social media account) across multiple profiles to create your “golden record,” and you’ll inevitably leave some information behind.

There are other options. Some CDPs use probabilistic methods to merge profiles. That method enables you to match records that might otherwise remain distinct. But you risk incorrectly merging profiles and creating a customer experience headache.

(Read this article for an in-depth comparison of deterministic and probabilistic matching.) 

You can’t create a single record for each customer that covers all the chaos and weird realities of how people behave. What you can do, and what you must do, is decide where that matters.

There are use cases where improperly merged profiles yield very bad customer experience outcomes. Stick with deterministic matching in those cases, even though you’re going to lose some of the data on interactions with that customer. You’ll have multiple profiles for some individuals, many of which will remain “unknown.”

Other use cases are far more forgiving. If you want to create a segment of people who share a particular interest, you don’t need to get down to the individual. In these cases, probabilistic methods are sufficient. 

In any event, recognize that “golden records” are a nice idea, but you’ll never actually get there.

The post The myth of the single customer record appeared first on MarTech.