Customer Data Platforms (CDP’s) make it easier for companies to assemble, unify, and deploy their customer data. The previous article in this series described how they do it; let’s assume here that was enough to convince you to buy one. This article will discuss how to make a wise purchase.
The process isn’t much different from buying any other piece of marketing technology – or anything else, for that matter. The trick is to start by defining your goals, followed by specific use cases that support those goals. Then you define the system functions needed to support those use cases, evaluate alternative ways of fulfilling those requirements, make a choice, and execute your deployment. It all sounds so simple.
But the reality is more complicated. You probably have a sense of your corporate goals and marketing objectives, but it can be hard to assign priorities when limited resources mean you can’t do everything.
Similarly, you may know which broad use cases you want to support but not understand the details well enough to convert them into specific requirements. (After all, you haven’t done them yet: if you had, you wouldn’t need a CDP to make them possible.) And there are literally dozens of CDPs to choose from, each using different language to describe features that are sometimes the same and sometimes truly different. Just assembling a list of candidates can be an overwhelming project.
Don’t let the complexity scare you. The key to a successful CDP selection project is taking things one step at a time. Start with what you already know – your business – and then gather the additional information as you move ahead, using the knowledge gained from each step as a foundation for the next.
Here’s how that works in practice.
-
Define Your Use Cases
The true starting point is your business strategy, which drives your marketing goals, which you’ll translate into projects to support those goals. But most of that will already be thought through by the time you’ve decided you need a CDP. So you should be able to start your project by going directly to a list of problems you expect the CDP to solve. Typical candidates are:
– Get a complete view of customer behaviors across channels.
– Deliver accurate, consistent customer information to personalization systems.
– Generate customer lists to support targeted marketing programs.
– Build predictive models to select targeted messages for each customer.
– Pick the best offer to each customer during real-time interactions such as a Web site visit.
Another thing you’ll know at the start of the project is where your data will come from. Will it be order processing systems, your company Web site, advertising networks, mobile applications, call centers, sales automation, customer service, purchased lists, others, or all of the above? This matters because different CDPs support different data sources, so it can be an important filter to narrow your search.
-
Elicit requirements
Once you’ve identified the problems you want the CDP to solve, you can define the CDP functions needed to solve those problems. For example, the complete customer view requires connectors to different source systems, ways to map the inputs to a defined data model, processes to link records that belong to the same customer, a place to store the data over time, and access to the stored data by analysis tools.
You or someone on your team might already know enough to list these. If not, a little Web research will surely turn up requirements lists and descriptions of similar projects that can be mined to extract requirements. At this stage, your requirements don’t need to be precise technical details: you’re just looking for a list of functions the system needs to perform.
-
Look beyond technology
It’s tempting to jump from requirements into the actual vendor evaluation. After all, shopping is fun. But just as you have to ask whether your cat will really wear those argyle ear muffs, you have to ask whether your organization has the data, systems, skills, processes, measurements, alignment, and management support to make effective use of the CDP.
If not, the selection project can help to create the necessary conditions by educating potential users. But what really matters is building a clear understanding of existing conditions so you can create CDP plans that are achievable. In many cases, this will result in simpler requirements, which could lead you to select a different and possibly cheaper system.
-
Screen vendors
Armed with a practical understanding of what you want the CDP to do, you can now look at the vendors themselves. This is another incremental process: starting with relatively broad requirements, your first step should be to screen for vendors who support the data sources and general applications you need.
You can further screen on general factors such as industry experience, similar client sizes and skill sets, and supporting services. This should get you to a manageable number of options – say, five to ten – which you can then explore in more depth.
-
Assess vendors
The key to finding out which vendors can meet your needs is to focus on your specific use cases. When possible, define scenarios you want them to demonstrate, such as adding a new data source or setting up a marketing campaign. This gives a much clearer idea than canned demonstrations of what it would be like to work with the system in your situation. It also makes it easier to find and compare relevant differences between systems, as well as forcing the vendor to expose weak spots they might otherwise skip over.
Take this opportunity to extend your own knowledge by having each vendor explain the technical approaches used in each system. This will let you understand subtleties that are initially obscure but can ultimately have a big impact on how well the system works for you.
-
Make a choice
Finally, you’ll need to make a choice. Don’t rush into this: take as much time as you need to gather all the information necessary for a sound decision. Some buyers use a formal Request for Proposal and others don’t, but either way you’ll need to assemble a comprehensive set of questions for the vendors to answer. You’ll also need to give each vendor an accurate picture of your expected implementation so they can estimate costs and deployment effort.
Many buyers today do a proof of concept or pilot project before signing a contract. You might pay something for this but it’s an increasingly practical option because CDPs are designed for easy deployment. In fact, inability to deliver a proof of concept rapidly at a reasonable cost should be cause for concern.
-
Make it work
Buying the CDP is just the start of your project. Data sources, processes, applications, and users should have been identified as part of your selection process, so they should be already available when deployment begins. You’ll want to move quickly, work in stages, show some early success, and continue to expand use of the system. Applications for your customer data are nearly endless so there’s little chance you’ll run out of new things to do with your CDP. The real trick is getting started and finding a tool that meet those future needs.
