Are you considering using a Customer Data Platform (CDP) to improve your marketing in the coming year? If so, you’re probably wondering which CDP use cases should receive top priority in your business goals as you roll out your new CDP capabilities. And should you initially confine your CDP use cases to the marketing department, or quickly roll out your CDP for use in service, contact center, sales, and even logistics data support or product design? It will come as no surprise to data-driven marketers that there’s actually good data on these questions, courtesy of the CDP Institute (CDPI), which offers a free online Use Case Generator to help organizations define their CDP requirements. (You can access the Use Case Generator on the CDP Institute site.) What can you learn from these CDP users, and their six dozen CDP use cases?
The Data Set Behind Our Report on Customer Data Platform Use Cases
How did we compile the data for our analysis of CDP use cases? Although information collected about CDP use cases in the CDPI system remains private, we recently analyzed the inputs in aggregate. The resulting report provides unique insight into how companies plan to use their CDP and what requirements these new CDP user companies expect it to meet. Here are some key findings from our research.
Finding #1: Most CDP Use Cases Are Remarkably Simple
The Use Case Generator asks about the data types, source systems, target systems, CDP features, departments, and Key Performance Indicators (KPIs) involved in each use case. There are about a dozen choices for each category. Yet the average use case requires just a few from each group: about six data types, five source systems, four target systems, four departments, six KPIs, and half the available features. About one-quarter of use cases require no more than three data sources.
The implications are significant. CDPs are often expected to assemble all possible data into a comprehensive unified customer view profile. This makes CDP deployment a daunting prospect and can result in a large, complex project plan – or in rejecting the project altogether because of the time, cost, and effort involved. The data tells us that less ambitious projects are feasible because CDPs can deliver value with just a few data sources, target systems, and users.
This confirms the conventional wisdom that recommends you start with a few marketing objectives, and then gradually do more as your teams build experience and demonstrate results, an approach sometimes called “crawl-walk-run incremental deployment.”
Finding #2: Expand CDP Use One Department at a Time
But that’s not all. The report also highlights the cost of expanding CDP use beyond a single department – since each new department will require training new users and, in most cases, connecting new data sources, data types, and target systems. This adds concrete guidance for incremental deployment; in other words, companies should plan to deploy as many use cases as possible within a single department before moving to applications in other departments. And when they do expand to a new department, they should again deploy many use cases in that department before moving to yet another.
This is an especially important insight for CDPs that are intended from the start to be used across the enterprise. For those projects, there may be substantial pressure to deploy the CDP as widely as possible as soon as possible. Companies should recognize that early, broad deployment is inherently more difficult than narrow, deep deployment. If quick deployment across multiple departments is unavoidable, they should be sure to budget adequate resources to meet this more demanding approach.
Finding #3: CDP Use Cases Span All Stages of CDP Maturity
The Use Case Generator classifies each use case by its final product. These products are arranged as a sequence that starts with unified customer profiles, next moves to analytics and predictive models, and ends with outbound campaigns, real time interactions, and cross-channel orchestration. The sequence can be considered a maturity model, since early products often provide inputs needed for later products.
About one-third of the use cases built in the Generator were aimed at the first-stage product, assembling unified customer profiles, which can be used to create unified customer views. Interestingly, there were relatively few that targeted the next stages of analytics or predictive models. More aimed at outbound campaigns and real-time interactions, while relatively few were intended to reach the most advanced aim: cross-channel orchestration.
The reason for this distribution is fairly clear, at least in hindsight: Companies are most interested in use cases that deliver measurable revenue gains, something that analytics and predictive models can only create if their results are used in campaigns or interactions. Indeed, about three-quarters of the campaign and interaction use cases included predictive models in their requirements.
It also turns out that most analytics and predictive model use cases were expected to feed their results to something other than the marketing campaigns and interactions listed as an option in the Use Case Generator. So even those projects really had a broader goal beyond analytics or model building itself.
Once more, the lesson here is that CDPs can create value quickly: remember, one-third of the use cases set data assembly as their goal. But this value will only be realized if the project plan includes all use cases, simple ones as well as those that support other departments. Business users focused on campaigns, interactions, or other high-maturity applications may not think to include the simpler ones. This means that project teams who want their CDP to deliver value quickly need to check that they’re present.
Finding #4: Early and Continuous User Involvement Is Key to CDP Success
Incremental deployment focused on a single department and inclusion of profile-building use cases both seem to suggest that for customer data platform use cases, it’s only necessary to engage a few business users at the start of a CDP project.
But that’s just plain wrong.
A narrow set of simple customer data platform use cases may be the fastest way to gain value from the CDP, but a successful CDP will ultimately be used for many more purposes across multiple departments. Finding a CDP that will support this later expansion depends on understanding the requirements of those future use cases when the CDP is being selected. This, in turn, depends on engaging the business users who can define those use cases from the start.
It may seem counterproductive to involve users who will later be told they’ll have to wait to use the system. Including those users will certainly create more work at the start. But results from the CDP Use Case Generator are clear: while most individual use cases have relatively few requirements, those requirements differ from one case to the next. In fact, while few requirements were needed by more than 80 percent of the relevant use cases, none was needed by fewer than 39 percent.
This means the only way to build a comprehensive set of requirements is to explore the full range of future use cases at the start. Incremental deployment is not an excuse for incremental requirements definition. In fact, incremental deployment can only go smoothly if a complete vision is developed in advance.
You can download our full analysis of the Use Case Generator from the CDP Institute. And of course, you can also create your own use cases in the Generator itself.
How to prioritize which CDP use case to build first
The Use Case Generator returns a long list of plausible candidates, and a long list creates its own problem: everything looks worth funding, and the committee wants to start all of it. The organizations that stall are rarely the ones that picked the wrong use case — they are the ones that started everything at once and finished none of it. Prioritization goes better when the filter is written down before the first debate starts.
A scorecard turns the argument from enthusiasm into evidence. Score every candidate against the same five questions:
| Criterion | What to establish | Why it matters | Failure mode when skipped |
|---|---|---|---|
| Revenue proximity | Which campaign or interaction the use case feeds, and the KPI it moves | Use cases that end at a report struggle to justify the next round of funding | The project launches successfully and dies quietly at the first budget review |
| Data readiness | Whether the required data types already exist, are consented, and are mapped to identities | Waiting on new data collection dominates the timeline | A “quick win” quietly becomes an unscoped data engineering project |
| Department scope | How many teams must change how they work for the output to matter | Every added department brings training, new connections, and new approval loops | A cross-department launch ships to people who were never onboarded |
| Maintenance owner | Who owns the use case after launch, and how often they revisit it | Segments go stale and definitions drift without an owner | Early wins erode into distrust of everything the CDP produces |
| Reversibility | What it costs to retire the use case if the KPI does not move | Cheap-to-stop bets let you run more experiments per quarter | A failed use case stays in production because unwinding it costs more than running it |
Rank the candidates, fund from the top until the budget stops, and keep the rejected list visible — last quarter’s cut is often this quarter’s winner. Teams that already run delivery in an agile methodology will recognize the shape: a short backlog, one use case delivered per cycle, and a working result demonstrated at the end rather than a status deck.
A first CDP use case that fits each department
The department-by-department argument above leaves one question unanswered, and it is the question the department lead actually asks: which use case comes first for my team? The honest answer depends on what data the department already trusts and what decision its people repeat every day. The pattern below is a way to test candidate first use cases, not a prescription.
| Department | Typical first use case | Data it depends on | Watch out for |
|---|---|---|---|
| Marketing | Post-purchase follow-up sequences driven by unified purchase history | Purchase records, email engagement, consent status | Personalization built on incomplete data reads as errors, and customers notice faster than marketers do |
| Customer service | Showing agents recent purchases and open issues in one view | Order history, support tickets, identity resolution across channels | A stale profile is worse than none — an agent who repeats advice the customer already got loses trust for both the agent and the tool |
| Sales | Flagging accounts whose engagement pattern suggests active buying intent | Web engagement, product usage, CRM account records | Scores nobody explained get ignored; introduce the signal to the team before automating it |
| Product | Comparing feature adoption across customer segments and plan tiers | Product usage events, plan data, lifecycle stage | Event instrumentation is thinner than expected — confirm events exist before the project starts, not during it |
What these four share is the property worth protecting when you choose your own: each runs on data the department already owns or already consumes, so none of them waits on another team’s roadmap. A first use case that depends on a source scheduled to arrive next quarter is not a first use case.
How CDP use case rollouts fail, and the fix for each
Most use case failures are not exotic. They repeat across organizations because each one is invisible at planning time and obvious six months later. Four patterns cover most of the damage.
The orphaned use case. It launches, works, and slowly rots: the segment no longer matches how the business talks about customers, and nobody notices because nobody owns it. Name the owner and the owner’s review cadence before the build starts — a use case without an owner is a demo, not an asset.
Requirements frozen at selection time. The use case list written to choose the platform becomes the permanent scope. Two years later the company launches a loyalty program and the requirements document has nothing to say about it. Treat the selection-time list as a sample of future requirements, not the population, and keep a living backlog that outlives the vendor selection.
The missing baseline. The use case goes live, the team reports that it is going well, and no one can prove it because the pre-launch number was never recorded. Capture the KPI baseline before launch; retrofitted baselines are where internal debates start.
Success measured as delivery. The use case shipped on schedule, so the project is declared a win even though no team uses the output. Define adoption as part of the use case itself: who uses the result, how often, and what tells you they stopped.
How AI agents change what a use case must define
A conventional use case describes what a person will do with unified profiles: build a segment, launch a campaign, hand sales a prioritized account list. Agentic AI adds a second consumer. In an agentic CDP, software agents read profiles and act on them — choosing the next interaction and executing it without waiting for a campaign calendar.
The planning consequence is easy to miss: a use case written only for human users can underspecify what an agent-run version will demand. A weekly batch segment satisfies a marketer; an agent choosing the next best interaction needs current data, fast profile access, and permission rules a machine can apply consistently. You do not need to build agent-driven use cases first. But when you define each use case now, note whether an agent could eventually execute it, and record the data quality and access requirements that version would need. The note costs an afternoon, and it tells you whether the platform you select will survive the next expansion — the same completeness discipline Finding #4 asks for.
FAQ
How many CDP use cases should you start with?
Start with a small set of use cases inside one department, and expand only after they run in production with results you can measure. The research behind this page found that each use case carries only a few requirements, so a narrow start keeps training and integration work manageable while your team learns how the platform behaves with real data. Define owners and KPI baselines for the first set before adding a second department.
What is the difference between a CDP use case and a CDP feature?
A use case is the business outcome you want; a feature is a platform capability. “Bring back buyers who have stopped reordering” is a use case: it names a goal, an audience, a KPI, and the team that acts on the result. Predictive scoring is a feature that serves many such outcomes. A complete use case definition adds the data, systems, departments, and KPIs involved, because a feature list cannot say whether the project worked.