Adobe Real-Time CDP RFP Template

Before You Issue a Adobe Real-Time CDP RFP

Real-Time CDP RFPs go wrong by boiling the ocean: every source connected, every schema modeled, value delivered in some future phase that never arrives. The corrective is to make the RFP use-case-first. Name the two or three activation use cases that justify the license — suppression of converted customers from paid media, say, or authenticated web personalization — and require the implementation plan to reach the first one within a fixed window.

Identity architecture and governance are where the specialist earns their fee. Which identity namespaces, how merge policies resolve conflicts, how consent is enforced at activation rather than asserted in a policy document — these decisions are cheap to make correctly at design time and brutally expensive to remake later. Demand written answers, not assurances.

What the Adobe Real-Time CDP Sections Cover

• Two or three activation use cases the build is judged on
• Source systems, their owners and their real refresh rates
• Identity namespaces and the graph they produce
• Profile volume assumptions sitting behind your licence
• Consent signals enforced at activation, not merely stored
• A runbook for adding the fourth audience without them

Writing the Adobe Real-Time CDP Scope of Work

Write the scope backwards from named activations. For each use case, state the destination, the audience definition in business terms, the latency it requires, and the measurement that will prove it worked. A suppression use case that saves media spend and an onsite personalization use case that needs edge-resident profiles place completely different demands on the architecture, and a scope written as a list of sources to connect will produce a platform full of data and short of outcomes. Order the use cases, and say which one the first phase must deliver.

Specify the source side with an honest account of its condition. For each system, name the owner, the extraction mechanism, whether it can stream or only batch, the identifiers it carries, and the known quality problems. Consent and preference data deserves its own line, including where the authoritative record lives, because activation legality depends on it being present and current rather than merely existing somewhere. If a source needs work from another team before it can be ingested, that dependency belongs in the scope with a named owner rather than in the vendor's assumptions.

Make identity and merge policy explicit design deliverables with their own review. The scope should require a namespace inventory, a statement of which identity is primary for profile resolution, the merge precedence between conflicting sources, and the treatment of shared devices and household situations. Where you operate in several regions, say whether profiles are unified globally or kept regionally separate, since that decision has both regulatory and architectural consequences that are extremely expensive to revisit once profiles are fragmented.

Put consumption governance in scope, because this platform bills on what you put in and keep. State who decides what is ingested into profile versus left in a data lake dataset, what retention each dataset gets, and who reviews profile volume as sources are added. Then define done at the activation end: a named audience of a stated size reaches a named destination within a stated latency, with the match rate measured at the destination rather than assumed, and with a documented check that consent state was honoured for every profile in it.

Requirements That Actually Separate Adobe Real-Time CDP Proposals

• Destination match evidence — require match rates to be measured at each destination on comparable work, along with what the vendor does when a match rate comes in materially below expectation rather than reporting it as a platform characteristic.
• Streaming versus batch segmentation — ask which of your audiences genuinely need streaming evaluation and which do not, and require the cost and complexity difference to be stated, since everything evaluated in real time is rarely justified.
• Consent enforcement mechanics — require a description of how consent is expressed as governance labels and policies inside the platform, and how an attempted activation that violates a policy is blocked rather than merely flagged in a report.
• Profile volume management — ask how they control which records become profiles, how dormant or low-value profiles are handled, and what levers exist if profile counts approach a licensed threshold.
• Schema design discipline — require a position on reusing standard field groups versus creating custom ones, because a heavily customised schema makes later connections, destinations and Journey Optimizer work harder than it needs to be.
• Source data quality gates — ask what validation runs before a source reaches the profile store, and what happens to a daily load that arrives malformed, since a bad batch that merges into profiles is expensive to unwind.
• Audience lineage — require a way to see which audiences depend on which fields, so that a schema change does not silently break an activation nobody is watching.

Common Mistakes in Adobe Real-Time CDP RFPs

• ✕ Connecting every source before any audience is activated, burning months of license with zero value shipped.
• ✕ Identity namespace and merge-policy design treated as configuration detail rather than the core architecture.
• ✕ Consent enforcement asserted in slideware but never implemented in governance labels and policies.
• ✕ Underestimating source data quality work — the CDP faithfully unifies garbage.
• ✕ No operational runbook, so the platform stalls when the implementation team rolls off.

• ✕ Scoping the platform as a marketing project when the required sources are owned by finance, service and operations teams who have not agreed to deliver anything and have their own priorities.
• ✕ Assuming the paid media destinations will accept the audiences as designed, without checking each platform's minimum audience size, refresh frequency and identifier requirements before the segmentation is built.
• ✕ Building audience definitions against fields that only a fraction of profiles actually carry, producing segments far smaller than the business case assumed and no diagnostic to explain why.
• ✕ Leaving the right to erasure and access request workflow out of scope, so the platform becomes a new system of record for personal data with no tested process for removing someone from it.

Questions Worth Asking Adobe Real-Time CDP Vendors

1. For our named use cases, how many days to first activated audience, and what does the critical path look like?
2. Show an identity design you shipped: namespaces, merge policies, and how you validated match rates.
3. How do you implement consent enforcement in the platform itself, and how is it tested?
4. What data-quality gates do you apply to sources before they enter the profile?
5. What does your operational handover include — runbooks, monitoring, and who answers questions in month four?

How to Weight the Adobe Real-Time CDP Evaluation

Weight time to first activation above breadth of proposed architecture. The most reliable predictor of a failed customer data platform program is a long foundation phase with no activated audience, because internal support decays before value appears. A proposal that reaches a real destination with a real audience early, even a modest one, and builds outward from there, is managing the political risk that kills these programs as often as the technical risk does.

Give identity and governance design more weight than integration count. Connecting a source is largely mechanical; deciding how identities merge, and which merges you would rather not make, is architecture with regulatory consequences. Since these decisions are cheap to make well at the start and painful to remake after profiles exist, evidence of deliberate identity design should outrank a longer list of connectors in your scoring.

Score operating cost awareness alongside capability. This is a consumption-priced platform where architectural choices translate directly into an invoice, and a vendor who is indifferent to what gets ingested, how long it is retained and how often audiences are evaluated will build something correct and unaffordable. Treat a proposal that models the consumption implications of its own design as evidence of experience, not as excessive caution.