CDP Implementation Phases, Timelines, And Deliverables

Blog

9/15/26

CDP Implementation Phases, Timelines, And Deliverables

A CDP implementation is a sequence of phases, each of which should produce specific named deliverables before the next phase begins. The phases are use case and scope definition, data audit and identity strategy, architecture finalization and integration build, testing and validation, go live and controlled launch, and post launch governance and adoption.

Most CDP implementation guides explain what happens during each phase. That is useful, but it is not enough for a program lead, project manager, engineering lead, or MarTech owner who needs to run the work.

The practical question is more specific: what does the team actually produce?

Without deliverable specifications, implementation phases become open ended. Discovery turns into a series of workshops with no signed output. The data audit continues indefinitely because no one defined what “complete” means. Identity resolution gets revisited every week because the assumptions were never documented. Go live becomes a soft open that never fully closes because acceptance criteria were never written down.

At Stable Kernel, we advise enterprise teams to manage CDP implementation with deliverable gates. Each phase should have:

  • A named output
  • Required content inside that output
  • A sign off owner
  • A timeline expectation
  • A gate criterion for moving forward
  • A known failure consequence if the output is skipped or incomplete

The goal is not bureaucracy. The goal is to prevent the most common CDP implementation failure: moving into the next phase before the current phase has produced the evidence required to proceed.

How To Use This CDP Implementation Reference

This page is designed as a project reference, not a conceptual overview.

For Program Leads Building A Project Plan

Use the phase sections below as a deliverable register. Each deliverable should become a task in the CDP implementation plan, with an owner, due date, review date, and completion criterion.

The phase gate criteria should become milestone criteria for project reviews. Instead of reporting that “Phase 2 is mostly complete,” the team should be able to say whether the data source inventory is complete, whether the data readiness report meets the threshold, whether the identity strategy document is signed, and whether the consent matrix is validated.

For Engineering Leads Reviewing A Vendor Plan

Use this guide to evaluate whether a vendor or systems integrator has proposed a complete implementation plan.

A vendor plan that says “Phase 1: Discovery workshops” without specifying the use case brief, stakeholder RACI, backlog, KPI baseline, and approval owner is not a gate controlled plan. It describes an activity, not an output.

For Teams Already Mid Implementation

Use the current phase as a diagnostic tool. Identify which deliverables are complete, which are incomplete, and which were informally closed. A CDP implementation often slips because a key deliverable exists only as a slide, workshop note, Slack thread, or verbal agreement.

The fastest way to regain control is to close the missing deliverable gap before advancing further.

The Six CDP Implementation Phases And Deliverables

A strong CDP project plan should name the deliverables for each phase, not just the activities.

Phase 1: Use Case And Scope Definition

Phase 1 typically takes one to three weeks. Its purpose is to define what the CDP must accomplish first and what will be deliberately deferred.

Primary Deliverables

The core deliverables are:

  • Use case brief for each initial use case
  • Stakeholder RACI matrix
  • Phase 2 backlog
  • Revenue KPI baseline document

The use case brief is the most important single document in the CDP implementation. It forces the team to translate broad goals into implementable requirements.

A complete use case brief should include:

  • A measurable business outcome
  • A quantified success metric
  • A pre-implementation baseline
  • Required data sources and fields
  • Required identity resolution logic
  • Activation channel
  • Delivery SLA
  • Named use case owner
  • Soft launch audience definition

“Improve personalization” is not a use case brief. “Send a triggered cart abandonment message within two hours to customers who add to cart but do not purchase, with a target 15 percent conversion lift against the current baseline” is a use case brief.

Sign Off Owner And Gate Criterion

The executive sponsor, marketing lead, and CDP program lead should sign off on Phase 1.

The phase is complete when the initial use case briefs are approved, each use case has a named owner, success metrics are defined, required data is identified, and deferred use cases are visible in the Phase 2 backlog.

The failure consequence is scope drift. Without a signed use case brief, every stakeholder can continue adding requirements because no one has defined what the first launch is supposed to prove.

Phase 2: Data Audit And Identity Strategy

Phase 2 typically takes two to five weeks and often overlaps with Phase 1. Its purpose is to confirm whether the data required by the initial use cases is ready for integration.

Primary Deliverables

The core deliverables are:

  • Data source inventory
  • Data readiness report
  • Identity strategy document
  • Consent management status matrix
  • Data quality remediation plan, if required

The data source inventory should document every priority source needed for the initial use cases. That includes CRM, ecommerce, POS, loyalty, mobile app, web events, customer service, email, paid media, and consent systems where relevant.

Each source entry should capture:

  • System name and type
  • Record count and event volume
  • Update frequency
  • Available customer identifiers
  • Field completeness
  • Known data quality issues
  • API or export availability
  • Consent status
  • Source owner

The data readiness report should confirm whether priority fields meet the completeness threshold required for the initial use cases. If a critical field is below the required threshold, the team needs a remediation plan with an owner and timeline before integration begins.

The identity strategy document should answer five questions:

  • What is the primary customer identifier?
  • Which match rules will be used across sources?
  • How will anonymous behavior merge into known profiles?
  • Will the CDP resolve individuals, households, accounts, or multiple levels?
  • How will incorrect profile merges be reversed?

Sign Off Owner And Gate Criterion

The data engineering lead, privacy or legal representative, and CDP program lead should sign off on Phase 2.

The phase is complete when priority sources are inventoried, data readiness is quantified, identity rules are documented, consent status is known, and remediation plans exist for blocking quality issues.

The failure consequence is integration rework. If identity rules or data quality gaps are discovered during Phase 3, the integration build may need to be redesigned midstream.

Phase 3: Architecture Finalization And Integration Build

Phase 3 usually takes four to ten weeks for packaged CDPs and four to twelve weeks for composable CDPs. Custom builds can run longer because the team may be building ingestion, identity, profile, and serving layers from components.

Primary Deliverables

The core deliverables are:

  • Architecture decision record
  • Integration test report by source
  • Identity validation report
  • Segment validation report
  • Consent enforcement verification
  • Data pipeline runbook

The architecture decision record should document the implementation decisions with long term consequences. For example, it should capture the ingestion tool, delivery semantics, identity graph approach, hot and cold profile store split, Profile API assumptions, activation approach, and monitoring model.

For each major decision, the ADR should include:

  • The decision made
  • Alternatives considered
  • Rationale
  • Assumptions
  • Trigger conditions for revisiting the decision

The integration test report should show that priority data sources are flowing correctly. It should include record count reconciliation, source to CDP field mapping, ingestion timing, failure handling, identity match rate, segment validation, activation test results, and consent enforcement validation.

Sign Off Owner And Gate Criterion

The data engineering lead, IT or security representative, and CDP program lead should sign off on Phase 3.

The phase is complete when priority sources are ingesting within expected record count ranges, identity resolution performs within the target range, initial segments reconcile against source systems, activation channels are connected, and opted out profiles are excluded from activation destinations.

The failure consequence is false confidence. The CDP may appear connected, but the first real campaign or personalization use case exposes incomplete ingestion, weak identity matching, or broken consent enforcement.

Phase 4: Testing, Validation, And Performance Certification

Phase 4 usually overlaps with Phase 3 and often runs during weeks eight to twelve in packaged or composable implementations.

Primary Deliverables

The core deliverables are:

  • Data accuracy validation report
  • Load test results report
  • Edge case test results
  • PII compliance verification
  • Go or no go recommendation memo

The data accuracy validation report should manually validate a sample of customer profiles against source systems. For enterprise implementations, the sample should include normal profiles and edge cases such as multiple email addresses, shared devices, merged accounts, deleted profiles, international characters, opt out status, and recently updated customer records.

The load test results report should confirm that the CDP can handle expected production volume. It should not only measure ingestion. It should also validate profile writes, Profile API latency, identity match rate, segmentation latency, activation behavior, and infrastructure cost at elevated traffic levels.

A useful Phase 4 test should answer:

  • Can the CDP ingest at expected peak volume?
  • Can profiles update without write failures?
  • Does identity match rate hold under load?
  • Does segmentation stay within the use case SLA?
  • Does Profile API p99 latency meet the required benchmark?
  • Do activation destinations receive the expected records?
  • Does infrastructure cost scale predictably?

The go or no go memo should be a signed decision record, not a verbal meeting outcome. It should summarize test results, open risks, accepted exceptions, launch configuration, monitoring plan, and rollback triggers.

Sign Off Owner And Gate Criterion

The CDP program lead, data engineering lead, IT or security representative, and executive sponsor should sign off on Phase 4.

The phase is complete when data accuracy is validated, performance testing meets defined thresholds, compliance handling is verified, edge cases are documented, and the executive sponsor signs the go or no go recommendation.

The failure consequence is a launch decision without evidence. If the system breaks after launch, the team cannot reconstruct what was tested, what passed, what failed, or which risks were accepted.

Phase 5: Go Live And Controlled Launch

Phase 5 typically takes weeks ten through fourteen for a packaged implementation, depending on soft launch length and launch complexity.

Primary Deliverables

The core deliverables are:

  • Signed go live checklist
  • Soft launch report
  • Full launch approval memo
  • Post launch monitoring dashboard
  • On call runbook

The go live checklist should confirm production readiness item by item. It should not rely on assumptions or informal status updates.

A complete go live checklist should confirm:

  • Priority data sources are flowing in production
  • Consumer lag is zero or within accepted range
  • Identity resolution is running in production
  • Initial segments are building on schedule
  • Activation destinations have been tested with seed audiences
  • Consent enforcement has been re verified in production
  • Monitoring dashboards are live
  • On call responsibilities are assigned
  • Rollback triggers are documented

The soft launch report should be produced after seven to fourteen days at limited scale, often 10 to 20 percent of the eligible audience. It should document audience size, delivery rate, data accuracy, system performance, opt out handling, early KPI movement, and any customer experience issues.

Sign Off Owner And Gate Criterion

The marketing lead, CDP program lead, and executive sponsor should sign off on Phase 5.

The phase is complete when the first use case has launched at controlled scale, monitoring data confirms expected behavior, the soft launch report is approved, and the full launch approval memo is signed.

The failure consequence is a “go live that is not really live.” The platform may be technically running, but if it cannot produce a marketer usable cohort without heavy engineering intervention, the go live gate has not been met.

Phase 6: Post Launch Governance And Adoption

Phase 6 runs for months three through nine and then becomes an ongoing operating model.

Primary Deliverables

The core deliverables are:

  • Data governance operating model
  • Champion user training completion record
  • Adoption metrics dashboard
  • Quarterly CDP program review agenda and scorecard
  • Use case expansion roadmap

The data governance operating model should assign named owners, not generic teams. Someone must own data quality monitoring. Someone must own identity match rate review. Someone must approve schema changes. Someone must audit consent enforcement. Someone must manage new data source intake.

The adoption metrics dashboard should track usage, quality, and business value.

Usage metrics may include:

  • Percentage of marketing users building or consuming audiences directly
  • Number of active use cases
  • Number of campaigns using CDP managed audiences
  • Time required to launch a new segment

Quality metrics may include:

  • Identity match rate trend
  • Data freshness by source
  • Activation delivery rate by destination
  • Segment count variance
  • Data quality incidents

Business metrics may include:

  • Use case performance against baseline
  • 90 day KPI progress
  • Conversion lift
  • Suppression accuracy
  • Churn intervention response
  • Revenue contribution where measurable

Sign Off Owner And Gate Criterion

The CDP program lead, change management lead, and executive sponsor should own Phase 6.

The phase is successful when champion users are trained, adoption metrics are visible, business users trust CDP outputs, governance responsibilities are assigned, and the CDP becomes the system of record for customer profile and audience decisions.

The failure consequence is shelfware. The platform works, but teams continue using old workflows because no one closed the adoption gap.

How Phase Timelines Vary By Architecture

The deliverables are similar across architectures, but timelines vary based on how much the organization configures versus builds.

Packaged CDP Timeline Pattern

Packaged CDPs usually move fastest through configuration but can slow down during source integration. The vendor platform may be ready before the enterprise data landscape is ready.

The longest phase is often Phase 3 because legacy systems, offline data, POS platforms, custom CRM exports, and consent sources can add weeks to the integration schedule.

Composable CDP Timeline Pattern

Composable CDPs depend heavily on warehouse maturity. If customer data is already clean, modeled, and trusted in the warehouse, implementation can move faster. If the warehouse contains raw operational data with inconsistent identifiers, Phase 2 and Phase 3 take longer.

The critical path is usually identity model design and validation.

Custom Build Timeline Pattern

Custom builds have the widest timeline range. The team may need to build streaming ingestion, identity graph logic, a hot profile store, cold storage, Profile API, monitoring, activation, and governance workflows.

The critical path is scope discipline. A custom build should prove the first use case with a minimum viable architecture before expanding into the full roadmap.

How Stable Kernel Produces And Reviews CDP Implementation Deliverables

Stable Kernel structures CDP implementation work around deliverable gates.

The objective is to create evidence that each phase is truly complete before the next phase begins. That evidence gives executives clearer visibility, gives engineering teams cleaner requirements, and gives business teams a stronger path to adoption.

New CDP Implementations

For new implementations, Stable Kernel helps define the initial use cases, produce the Phase 1 use case briefs, assemble the stakeholder RACI, conduct the data audit, document the identity strategy, validate integration outputs, and create the go live and governance deliverables.

The work is vendor neutral. Stable Kernel can support packaged, composable, and custom CDP paths based on the organization’s data infrastructure, engineering capacity, latency requirements, privacy obligations, and total cost of ownership.

Mid Implementation Deliverable Gap Reviews

For teams already in motion, Stable Kernel can review the current deliverable state against the framework above.

This often reveals that the project did not fail because the team lacked effort. It slipped because one or more gates were closed informally. The identity strategy was discussed but never documented. The integration test report exists as an email thread. The go live checklist was verbal. The governance model was labeled “ongoing” with no owner.

A deliverable gap review identifies which outputs are missing, which are incomplete, and which need remediation before the program should advance.

Stable Kernel helps enterprise teams produce the CDP implementation deliverables that prevent phase slippage, reduce rework, and give leaders a clearer view of whether the program is actually ready for the next milestone.

Reflection Questions For Executives

  1. Which phase is the CDP implementation currently in, and what deliverable proves that phase is complete?
  2. Do the use case briefs define measurable business outcomes, required data, activation channels, and named owners?
  3. Has the data audit produced a signed data source inventory and data readiness report?
  4. Is the identity strategy documented, or is it still living in workshop notes?
  5. Does the integration test report show measured results against thresholds, or only a general status update?
  6. Has the go or no go decision been documented with accepted risks and rollback triggers?
  7. Are governance responsibilities assigned to named people after launch?
  8. Is adoption being measured alongside business value?

FAQ

What Are The Phases Of CDP Implementation And What Does Each Phase Produce?

A CDP implementation has six core phases. Phase 1 produces use case briefs, a stakeholder RACI, a Phase 2 backlog, and KPI baselines. Phase 2 produces a data source inventory, data readiness report, identity strategy document, consent matrix, and remediation plan. Phase 3 produces an architecture decision record, integration test report, identity validation report, segment validation report, consent verification, and pipeline runbook. Phase 4 produces data accuracy validation, load test results, edge case results, PII verification, and a go or no go memo. Phase 5 produces the go live checklist, soft launch report, launch approval memo, monitoring dashboard, and on call runbook. Phase 6 produces the governance model, champion user records, adoption dashboard, quarterly scorecard, and expansion roadmap.

What Is The Most Important Deliverable In A CDP Implementation?

The use case brief is the most important deliverable because it defines the scope, data requirements, activation path, success metric, and owner for the first value producing use cases. If the use case brief is vague, every downstream phase becomes vague.

What Deliverables Are Required Before CDP Integration Begins?

Before integration begins, the team should have a signed data source inventory, data readiness report, identity strategy document, consent management status matrix, and remediation plan for any blocking data quality issues. These documents prevent Phase 3 from being redesigned after integration work has already started.

How Long Does Each CDP Implementation Phase Take?

For packaged CDPs, Phase 1 often takes one to three weeks, Phase 2 takes two to five weeks, Phase 3 takes four to ten weeks, Phase 4 overlaps Phase 3 and often runs weeks eight to twelve, Phase 5 takes two to four weeks, and Phase 6 runs for three to nine months after launch. Composable and custom builds vary more based on warehouse maturity, identity complexity, and engineering capacity.

What Is A CDP Phase Gate Criterion?

A CDP phase gate criterion is the documented condition that must be met before the next phase begins. For example, Phase 2 is complete only when priority sources are inventoried, data readiness is quantified, identity rules are signed off, and consent status is known. Gate criteria prevent phases from being closed informally.

What Should A CDP Data Source Inventory Include?

A CDP data source inventory should include system name, system type, record count, update frequency, available identifiers, field completeness, known data quality issues, API or export availability, consent status, and source owner for every priority source required by the initial use cases.

What Should A CDP Integration Test Report Include?

A CDP integration test report should include source record count reconciliation, ingestion completeness, identity match rate, false positive review, segment validation, activation channel testing, consent enforcement verification, and end to end latency against the use case SLA.

What Should A CDP Go Live Checklist Include?

A CDP go live checklist should confirm production data flows, identity resolution, segment builds, activation destination testing, consent enforcement, monitoring dashboard readiness, on call ownership, rollback triggers, and signed approval from the appropriate launch owners.

Can Stable Kernel Help Produce Or Review CDP Implementation Deliverables?

Yes. Stable Kernel helps enterprise teams produce CDP implementation deliverables for new programs and review deliverable gaps in existing programs. That includes use case briefs, data audits, identity strategy documents, integration test reports, go live checklists, governance models, and adoption dashboards.