How To Define CDP Requirements Before Evaluating Vendors: A Five Category Framework For Enterprise Teams

Most enterprise CDP evaluations start in the wrong place.

The typical sequence is familiar. A team decides it needs a customer data platform. Vendors are contacted. Demos are scheduled. Stakeholders react to what they see. Someone drafts an RFP. Requirements are written after the organization has already been influenced by vendor positioning, product interface, demo flow, and feature language.

That sequence feels efficient. It is also risky.

When CDP requirements are defined after vendor demos, the requirements are shaped by what vendors chose to show. The evaluation begins to prioritize front end usability, segment builder features, activation destination lists, and dashboard polish before the organization has defined the data architecture, integration, governance, operating model, and business outcome requirements that determine whether the CDP will actually work in production.

At Stable Kernel, we do not approach CDP evaluation as a traditional software procurement exercise. We approach it as a long term operational infrastructure strategy decision. A CDP is not just a marketing tool. It is customer data infrastructure that affects data ownership, identity resolution, governance, personalization, AI readiness, marketing activation, and long term flexibility.

That is why CDP requirements should be defined before any vendor is contacted.

A requirements first process gives enterprise teams a clear, vendor agnostic view of what the organization actually needs. It turns business goals, data realities, technical constraints, compliance obligations, and operating model limits into a structured requirements document. That document then becomes the basis for the RFP, vendor scorecard, demo script, pre qualification questions, and final architecture decision.

What CDP Requirements Definition Means

CDP requirements definition is the structured process of gathering, categorizing, and prioritizing the capabilities, architectural characteristics, integrations, governance controls, and operating constraints the organization needs from a customer data platform.

This is different from listing CDP features.

A feature describes what a vendor has built. A requirement describes what the organization needs the CDP to do in its own environment.

For example, “the CDP must have a segment builder” is a feature based requirement. Almost every vendor can answer yes.

A stronger requirement is: “The CDP must enable paid media suppression by unifying customer suppression lists across Google Ads, Meta, and The Trade Desk so that customers who purchased within the last 30 days are removed from acquisition campaigns within 24 hours of purchase.”

That requirement tells vendors what the business outcome is, which systems are involved, what latency is required, and how success will be measured.

That is the difference between a generic RFP and a requirements driven vendor evaluation.

Why Demo First CDP Evaluations Create Biased Requirements

Vendor demos are designed to make the platform look strong.

That does not mean vendors are acting in bad faith. It means demos are sales experiences. They highlight the cleanest workflows, the most polished features, and the use cases the vendor is best equipped to show.

A demo first evaluation often overweights:

• Interface quality
• Segment builder usability
• Dashboard design
• Number of activation destinations
• Pre-built campaign templates
• AI features presented without production context
• Speed of configuration in a controlled demo environment

Those features matter, but they are not enough.

A demo may not reveal whether the platform can handle a proprietary QSR POS integration. It may not reveal whether identity resolution supports the organization’s individual versus household model. It may not reveal whether data portability is practical if the vendor is acquired. It may not reveal whether EU data residency is available. It may not reveal how many data engineers the architecture will require after go live.

The risk is that the most compelling demo becomes the invisible blueprint for the RFP.

The evaluation appears objective because every vendor receives the same questions. But the questions were shaped by the vendor that presented first or best.

The Better Sequence: Requirements Before Vendors

A better CDP evaluation sequence looks like this:

• Confirm that a CDP is the right investment.
• Complete a readiness assessment of the data environment.
• Define requirements across five categories.
• Prioritize requirements into knockout criteria, must haves, and nice to haves.
• Translate requirements into a pre qualification questionnaire and RFP.
• Require vendors to demonstrate priority use cases using the organization’s actual data where feasible.
• Score vendors against the requirements register, not a generic feature checklist.

This process prevents vendor language from becoming the organization’s requirements language.

It also makes the evaluation more useful for executives. Instead of asking, “Which vendor has the best feature set?” the team can ask, “Which vendor can support our use cases, data architecture, compliance obligations, engineering capacity, and long term roadmap?”

The Five Category CDP Requirements Framework

Enterprise CDP requirements should be gathered in five categories:

• Use case and business outcome requirements
• Data architecture requirements
• Integration and ecosystem requirements
• Governance and compliance requirements
• Operational and organizational requirements

Each category requires different stakeholders and a different elicitation method. Completing all five before vendor contact creates a requirements document that reflects the enterprise’s actual needs rather than a vendor’s preferred story.

Category 1: Use Case And Business Outcome Requirements

Use case and business outcome requirements define what the CDP must help the organization accomplish.

This category should be led by the executive sponsor, CMO, VP of Marketing Technology, analytics lead, and data engineering lead. Marketing may define the business outcome, but data engineering must confirm that the required data inputs are available and feasible.

The goal is to define two or three priority use cases with clear revenue mechanisms.

A strong use case requirement includes:

• The customer segment involved
• The business outcome expected
• The data inputs required
• The activation destinations involved
• The latency requirement
• The measurement method
• The revenue KPI that proves success

Common examples include paid media suppression, churn prevention, personalization, cross sell, loyalty activation, and AI driven customer experience use cases.

Example Use Case Requirements

• For paid media suppression, the requirement may be: the CDP must identify customers who purchased within the last 30 days and suppress them from acquisition campaigns across Google Ads, Meta, and The Trade Desk within 24 hours of purchase. The business outcome is wasted spend reduction. The measurement method is pre and post waste rate comparison or holdout based incrementality testing.
• For churn prevention, the requirement may be: the CDP must combine CRM purchase history, mobile app engagement, loyalty activity, and customer service signals to identify at risk customers daily. The business outcome is lower 90 day churn in the at risk segment. The measurement method is an 80 and 20 holdout test comparing treated customers against a control group.
• For personalization, the requirement may be: the CDP must use purchase history, email engagement, and mobile app behavior to personalize email and on site recommendations. The business outcome is conversion rate lift or average order value lift. The measurement method is treated versus control performance across comparable campaigns.

These requirements are much stronger than asking whether a vendor supports segmentation or personalization. They force vendors to demonstrate whether the platform can deliver the use case in the organization’s environment.

Category 2: Data Architecture Requirements

Data architecture requirements define the technical characteristics the CDP must support.

This category is often underspecified because many CDP evaluations are led by marketing procurement teams without enough data engineering input. That creates a gap between what looks good in the demo and what will work in production.

The data architecture workshop should include the data engineering lead, data architect, CTO or VP of Engineering, analytics lead, and marketing technology owner.

This session should define:

• Source systems and update cadences
• API types and integration constraints
• Identity model requirements
• Profile count and expected growth
• Event volume and peak traffic
• Real time versus batch requirements
• AI readiness requirements
• Data quality and schema requirements
• Warehouse maturity for composable architectures

Example Data Architecture Requirements

• For a QSR enterprise: the CDP may need to support a proprietary POS with real time order submission and customer record lookup through a synchronous API. If no standard connector exists, that becomes a must have custom connector requirement that affects timeline and total cost of ownership.
• For identity resolution: the organization may require individual level profiles using deterministic matching on loyalty ID and email, with probabilistic matching for anonymous to known resolution. If the business needs more than 75 percent of digital traffic resolved to known profiles, vendors must show how that coverage target is achieved.
• For event volume: the organization may need to process 12 million events per day at peak and 80 million per month, with a projected three times increase over 24 months. That requirement protects the organization from selecting a platform that looks affordable at today’s volume but becomes expensive at future scale.
• For AI readiness: the organization may require sub second profile serving to support real time personalization in a future voice ordering or agentic AI use case. If that requirement is Phase 2, it may be nice to have for the first deployment but a must have for the longer roadmap.

Category 3: Integration And Ecosystem Requirements

Integration requirements define which systems the CDP must connect to, how deeply it must connect, and whether those integrations are standard or custom.

A vendor may advertise hundreds of connectors. That does not matter if the organization needs one proprietary connector the vendor does not support.

Integration requirements should specify actual system names and integration depth, not generic categories.

The systems inventory session should include data engineering, IT, marketing technology, security, and any business owner of a priority source or activation system.

This session should define:

• Source systems that send data into the CDP
• Activation destinations that receive data from the CDP
• Whether integration is read only, write only, or bidirectional
• Required sync frequency
• API limitations
• Middleware or gateway requirements
• Pre-built connector availability
• Custom development estimates

Example Integration Requirements

• Salesforce CRM may require bidirectional integration, with real time sync of customer records and write back of CDP segment membership for sales actions.
• A proprietary QSR POS may require source integration for real time transaction events, menu item data, and loyalty ID resolution at the transaction level. If there is no prebuilt connector, the requirement should include custom connector development estimates before vendor selection.
• Google Ads may require activation integration for Customer Match uploads, acquisition suppression, and audience refresh within 24 hours of purchase.
• An internal loyalty platform may require bidirectional integration for tier status, point balance, loyalty event ingestion, and write back of CDP behavioral segments for offer targeting.
• Braze or another ESP may require segment sync, profile attribute push, and real time triggered sends based on behavioral events.

These details matter because integration depth is often the difference between a CDP that works as an operational hub and a CDP that only stores customer profiles.

Category 4: Governance And Compliance Requirements

Governance and compliance requirements define the regulatory, privacy, consent, data residency, audit, and risk controls the CDP must support.

This category should not be led by marketing alone. It should be led by Legal, Compliance, the Data Privacy Officer, security, and data governance leaders. Marketing should explain the planned data uses. Legal should define the conditions under which those uses are permissible.

Governance requirements often become knockout criteria because noncompliance can prevent deployment.

This session should define:

• Applicable regulatory frameworks
• Consent architecture requirements
• Data residency requirements
• Data retention requirements
• Data subject rights workflows
• Vendor DPA and sub processor requirements
• AI decision audit trail requirements
• Biometric or voice data requirements where relevant
• Security and certification requirements

Example Governance Requirements

• For GDPR consent enforcement: the CDP may need to maintain consent records at the profile level and propagate consent withdrawal to all activation destinations within 72 hours. Vendors should be required to demonstrate consent enforcement and provide current DPA and sub processor documentation.
• For EU data residency: customer data for EU residents may need to be stored and processed within EEA data centers. If this is legally required, it should be a knockout criterion.
• For AI driven decisions: the CDP may need to log profile state, model version, decision output, and outcome for each AI personalization decision. If the organization expects regulatory inquiry or internal audit, audit trail completeness becomes a must have.
• For data subject deletion: deletion requests may need to cascade from the CDP to all activation destinations and sub processors within GDPR or CCPA timelines. Vendors should demonstrate the deletion workflow in a test environment.
• For biometric or voice related data: organizations operating in states with biometric privacy laws may need written consent, retention policy, and prohibitions on selling or profiting from biometric identifiers.

Category 5: Operational And Organizational Requirements

Operational and organizational requirements define whether the CDP can be operated sustainably inside the enterprise.

This category often separates vendors that look similar in a feature comparison.

A CDP may meet the initial use case requirements but create long term risk because it requires more engineering capacity than the organization can support, limits data portability, creates vendor lock in, lacks observability, or does not align with the AI roadmap.

This session should include the engineering manager, CDO or CTO, procurement, legal, marketing technology, and the executive sponsor.

It should define:

• Maximum engineering capacity available for CDP operations
• Support model expectations
• Data portability requirements
• Exit flexibility and migration requirements
• Vendor acquisition trigger clauses
• Observability access requirements
• AI roadmap alignment
• Ownership model expectations
• Training and handoff requirements

Example Operational Requirements

If the organization can dedicate only one data engineer to ongoing CDP operations, the architecture must be sustainable within that constraint. A composable architecture requiring three to five engineers may not be viable even if it appears attractive on license cost.

• For portability, customer profiles may need to be exportable in JSON or Parquet within 30 days of contract termination, including identity graph, segment membership history, and raw event logs. Vendors should provide a sample export and explain the migration process.
• For vendor acquisition risk, the contract may need to include notice requirements, termination flexibility, and protections against pricing or roadmap changes after acquisition.
• For observability, the engineering team may require direct real time access to pipeline health, identity resolution accuracy, profile completeness, and event freshness. Vendor provided reports on request are not enough for operational ownership.
• For AI roadmap alignment, the CDP may need to support native agentic AI integration, real time profile serving, or closed loop personalization over the next 24 months.

How To Prioritize CDP Requirements

Once requirements are gathered, each should be assigned to one of three priority tiers: knockout criterion, must have, or nice to have.

Knockout Criteria

A knockout criterion is a requirement the CDP must meet for the organization to use it at all.

If a vendor fails a knockout criterion, it should be removed from the shortlist before the full RFP.

Common knockout criteria include:

• GDPR data residency for EU customer populations
• HIPAA compliance for covered healthcare entities
• SOC 2 Type II requirements for regulated environments
• Required consent enforcement that cannot be worked around
• Required support for a legally mandated data handling policy
• Knockout criteria should be tested in a pre qualification questionnaire before the full evaluation begins.

Must Have Requirements

A must have requirement is necessary for the initial deployment to deliver projected business value.

If the vendor cannot meet it, the team may need workarounds that add cost, delay, or risk.

Common must haves include:

• Required source system integration
• Required identity model support
• Required latency for the first use case
• Required activation destination sync
• Required data quality monitoring
• Required measurement or holdout test support

Must haves should be weighted heavily in the evaluation scorecard.

Nice To Have Requirements

A nice to have improves the deployment but is not required for the initial use cases.

Nice to haves often include Phase 2 or Phase 3 capabilities such as future AI roadmap alignment, advanced observability features, preferred support models, or additional activation destinations.

Nice to haves should differentiate vendors that are otherwise strong. They should not override knockout criteria or must haves.

From Requirements To RFP

The requirements document becomes the RFP by translating each register entry into a specific vendor question.

A weak RFP question asks: “How does your platform handle identity resolution?”

A strong requirements driven RFP question asks: “Demonstrate how your platform resolves individual level identity for customers who have a loyalty card linked to an email address, a mobile app profile with a separate device ID, and a POS transaction card with no CRM link. Show deterministic matching for loyalty to email and probabilistic matching for device ID linkage using representative data under NDA.”

That question reveals fit.

Use Knockouts As Pre Qualification

Before distributing the full RFP, send vendors a short pre qualification questionnaire covering knockout criteria. Require written confirmation and evidence.

This saves time by removing vendors that cannot meet legal, security, residency, or architecture requirements before the full evaluation begins.

Replace Generic Demos With Use Case Demonstrations

Do not ask vendors for their standard demo.

Ask them to demonstrate the priority use cases using the organization’s data, or a representative dataset that reflects the organization’s source systems, identity challenges, and activation destinations.

For example, if paid media suppression is the first use case, the demo should show how the vendor ingests purchase data, builds the suppression audience, syncs it to ad platforms, handles consent, and reports performance.

Build The Scorecard From Requirements

The final CDP evaluation scorecard should come directly from the requirements register.

Each must have becomes a high weight scored criterion. Each nice to have becomes a lower weight criterion. Knockouts are already resolved before scoring.

This keeps the evaluation tied to what the organization needs, not what generic CDP feature checklists say every enterprise should want.

How Stable Kernel Facilitates CDP Requirements Definition For Enterprise Teams

Stable Kernel helps enterprise teams define CDP requirements before vendors enter the conversation.

This matters because the hardest part of the requirements definition is not writing the document. It is translating across teams.

Marketing describes customer outcomes. Data engineering describes architecture constraints. Legal describes compliance obligations. Procurement describes contract risk. Analytics describes measurement requirements. Product describes event data and digital behavior.

Stable Kernel’s role is to turn those perspectives into a vendor ready requirements document.

Technology Translation During Requirements Definition

Stable Kernel acts as the technology translator between marketing’s use case language and data engineering’s architecture language.

For example, marketing may say, “We need real time suppression after purchase.” Data engineering may explain that the POS API is batch only with a four hour window. Stable Kernel translates that into an RFP ready requirement: “The CDP must support a middleware gateway integration with batch POS transaction data at a maximum four hour event latency.”

That is the level of specificity vendors can answer.

Five Category Workshop Facilitation

Stable Kernel facilitates the five category requirements workshop across:

• Use case and business outcome requirements
• Data architecture requirements
• Integration and ecosystem requirements
• Governance and compliance requirements
• Operational and organizational requirements

The output is not a generic RFP template. It is a requirements register based on the organization’s actual data environment, source systems, governance obligations, engineering capacity, and roadmap.

Vendor Agnostic Evaluation Design

Stable Kernel is vendor agnostic.

That means requirements definition is not calibrated to a preferred platform. It is calibrated to the enterprise’s business outcomes, architecture, governance, and operating model.

A CDP implementation partner should not begin by asking which platform the organization prefers. It should begin by asking whether the investment is justified, whether the data foundation is ready, and which architecture the enterprise can operate.

Lock In And Future State Risk Assessment

Stable Kernel also helps organizations define operational requirements that protect long term flexibility.

That includes portability, exit flexibility, vendor acquisition risk, observability, AI readiness, and total cost of ownership. These requirements may not be persuasive in a demo, but they become critical after the platform is embedded into customer data operations.

Stable Kernel offers a complimentary CDP requirements definition session to help enterprise teams run the five category workshop, translate technical constraints into RFP ready requirements, identify knockout criteria, and produce a prioritized requirements document before contacting vendors.

Reflection Questions For Executives

1. Have we defined CDP requirements before contacting vendors, or are we reacting to demos?
2. Are our requirements written as business outcomes or vendor features?
3. Which two or three use cases must the CDP support first?
4. Do we know the data inputs, activation destinations, latency requirements, and revenue KPIs for each use case?
5. Has data engineering defined source system, identity, event volume, and architecture requirements?
6. Has Legal defined consent, residency, retention, and audit requirements before vendor evaluation begins?
7. Which requirements are true knockout criteria?
8. Which requirements are must haves for the first deployment?
9. Which requirements are future nice to haves?
10. Does our vendor scorecard reflect our requirements register, or a generic CDP feature checklist?

FAQ

How Do You Define CDP Requirements Before Evaluating Vendors?

Define CDP requirements across five categories before contacting vendors: use case and business outcome requirements, data architecture requirements, integration and ecosystem requirements, governance and compliance requirements, and operational and organizational requirements. Each category should be gathered through a cross functional workshop with the teams that will buy, implement, govern, and use the CDP.

What Is The Difference Between CDP Requirements And CDP Features?

CDP requirements describe what the organization needs the platform to do in its specific environment. CDP features describe what a vendor has built. A requirement ties a capability to a use case, data input, latency need, activation destination, compliance condition, or business KPI. A feature usually describes a general product function.

What Are The Five Categories Of Enterprise CDP Requirements?

The five categories are use case and business outcome requirements, data architecture requirements, integration and ecosystem requirements, governance and compliance requirements, and operational and organizational requirements. Together, they define what the CDP must support before vendors are evaluated.

What Are Knockout Criteria In A CDP Requirements Evaluation?

Knockout criteria are requirements a vendor must meet to be considered at all. If a vendor fails a knockout criterion, it should be removed before the full RFP. Common knockout criteria include legal, security, data residency, HIPAA, GDPR, SOC 2, or consent enforcement requirements that cannot be worked around.

When Should CDP Requirements Definition Happen?

CDP requirements definition should happen before vendor demos, before RFP drafting, and before vendor shortlisting. It should follow the decision and readiness stages, then inform the pre qualification questionnaire, RFP, demo script, scorecard, and final vendor evaluation.

How Do Functional And Technical CDP Requirements Differ?

Functional requirements describe what the CDP must do for users, such as audience segmentation, campaign activation, or personalization. Technical requirements describe how the CDP must operate, including source system integration, API depth, event volume, latency, identity resolution, observability, and architecture fit.

What Data Architecture Requirements Should A CDP Evaluation Include?

A CDP evaluation should include source system requirements, identity model requirements, data volume and velocity, latency needs, warehouse maturity, real time versus batch requirements, and AI readiness. These requirements determine whether a vendor can support the organization’s actual data environment.

How Should Governance Requirements Shape CDP Vendor Selection?

Governance requirements should shape vendor selection through knockout criteria and must have requirements. Legal, compliance, security, and privacy teams should define consent, residency, retention, audit, deletion, DPA, and sub processor requirements before the RFP is distributed.

What Are The Most Common Mistakes In CDP Requirements Definition?

Common mistakes include defining requirements as features, omitting data architecture requirements, leaving Legal out until after vendor selection, marking every requirement as must have, ignoring portability and exit flexibility, and allowing vendor demos to shape the RFP.

Can Stable Kernel Help Define CDP Requirements Before Vendor Evaluation?

Yes. Stable Kernel facilitates CDP requirements definition before vendor evaluation. Stable Kernel helps teams define use cases, document data architecture needs, map integration requirements, identify governance obligations, assess operating constraints, prioritize knockout and must have criteria, and translate the requirements into an RFP ready vendor scorecard.