Whether a CDP purchase gets a formal RFP tracks company size and contract value rather than the category — the section below has the numbers. If you are on the side of that line where you have to write one, the document itself follows immediately: an eight-section structure, assembled from the requirements buyers described issuing and the criteria they described scoring against. Everything after it is how the selection runs around that document: how a long list of five or six becomes a shortlist of three, who evaluates the platform and who releases the money, and why the date you are working to is almost certainly a contract expiry rather than the day the requirement appeared. For the questions you ask in the room rather than in a document, the companion read is questions to ask CDP vendors.
How do you write a CDP RFP?
A CDP RFP has eight sections: the problem and where it came from; technical and non-technical requirements; the CDP capability requirements; the response format; the evaluation criteria; commercial and contractual terms; security, risk and compliance; and the process and dates.
Buyers most often issue the formal RFP to three vendors after early conversations with five or six. Integration with the existing stack and cost form the first tier of evaluation criteria, and buyers usually work backwards from an incumbent contract expiry rather than from the day the requirement appeared.
When is a formal CDP RFP required?
A formal CDP RFP is most likely to be required when the purchase crosses an organization's annual contract-value threshold. Company size correlates with formality, but buyers describe the spend threshold as the more reliable trigger: above it the RFP, central technology involvement and higher approvals engage; below it the business owner may decide alone.
Roughly two-thirds of CDP buyers who describe their buying process name an RFP or an RFI in it, and the split is not even. Nearly every buyer above about a billion in revenue or ten thousand employees runs one, and describes it in compulsory language — a mandatory RFP process, a competitive bid system, a policy requiring a minimum of three proposals before any enterprise purchase. Below that line, most say plainly that they have no formal buying committee and no RFP requirement.
The line leaks in both directions, so it is worth knowing which side you are actually on rather than assuming from headcount. Small consumer brands with lean teams sometimes run RFPs anyway, usually because a parent company or an investor requires it. Some very large organizations describe a fast process with little committee involvement, because the category sits clearly inside one function's budget.
Buyers describe that threshold as an explicit figure rather than a rule of thumb. Lower-cost tools may skip the RFP and still get a procurement review of services and cost. If you do not know your own threshold, that is the first thing to find out, because it determines every other date in your plan.
What goes in a CDP RFP?
A CDP RFP should contain eight sections: the problem and where it came from; technical and non-technical requirements; the CDP capability requirements; the response format; the evaluation criteria; commercial and contractual terms; security, risk and compliance; and the process and dates. What follows is a structure, not a transcription: the sections buyers described requesting, filled with the requirements and criteria they described applying. Written scoring instruments do appear in the interviews — a rubric issued to vendors to respond against, a requirements grid matching vendors to needs, a named scoring framework — but weighting does not. What buyers describe is criteria, applied by multiple evaluators, with feedback consolidated across the committee. Treat a weighted arithmetic scorecard as a tool you may choose, not as the practice the category runs on.
The problem, and where it came from
Where buyers describe writing this well, they are copying from something that already exists — a multi-year technology plan, a business case already taken to leadership. Our recommendation follows from that: start from the artefact that created the requirement, not from the category name.
- What the platform is for, written before any vendor has demonstrated what it can do
- The originating document or plan the requirement came from, and the outcome it was tied to
- Whether an internal or already-licensed solution has been ruled out — in large organizations this check is mandatory before anything external is considered
Requirements, technical and non-technical
Buyers describe defining both halves jointly with procurement before issuing anything, so the commercial requirements are not bolted on after the technical evaluation is done.
- Technical requirements, separated into must-have and preferred
- Non-technical requirements: support model, service levels, contracting constraints, regional or entity coverage
- A requirements grid vendors respond against line by line — this is what makes shortlisting mechanical rather than argued
The CDP capability requirements
This should be the longest section of your RFP, and we would group it the way the evaluation itself splits: a flat feature list makes vendor responses harder to line up against each other. Mark each requirement for how it will be judged: some you will take on the written answer, others you will validate hands-on once the responses are in. The document names the test and the success condition; it does not run the test. For how buyers run them, see questions to ask CDP vendors.
Data in- Every source system named individually, with its volume and how fresh the data has to be
- Real-time versus batch ingestion — and which of your sources can actually support real time today
- What has to be true about your data before the platform works: name your known duplicates, your governance owner, and your source of truth, and ask vendors to respond to the sequencing rather than the capability
- Identity resolution — flagged for hands-on validation against a sample of your own file, so vendors know at response time that a benchmark will not settle it
- Whether the identity graph is the vendor's own or licensed from a third party you could buy directly
- Your specific hard cases, named: post-merger duplicates, contacts who move between companies, household versus individual, guest versus authenticated
- The match rate you achieve internally today, as the bar the response is measured against
- Segmentation, including clean-room segmentation with brand or retail partners where that applies
- Every activation destination named individually — connector and destination fees commonly sit outside the licence, so the list is a commercial requirement as much as a technical one
- Activation latency stated as a number, not as "real time"
- Journey mapping, and how an audience is QA'd before it ships
- Your industry's use cases named specifically, rather than a generic capability list
- The governance model, and who owns consent, suppression and deletion once data is in the platform
- Data residency: whether your data must live in the vendor's environment or can stay in your warehouse, and what replication is mandatory
- Observability — how you find out a pipeline broke before a campaign does
- The access and permissions model, down to field level, and how it maps to your existing roles
- Marketer self-service — flagged for hands-on validation, with the success condition stated in the document: a non-technical marketer builds and activates an audience unaided
- Scalability, asked for as evidence of production deployments at two and five times your current volume, with pricing modelled at those volumes
- Implementation resources — what your team supplies, what the vendor supplies, and what neither has scoped
- Which existing tools this platform is expected to consolidate or retire, named individually
- AI capability split into generally available, roadmap and partner-delivered, with dates on the roadmap items
Response format
One of the clearest structural requests in the corpus, and one of the cheapest to make: separate the two proposals so a strong technical answer cannot be read through the fog of an attractive price, or the reverse.
- A technical proposal and a price proposal as separate documents
- Supporting materials supplied in advance of any session, so evaluation time is spent evaluating
- A stated delivery window for hands-on validation — buyers who set one name about three weeks
Evaluation criteria, published to vendors
Some buyers issue the rubric to vendors and ask them to respond against it directly. It costs nothing and it changes what comes back — a vendor answering your criteria is easier to compare than a vendor answering its own.
- The criteria list, ordered — the tiers below are the category's starting point, not your answer
- Who evaluates each criterion, so technical scoring stays with the people who will operate the platform
- How feedback is consolidated across the committee into a single recommendation
Commercial and contractual
The section procurement will own, and the one where buyers report the most avoidable pain — because the questions are cheap to ask now and expensive to raise after a preferred vendor exists.
- Pricing modelled at your projected volume, not today's — see what buyers actually pay for a CDP
- Every metered line named separately from the licence
- Commitment length, renewal terms, and what a departing customer receives, in what format, over what period
- What is in the statement of work, what is explicitly out, and who pays when scope changes
Security, risk and compliance
In regulated and listed organizations this is less a section of the RFP than a parallel process with its own calendar. Put it in the document early enough that it runs alongside the evaluation rather than after it.
- Third-party risk assessment requirements and who conducts them
- InfoSec and cybersecurity review, including what the vendor must produce and when
- Regulatory and data-residency constraints, with legal named as a participant rather than a reviewer
Process and dates
Working backwards from the date that is actually fixed — which, as below, is usually a contract expiry rather than the day the requirement appeared.
- Response deadline, evaluation window, validation window, decision date
- Which approvals sit after the decision date and how long each historically takes in your organization
- Named contact for questions, and whether a clarification round exists
What criteria should you use to evaluate CDP vendors?
Integration with the existing stack and cost form a clear first tier in these interviews; the ROI case, ease of use, scalability and security follow. That is the single most useful thing to know before you order Section 05.
Named by most buyers
Named often
Also named
Grouped by how often buyers named each criterion when describing their evaluation. Tiers rather than a strict rank: the interviews support the grouping, not a precise ordering within it. Bars show the tier, not vendor scores or importance weights.
How many vendors should a CDP RFP go to?
Three is the number buyers name most often, reached from early conversations with five or six and narrowed afterwards to two finalists for the commercial round. You now have the document; the rest of this page is how buyers run the selection around it. Where they give numbers, they cluster tightly.
| Stage | Vendors | What happens at this stage |
|---|---|---|
| Early conversations | 5–6 | Discovery calls and first demos, often before procurement is engaged at all. Some buyers build this list themselves; in multi-brand groups a shared central technology function builds it and presents back to the operating businesses. |
| Formal RFP | 3 | The number buyers name most. Enterprise policies mandating a competitive bid tend to set three as a floor — a minimum of three proposals, or a requirement to benchmark the preferred vendor against at least two others. |
| Finalists | 2 | Where pricing and contract negotiation happen with real leverage. Buyers describe narrowing to the two best competitors specifically so a second option stays live through the commercial round. |
Almost nobody describes issuing an RFP to more than about six vendors. Past that the evaluation load rises sharply — every response has to be read by every committee member — without the shortlist getting better.
Who decides on a CDP purchase?
Two separate bodies: a selection committee that evaluates, and a funding body that releases the money. They have different memberships, ask different questions and enter at different points — the structure most likely to surprise a first-time buyer, and the one that most often explains why a finished evaluation sits still for a month.
The selection committee
Evaluates. Cross-functional by design: business owners, brand or division leads, product management, analytics, and the technical stakeholders who will operate the platform.
Runs demos and validation sessions, applies the evaluation criteria, and consolidates feedback across members into a recommendation. Enters early and stays until a preferred vendor exists.
The funding body
Releases the money. An investment committee, an executive prioritization group, a board, or a CFO sign-off — depending on the organization.
Often sees the business case twice: once before any vendor is contacted, to authorize the spend in principle, and again at the end to approve the specific contract. It is judging the investment, not the product.
Several buyers describe building a financial proposal and taking it to leadership before procurement is engaged and before an RFI goes out. Where that first approval is skipped, the evaluation runs on the assumption that budget exists and discovers at the end that it has to be argued for — with a preferred vendor already waiting and no leverage left in the room.
What role does procurement play in a CDP purchase?
In these interviews, procurement appears primarily as a gate on cost and contract rather than as the function judging product fit. The business identifies the need and picks the field; procurement formalizes the process, ensures competitive bidding, handles legal and contractual negotiation, and pushes on price. Several buyers state explicitly that the business owner keeps the final decision.
Where buyers report it going wrong is expertise. A handful describe procurement adding time without adding judgment, and one names the mechanism directly: an internal procurement team with less category knowledge complicates the process, because the questions it can ask are commercial rather than technical. The buyers who avoid this bring procurement in early for input on the process rather than late for enforcement of it, and keep the technical scoring with the people who will operate the tool.
Intake is worth settling before anything else. Some organizations route every technology request through a ticket to procurement; others have a product manager whose job description includes writing requirements and running vendor evaluations. Either way, the route in determines who owns the document.
When should you start a CDP RFP?
Work backwards from the incumbent's contract expiry, then add the approval stages that sit after your decision date. Buyers time the RFP to the renewal rather than to when the need appeared, which is an easy pattern to get wrong. They open an RFP because an agreement is up mid-next-year; one buyer describes shortlisting about eighteen months before a contract ends. Where several replacements are queued, the one whose contract is month-to-month gets prioritized — not the one with the worst product.
So the RFP date is an output, not an input. On duration the interviews are thin and inconsistent — one buyer puts the whole selection at one to two months, another at three to six months end to end — so treat any published timeline, including this one, as weaker than your own organization's history with its last comparable purchase.
Run the risk track in parallel, not after
Buyers in pharmaceuticals, banking, insurance, credit unions and listed retail describe mandatory stages that have nothing to do with the product and cannot be compressed: a third-party risk management assessment, an InfoSec review, a cybersecurity risk assessment by the technology function, and legal or regulatory partners embedded in the evaluation rather than consulted at the end. One listed European retailer describes presenting to separate boards covering InfoSec, security, finance and ROI suitability, each a distinct approval.
None of this is unusual and none of it is negotiable. What it changes is the calendar: these reviews queue, they have their own cadences, and a selection that finishes in six weeks can wait months behind them. Which is why Section 07 belongs in the document that goes out, not in a follow-up after the decision.
What is the difference between a CDP RFI and a CDP RFP?
Among the most formal buyers the two stages are distinct and sequential. The RFI defines the technical and non-technical requirements, frequently written jointly with procurement, and filters the long list. The RFP goes to the survivors and asks for a priced, committed response. The distinction is not universally observed — some buyers issue a single document described interchangeably as a request for information or proposal. The practical test: if you already know your requirements, the RFI stage is doing no work and is worth collapsing.
Want this read against your own stack?
Get my read →When the standard RFP breaks down
Four exceptions worth planning for, because each one changes what the document has to do.
The mini-RFP. One consumer finance company judged the traditional structure too slow and inverted it: contact a wide set of vendors, ask each to state what it would take for them to be best in class at the problem, require materials in advance, and skip the formal apparatus entirely. They used the responses to map their own gaps rather than to score a predefined field — a different use of vendor effort, and one that produces a requirements list instead of a scorecard.
Validation without a full proof-of-concept. Worth knowing before you promise your committee one. Hands-on validation before signature is close to universal, but the form varies more than the RFP implies: a national specialty retailer says that for platforms as heavy to stand up as a CDP they usually do not run a full proof of concept at all, and others run one only after the shortlist exists or substitute a controlled demo on a small segment. Specify in Section 04 what you need to see proven and let vendors propose the format, rather than naming a POC and discovering it is impractical.
The evaluation you did not run. In multi-brand groups a shared technology function builds the long and short lists and presents them back to the operating businesses, which then evaluate against their own requirements. A sister brand already running the platform is treated as a reference that outranks anything a vendor supplies — which means your requirements document may be arguing against an internal precedent rather than against other vendors.
The bundle that changes the field. This one can end an RFP mid-flight regardless of how well it was written. A hotel group running three concurrent RFPs — CDP, loyalty and CMS — began evaluating a bundle instead when an incumbent enterprise vendor offered a discount for taking the CDP together with its loyalty technology. The competitive process was not lost on the merits; it was overtaken by a commercial offer nobody had scoped. Where an incumbent enterprise vendor sells an adjacent category to you, assume a bundle is coming and decide in advance how it gets evaluated.
The honest caveat
Buyers rarely credit their process for a good outcome, and rarely blame it for a bad one — the unhappy ones describe the product. So nothing here is a claim that a well-structured RFP produces a better platform. What the interviews support is narrower and still worth having: the buyers who describe the least friction are disproportionately the ones who knew their approval threshold before they started, who took the business case to the funding body early rather than late, and who worked the calendar backwards from a contract date instead of forwards from a requirement.
Common questions
What should a CDP RFP contain?
Eight sections cover what buyers describe requesting: the problem and where it came from; technical and non-technical requirements; the CDP capability requirements, grouped as data in, identity, audience and activation, governance and residency, and operating it; a response format separating the technical proposal from the price proposal; the evaluation criteria published to vendors; commercial and contractual terms; security, risk and compliance; and the process and dates. Integration with the existing stack and cost form the first tier of criteria buyers describe.
How many vendors should a CDP RFP go to?
Three is the number buyers name most often. The common shape is early conversations with five or six vendors, a formal RFP to three, and two finalists entering pricing and contract negotiation. Enterprise competitive-bid policies often set three proposals as the minimum.
What is the difference between an RFI and an RFP?
An RFI defines requirements and filters the long list; an RFP asks the shortlisted vendors for a priced, committed response. Among the most formal buyers the two are distinct and sequential, with the RFI often written jointly with procurement. Not every buyer observes the distinction — some issue a single document described as a request for information or proposal. The useful test is whether you already know your requirements. If you do, the RFI stage is doing no work.
Who should be on a CDP RFP evaluation committee?
A CDP selection committee typically includes business owners, brand or division leads, product management, analytics, and the technical stakeholders who will operate the platform. A separate funding body — an investment committee, executive prioritization group, or CFO and board sign-off — approves the spend, and often sees the business case before any vendor is contacted. Confusing the two is how an evaluation reaches a recommendation and then stalls.
When should you start a CDP RFP?
Work backwards from the incumbent's contract expiry, then add the approval stages that sit after your decision date. Buyers describe timing the RFP to a renewal rather than to when the need appeared — opening one because an agreement is up mid-next-year, or prioritising the replacement whose contract is month-to-month. In regulated or listed organizations, start the third-party risk and InfoSec reviews in parallel with the evaluation rather than after it, because those queue on their own cadences.
What does procurement control in a CDP purchase?
Procurement primarily controls cost, process and contract rather than product fit. It formalizes the process, ensures competitive bidding, handles legal and contractual negotiation, and pushes on price — while several buyers state explicitly that the business owner keeps the final decision.
Related reading
This page is the document and the process around it. For what you ask vendors face to face — the tests that separate a demo from a product — see questions to ask CDP vendors before you sign. Then what CDP buyers wish they'd known for the same corpus in hindsight, what buyers actually pay for a CDP for the commercial section, and real CDP implementation timelines for what happens after signature. The nearest sibling in another category is how to run a loyalty platform evaluation, where the corpus supports a buying-process framework rather than a document template, and the approval ladder stops lower. Weighing specific platforms: Tealium vs. Amperity and Hightouch vs. Segment.
Get this research made for your stack
How much process your purchase gets depends on your size, your sector and your contract value — and the requirements that matter depend on your stack. Do a 15-minute interview and get the version of this that applies to you: what buyers at your scale put in the document, who they had to get through, and how long it took.
Get my personalized read — 15-min interviewNo password · your interview is anonymized before it ever informs a page like this one.