First-party data programs — if you build it they (customers) will come

Amazing things can be built in the age of APIs and cloud connectors.

flickr/carlwwycoff

You don't build a customer data platform.

You can build towards accomplishing some short-term goals that can also be accomplished with a CDP, but you can't build the core capabilities that drive the allure of the customer data platform. The accessibility of a real-time unified profile for push-button systems integrations and seemingly limitless capabilities in data collection would cost countless years of time to develop internally.

But things can be built, and I am a proponent of building things. At least two types of things can be built here:

1. The use cases themselves
Many use cases that would be deployed with a CDP can be deployed in some other way, without benefit of a full profile and other components the customer data platform provides

2. Internal capacity for customer data use cases
This is where time is better spent. Building out use cases shouldn't really happen until the internal capacity to deal with them is being managed. Early on, teams should be thinking about and planning for customer data and other first-party data use cases. Take the systems out of the equation for a while.

Where does an organization start?

There are organizational ownership decisions to be made. Milestones and ownership need to be defined. From there, one way to get started in building the capacity for customer data use cases is to build out a list of potential, practical use cases for customer and first-party data. Initial use cases for a customer data platform tend to be those that make use of customer data in new areas of value. Consider these, and list use cases from channel to channel with an estimate of effort and value. Include details around why the effort and value scores were chosen. 

As an example or potential starting point, here is an example set of use cases for an imaginary retail brand with special interest publishing sites, minus the scoring details for the sake of brevity. To keep things very simple I included only three channels and used scores from 1-3. For value, 1 = high. For effort, 1 = easy. These can be combined and sorted to find potential good starting points, though supporting steps for long-term use cases must also be considered as part of earlier implementation phases.

Example website use cases for customer data:

Use caseEffortValueScore
Base data collection (including visitor identification)314
Home page header & navigation modification based on most recent campaign response224
Contextual personalized lead generation112
Conversion funnel personalization (behavior-based)123
Conversion funnel personalization (user generated content)123
Drive identification for medium engagement visits224
Content/product recommendations224
Post-conversion personalization235
Profile-building for high engagement / identified visits224

Example email use cases for customer data:

Use caseEffortValueScore
Drive site personalization from clickthroughs314
Drive ad personalization open behavior (post-latency)123
Target past customers with date-based segments224
Target non-customers with behavior-based segments213
Subject line tests per key segment123
List creation for unaddressed segments314
Trigger site abandonment email for high engagement visits224
Add purchase abandoners to cross-channel drip campaign314
Image tests per key segment235

Example PPC/ad tech use cases for customer data:

Use caseEffortValueScore
Add campaigns targeting customers in date-based segments325
Add campaigns targeting customers in behavioral segments325
Add campaigns for post-latent customers224
Optimize remarketing bids224
Create new ad product from profile database314
Compare first-party-based audiences against third-party audiences213

Extract internal requirements

In reality, a 1-5 scale and the details are necessary for prioritization, but even with a list like this, effort unrelated to a customer data platform can be extracted. Each one of these use cases will come along with internal requirements and steps that need to be taken in order to approach them, steps that can be worked out internally with or without a CDP.

If a decision has not yet been made on a CDP, a list like this will go a long way in conversations with vendors to ensure coverage. This may also be where use cases will be discovered that are worth deploying before a decision is made on a customer data platform (the "oh, we had this?" moment).

It's all about the profile

Most customer data platforms feature a website personalization interface, and the driving reason to use that interface is the unified customer profile and real-time decisioning. Visitor identification is a requirement in order to support cross-device and known customer data scenarios. Customer data platforms are not the only way to identify visitors, whether from logging in or clicking through from emails, push notifications, SMS messages, etc. What CDPs offer that other solutions tend not to is an ability to personalize and build out profiles based on multiple identifiers (a process some call "stitching").

While cookie-based personalization tools can allow you to try and stay relevant across pages and sessions, they are no replacement for a full-as-it-can-be profile combined with the centralized decisioning and orchestration that a customer data platform would provide to hands-on marketers.

Yes, build it!

Building the capacity for the customer data platform is just as important as having the customer data platform. Building lines of communication and plans for customer and other first-party data is what enables successful deployments. And, if a customer data platform isn't yet in the budget, you may just be able to select a use case or two to attempt before landing one.

Leave a comment