Careers
Part of Customer data platforms: durable identity models anchor every build
Getting customer data platforms use cases right the first time
Customer data platforms use cases for 2027 cover preference, onboarding, service context, account matching, suppression, renewal, measurement, and recovery.
What to take away
- Choose a CDP use case only when a defined decision, service path, or downstream system needs governed context the CDP holds.
- Specify the full service for every use caseentities, identity, permission, data, latency, destinations, ownership, measurement, stop rules, recovery.
- Pilot duplicate identities, late records, revoked permission, and conflicting source values. Then test destination failure, correction, and deletion before scale.
Customer data platforms use cases should require durable customer context across sources and make that context available to another decision or system. The nine patterns below name real CDP products and implementations, plus the identity, permission, data, risk, latency, platform, and service capacity each one needs.
Nine named CDP use cases
The CDP Institute's Use Case Knowledge Hub treats use cases as the basis for selection and implementation.
- Preference propagation with OneTrust Preference Management and Twilio Segment: OneTrust captures channel, topic, brand, and purpose choices in preference centers. Segment Profiles distributes changes to approved engagement destinations. Typical latency: seconds to a minute, set by source webhooks and destination APIs.
- Onboarding coordination with mParticle and BrazemParticle combines purchase, product, service, and engagement state in real time. Braze Canvas delivers help, detects stalled progress, and avoids conflicting acquisition messages. Typical latency: seconds for events, minutes for orchestrated sends.
- Recent-purchaser suppression with Adobe Experience Platform Real-Time CDP: People-Based Destinations connect transaction and advertising identities through hashed email. The setup stops unnecessary acquisition spend and handles returns, shared accounts, and delayed orders. Typical latency: hours, set by source ingestion and identity matching.
- Service-aware marketing with Salesforce Data CloudData Cloud connects Service Cloud cases and service states to Marketing Cloud journeys. Teams pause unsuitable promotions and route customers to the help they need. Typical latency: near real time for case state, minutes for journey entry.
- Account and buying-group context with Oracle Unity CDPUnity links people, accounts, roles, and engagement. It also links opportunities and products for B2B audiences without treating every contact as one buyer. Typical refresh: daily batch, scaled by account and contact volume.
- Lifecycle retention with BlueConic and OptimoveBlueConic combines adoption, transaction, service, preference, and risk signals. Optimove tests interventions, prioritizes customer help, and stops after resolution. Typical latency: minutes for signals, hours for test cycles.
- Cross-channel frequency with Tealium AudienceStream and EventStream: EventStream captures communication history. AudienceStream applies priority rules so separately managed campaigns do not overload one customer. Typical latency: seconds to minutes, bounded by event volume.
- Customer analytics record with AmperityStitch provides governed identity resolution. Amp360 supplies events, attributes, lineage, cohorts, and correction for analysis while preserving metric and attribution limitations. Typical refresh: hourly to daily, scaled by record volume.
- Data-rights operations with OneTrust Data Subject Rightslocate, correct, restrict, export, or delete relevant customer data and propagate the approved action across connected systems with evidence. OneTrust automates request intake and workflow. Typical latency: days to weeks, set by system count and manual review.
Pick the first use case with four tests: a decision that already runs and fails without CDP context, an accountable destination owner, governed source data, and a measurable outcome within one quarter. Score all nine and start with the highest scorer you can staff.
Specify the complete service
NISTIR 8062 introduces privacy-engineering objectives and a privacy-risk model for federal information systems. Its publication record supports systems-level analysis of how data processing can create problems for people.
Specify each use case
- Outcome, population, entities, identifiers, sources
- Identity rules, permission, quality, latency
- Attributes, calculated fields, destination, owner
- Access, retention, deletion, monitoring, recovery
- Measure and stop rule
- Require persistent records and downstream usability
Write the specification before implementation. Record entities and identifiers, identity rules with merge and split thresholds, permission basis and channel scope, source data and refresh cadence, latency target and volume, and destinations and payloads.
Also record an owner for each system, the measurement that shows the decision changed, stop rules, and the recovery path for wrong merges, stale data, and failed delivery.
Latency and cost follow from profile volume, source count, identity complexity, destination count, and review effort. Set thresholds from your own baseline.
NISTIR 8062, the GAO guide, and the W3C statement are non-binding references, not law or certification. Check your own obligations.
In the United States: the CCPA, CPRA, other state privacy laws, HIPAA, GLBA, FERPA, and FTC Act Section 5. In Canada: PIPEDA, Quebec Law 25, Alberta and British Columbia PIPA, and CASL for commercial email.
Pilot edge cases
Test duplicate and shared identities, late transactions, revoked permission, account changes, deleted records, destination failures, and conflicting source values. Obtain qualified review of the people, data, and systems in scope.
Run the build in this order: baseline the failing decision, write the specification, connect one source, resolve identity, deliver to one destination, measure against the baseline, then expand.
Choose one use case with a visible customer consequence and an accountable destination owner. A decision record for the use case should also state the marketing operations benchmarks that will show whether the service works.
Use-case acceptance map
Minimum evidence
- Preference propagation
- Authoritative status, latency, destination receipt
- Anonymous context
- Identity rule, confidence, neutral fallback
- Service context
- Current state, owner, accepted handoff
- Analytics record
- Definition, population, source, comparison
- Data-rights operations
- Request scope, system receipt, evidence
Stop condition
- Preference propagation
- Suppression lost or delayed
- Anonymous context
- False merge changes treatment
- Service context
- Context stale or unactionable
- Analytics record
- Reported activity lacks decision value
- Data-rights operations
- Correction or deletion unproven
Resolve the question with a decision record
The GAO evaluation design guide connects evaluation questions with evidence needs and design choices. Federal evaluation guidance does not make a local marketing result causal or transferable.
Write the record with named fields: decision, use case, owner, date, evidence, acceptance threshold, latency and volume target, stop rule, recovery path, and review date.
Illustrative example: decision, run recent-purchaser suppression in paid social; owner, lifecycle marketing manager; evidence, return rate and ad overlap report. Threshold, four hours and 98 percent coverage, to confirm in your pilot; stop rule, pause ads if returns exceed the control group; review date, 60 days after launch.
The W3C Privacy Principles statement gives web-system designers shared privacy concepts and warns against shifting privacy work to individuals. Apply it to customer data platforms use cases, then review the governing law and configuration.
Common questions
Which CDP use case should come first?
Choose a frequent, consequential decision that currently fails because governed customer context cannot reach an accountable destination.
Is audience creation enough for a use case?
No. Define the customer need, the data service, destination action, outcome, and guardrails.
How large should the first pilot be?
Use the smallest representative population that exercises normal, edge, and failed paths without exposing more people or data than necessary.
