Implementing a CDP is a little bit like setting up a smart TV. If your goal is to binge watch “Stranger Things” or a trending new docuseries on the new big screen, you don’t need to immediately connect to every streaming service within minutes of opening the box. Likewise, implementing a CDP starts with deciding on a specific use case. You may not need all the functionality on day one, but it’s still there when you’re ready to explore more features.
The recognition that a CDP can be used to achieve a specific use case is an important distinction to make, even though it may seem counter-intuitive to the aspirational notion that a CDP’s purpose is to generate a 360-degree view of the customer – a single source of truth for customer data. Another counter-intuitive concept is that a CDP, from day one, does not have to hold all customer data in a single database.
Deciding on a use case helps dispel these counter-intuitive notions, because it is more than possible to extract immediate value from a CDP with a “180-degree view” and having data live in separate databases. If the use case is customer acquisition, for example, it may not be necessary to connect to a point of sale system. As far as holding all customer data in a single database, real-time unified access to data is what’s important. Instead of moving data from systems of record to a CDP, a live, real-time connection offers value. There can be cleansed, master information about the customer in the CDP and reference data in other systems, like a CRM system of record.
For the marketer, of course, a lot of these machinations will be hidden from view – as they should be. The marketer’s concern is to create hyper-personal customer experiences, without having to worry about the technical underpinnings. If customer data is available, visible, and in real time, the database of origin is not the marketer’s concern. For the initial CDP implementation, however, decisions about data structure and availability are important. Each use case will determine how to strike the optimal balance between fast-moving and slow-moving data, depending on how recalculations impact the desired goal.
How Will You Be Using the CDP?
Stipulating that it is possible to extract value from a CDP without immediately completing a 360-degree view, there are other important considerations before implementing a CDP that are more intuitive, and common to other martech integrations. First, the CDP must meet whatever IT requirements are placed on it – particularly for highly regulated industries at risk of data leaks. Whether an organization maintains control of its own security perimeter is one of several important decisions to make about how to satisfy IT requirements. The configuration and location of the CDP must meet IT’s criteria for security, privacy, performance, and control, and those requirements might not be satisfied for a SaaS solution where sensitive customer data resides in someone else’s cloud infrastructure and a third-party defines the IT architecture.
Second, the CDP itself must share implementation between marketers and IT personnel. And if the CDP includes a machine learning modeling capability, collaboration must include third parties like data scientists. A CDP design, in other words, must recognize that different stakeholders must be allowed to perform their roles, while still providing an end-to-end workflow for marketers to deliver personalized customer experiences along the entire customer journey. Examples include seamlessly providing data quality functions under the hood and putting those functions under control of IT without marketers ever having to be concerned with them. Likewise, this means providing a data model repository that allows data scientists to control data cleansing, training, model validation, and optimization – while simultaneously allowing marketers to see, deploy, and measure the models.
Third, a CDP must meet the marketers’ (and use cases’) required cadence and connectivity to other applications, a requirement that may eliminate a slew of CDPs that cannot orchestrate in real time, for example. Similarly, it might disfavor a CDP that cannot interactively push information out to a call center, a clienteling app, a bank branch tablet, or any other opportunity to interact with a client or customer that relies on inter-application connection.
These three considerations indicate that marketers should define long-term requirements, as well as detailing their immediate use cases, to avoid choosing a CDP that meets minimum needs but cannot grow to match aspirations.
Everything’s Downstream from the Use Case
Choices in the purchase phase – such as private or public cloud, SaaS or hosted, clustering controls, or how the CDP will be configured in the martech stack – all have downstream consequences for the actual implementation phase. Will reporting and campaign activation need to be done inside the CDP, for example? Every choice or decision about what needs to be within the CDP will have implementation consequences.
Those choices are tied to the ultimate use cases. If a use case involves attribution, measurement, or optimization, elements of the implementation will need to reflect those requirements to ensure that the CDP does not stop short of the last mile connection to the customer.
For more information, or to learn more about which type of CDP is right for your organization by use case, please refer to the Redpoint guide to selecting the right CDP platform.