How To Create A CDP Integration Plan

Definition: A CDP integration plan is the technical planning document that governs the Phase 3 integration build for a customer data platform implementation. It sits between the Phase 2 data audit and identity strategy, which define what data the CDP needs and where that data lives, and the Phase 3 integration test report, which proves whether the integrations delivered what was planned.

A CDP integration plan is not just a list of source systems.

A list might say the team will connect Salesforce, Shopify, a mobile app, a POS system, a loyalty platform, and an email platform. That is useful inventory, but it does not explain how those systems will connect, which ones should be built first, which ingestion method each source requires, which fields map to the canonical customer profile, which identifiers contribute to identity resolution, or how the team will prove each integration is complete.

That is the job of the integration plan.

For each source system and activation destination, the plan should specify the connector type, ingestion method, latency tier, source to CDP field mapping, event taxonomy, identity resolution identifiers, dependency sequence, validation criteria, and ownership model.

Without that plan, Phase 3 becomes a series of individual connector decisions made by whoever is available at the time. One engineer configures a native CRM connector. Another builds a server side SDK event stream. Another maps mobile app events to the CDP in a different naming format. A program manager asks whether the integration is “done,” but no one has defined what done means.

At Stable Kernel, we advise enterprise teams to treat the CDP integration plan as a signed technical artifact before the integration build begins. It should translate the use case briefs, data audit, identity strategy, and statement of work into a build sequence the engineering team can execute and the program team can validate.

What A CDP Integration Plan Is Not

Teams often confuse the integration plan with adjacent implementation documents. The distinction matters because each document answers a different question.

It Is Not The Data Source Inventory

The data source inventory documents what source systems exist, who owns them, what data they contain, how frequently they update, what identifiers they provide, and what quality issues were found during the audit.

The integration plan uses that inventory as input, but it goes further.

It answers how each system will be connected, which connector type will be used, whether the source should stream events or send batch files, which fields map to the CDP schema, and what validation criteria apply.

A team can have a strong data source inventory and still have no shared build plan.

It Is Not The Architecture Decision Record

The Architecture Decision Record documents the major architecture choices. It may specify the streaming tool, warehouse, identity graph approach, hot and cold profile store split, Profile API pattern, and activation architecture.

The integration plan operates one level lower.

The ADR might say the organization will use Kafka for streaming ingestion. The integration plan says the ecommerce order service will publish order_completed events to Kafka, using the server side order service producer, with the fields mapped to the CDP’s canonical order schema and validated by the relevant data contract.

It Is Not The SOW Scope Definition

The statement of work defines what systems and deliverables are contractually in scope.

The integration plan explains how the in scope systems will actually be connected.

The SOW may say Salesforce CRM is in scope. The integration plan should say Salesforce will connect through the packaged CDP’s native connector, ingesting account and contact records daily at a defined time, mapping Account ID, Email, Phone, and lifecycle fields into the canonical customer profile, and treating Salesforce as authoritative for email when conflicts exist.

The SOW governs the contract. The integration plan governs the build.

The Eight Sections Of A Complete CDP Integration Plan

A complete CDP integration plan should include eight sections. Each section should produce a specific artifact the team can review before the build begins.

Section 1: Integration Scope And Use Case Mapping

The first section should map each initial use case to the source systems and activation destinations required to deliver it.

This prevents integration scope from expanding without a business reason.

A useful mapping should include:

• Use case name
• Business outcome
• Source systems required
• Activation destinations required
• Required customer identifiers
• Required events or attributes
• Latency requirement
• Use case owner

For example, a cart abandonment use case may require ecommerce events, web or mobile behavioral data, order status, consent status, and an email platform. A loyalty personalization use case may require loyalty tier, recent transactions, product affinity, offer eligibility, and an onsite personalization destination.

The rule is direct: every integration in Phase 3 should trace to at least one initial use case. If an integration does not support the first use cases, it belongs in the Phase 2 backlog rather than the current build.

A thin version of this section says, “We will integrate our major customer systems.” That creates scope ambiguity. A strong version explains exactly why each integration is needed.

Section 2: Connector Classification

The second section should classify every source system and activation destination by connector type.

Connector type has one of the biggest impacts on timeline, engineering effort, support model, and maintenance burden.

Native Pre-Built Connector

A native connector is maintained by the CDP platform or adjacent tool. It is usually the fastest path when the source or destination is already in the platform’s connector catalog and the integration requirements fit the standard configuration.

Native connectors are usually best for common systems like CRM, paid media, email, analytics, and marketing automation platforms when standard objects and fields are sufficient.

Build time is often short, but the plan should still document field mappings, sync cadence, authentication, ownership, and validation criteria.

Managed Connector Through Reverse ETL Or iPaaS

A managed connector uses a third party tool such as a reverse ETL platform or integration platform to move data between the warehouse, CDP, and destinations.

This is often useful when a destination is not supported natively by the CDP but is supported by another tool in the stack.

The benefit is reduced custom engineering. The tradeoff is third party dependency, sync configuration, monitoring responsibility, and possible additional cost.

Server Side SDK Integration

A server side SDK integration is used when an application, service, or backend system can emit events directly into the CDP or event pipeline.

This is common for web applications, mobile applications, ecommerce order services, subscription systems, and customer profile services.

Server side SDKs are useful when the business needs reliable event capture, faster event availability, or reduced dependence on browser side tracking. They require application engineering time and must be aligned to the canonical event taxonomy.

Custom Connector

A custom connector is required when no native, managed, or SDK based option exists.

This is common with proprietary POS systems, legacy CRM systems, industry specific platforms, on premise systems, custom transaction systems, or systems with flat file exports and no modern API.

Custom connectors are the highest risk connector type. They require API analysis, authentication handling, rate limit management, retry logic, error handling, monitoring, testing, and ongoing maintenance. They should never be hidden inside a generic line item called “system integration.”

If the plan reveals more than two Tier 1 custom connectors, the Phase 3 timeline should be revisited before work begins.

Section 3: Integration Priority And Sequencing

A CDP integration plan should not attempt to connect every source system at once.

The build order should be based on use case need, identity importance, connector complexity, and dependency chains.

The Three Question Sequencing Framework

For each integration, ask three questions:

• First, is this integration required for one of the initial use cases? If yes, it may belong in Tier 1 or Tier 2. If no, it belongs in the Phase 2 backlog.
• Second, does this source system provide the primary identity resolution identifier? If yes, it should move earlier in the build sequence because identity validation cannot happen without it.
• Third, is the connector native, managed, SDK based, or custom? Native and managed connectors can often move faster. Custom connectors should be scoped early, but their risk must be reflected in the timeline.

Tier 1: Build First

Tier 1 integrations are required for the initial use cases and identity resolution. These are the systems that must be connected before the team can validate whether the CDP is creating usable profiles.

Tier 1 often includes CRM, ecommerce, loyalty, consent, core behavioral events, and the primary activation channel for the first use case.

Tier 2: Build Second

Tier 2 integrations support one or two initial use cases, provide secondary identifiers, or enrich the customer profile after the core data foundation is validated.

These might include support systems, mobile messaging, secondary behavioral sources, paid media destinations, or enrichment systems.

Tier 3: Defer Or Backlog

Tier 3 integrations are not required for the first use cases or require high effort custom work without immediate business value.

These should be documented, not ignored. The Phase 2 backlog gives stakeholders confidence that their systems are visible without adding them to the current build.

The sequencing rule is simple: let the hardest required integration set the timeline, not the easiest one.

Section 4: Ingestion Method Assignment

Every source system should have an assigned ingestion method. The right method depends on the use case latency requirement, source system capability, data volume, and reliability need.

Streaming Ingestion

Streaming ingestion is appropriate when events must become available quickly. This usually applies to web events, mobile app events, order events, conversion events, fraud signals, consent changes, or real time behavioral signals.

Streaming is usually required for in session personalization, real time suppression, cart abandonment triggers, AI decisioning, or any use case where profile freshness materially changes the outcome.

API Based Ingestion

API based ingestion is useful when the source system can push changes through webhooks, event callbacks, or API calls but does not support a full streaming pipeline.

This can work for CRM updates, support ticket creation, subscription status changes, loyalty changes, and operational events that need to arrive in seconds or minutes rather than hours.

Batch ETL Or ELT

Batch ingestion is appropriate when hourly or daily freshness is sufficient.

This commonly applies to historical backfills, full CRM exports, offline data sources, warehouse enrichment, reporting oriented data, and slower moving customer attributes.

Batch is not weaker by default. It is the right choice when the use case does not justify streaming complexity.

The mistake is using “real time where possible” as the ingestion strategy. A strong plan assigns the method per source and explains the use case justification.

Section 5: Event Taxonomy And Naming Convention

The event taxonomy defines the canonical names and schemas for the behavioral events the CDP will ingest.

This is one of the most important standardization decisions in the plan.

Without an event taxonomy, the same business action can arrive under different names from different systems. A product view might appear as PRODUCT_VIEWED in ecommerce, pdp_view in the mobile app, and productView in web analytics. The CDP may ingest all three, but segmentation and reporting become harder, less accurate, and more expensive to govern.

What The Taxonomy Should Include

The taxonomy should define:

• Canonical event name
• Required properties
• Optional properties
• Data types
• Accepted values
• Source system event name mapping
• Identity fields
• Consent fields
• Timestamp rules
• Schema version
• Data contract location

A practical naming convention is [noun]_[past_tense_verb], such as product_viewed, cart_added, order_completed, account_created, and page_viewed.

The point is not stylistic consistency. The point is that downstream segmentation, activation, analytics, and AI models depend on stable event meaning.

Section 6: Field Level Data Mapping

Field level data mapping specifies how source fields translate into the CDP’s canonical customer profile schema.

This section should be completed before build begins. Waiting until implementation to decide mappings creates rework.

A complete field mapping row should include:

• Source system
• Source field name
• CDP target field
• Data type
• Transformation required
• Identity role
• Consent sensitivity
• Authoritative source rule
• Conflict resolution rule

For example, Salesforce may provide Email, Shopify may provide customer.email, and the mobile app may provide user.emailAddress. The CDP target field may be customer.email. The plan should define whether values are lowercased, hashed, validated, normalized, or suppressed based on consent.

Conflict rules matter because multiple systems may provide different values for the same attribute. The plan should state which source is authoritative for each major field. Salesforce may be authoritative for email. The loyalty platform may be authoritative for loyalty tier. The mobile app may be authoritative for device ID.

Without conflict rules, the CDP can overwrite good data with stale data.

Section 7: Identity Resolution Identifier Specification

The integration plan should define what each source system contributes to identity resolution.

A CDP cannot resolve customer profiles well if the team does not document which identifiers each system provides and how reliable those identifiers are.

For each source, the plan should specify:

• Identifier fields
• Identifier type
• Reliability class
• Anonymous to known trigger
• Merge rule
• Conflict rule
• Source priority
• Validation method

Deterministic identifiers include email, phone, loyalty ID, account ID, CRM ID, ecommerce customer ID, and authenticated user ID. Probabilistic identifiers may include device attributes, IP patterns, location patterns, or behavioral similarity.

The plan should also document anonymous to known transitions. A mobile app may move from anonymous device ID to authenticated user ID when the user logs in. Web behavior may move from anonymous cookie ID to known customer profile after form submission or account creation.

This section connects the integration plan to the identity strategy. The identity strategy defines the merge rules. The integration plan defines how each system contributes data into those rules.

Section 8: Integration Validation Criteria

The final section defines the measurable pass or fail criteria that the integration test report will verify.

A weak validation standard says, “We will test that the integration works.”

A strong validation standard defines thresholds.

Ingestion Completeness

The plan should specify expected record counts and acceptable variance.

For example, the CDP event count for ecommerce orders should reconcile within 5 percent of the ecommerce platform’s order count for the same validation window.

Field Completeness

The plan should specify completeness thresholds for key fields.

For example, the CRM integration may require 80 percent completeness on email and account ID, while ecommerce order events may require 95 percent completeness on product ID, order ID, total value, and currency.

Schema Compliance

The plan should require events to pass data contract validation at the ingestion boundary.

For Tier 1 sources, schema compliance should be strict. Events that fail validation should route to a dead letter queue, generate alerts, and be reviewed before replay.

Identity Resolution Contribution

The plan should measure whether the integration contributes usable identifiers to the identity graph.

For example, the validation report may measure what percentage of ecommerce customers matched to a known CRM profile or loyalty profile after ingestion.

The integration test report should show the measured value, threshold, pass or fail result, and remediation owner for every criterion.

The Native Vs Custom Connector Decision

Connector type determines the Phase 3 build risk more than almost any other integration planning decision.

When Native Connectors Are The Right Choice

Use a native connector when the CDP platform supports the system, the required objects are available, the standard sync behavior fits the use case, and the connector can meet the required latency.

Native connectors are usually best for speed. They reduce engineering effort and shift connector maintenance to the vendor.

The plan should still validate the connector against the actual use case. A native connector that cannot access a required object or field may not be sufficient.

When Managed Connectors Are The Right Choice

Use a managed connector when a reverse ETL tool, iPaaS, or integration platform already supports the source or destination.

This is often useful for activation destinations or warehouse based data movement.

The main risk is operational dependency. The team must monitor sync failures, API limits, field mapping changes, and third party connector behavior.

When SDK Instrumentation Is The Right Choice

Use server side or mobile SDK instrumentation when the source application needs to emit behavioral events directly.

This is common for web applications, mobile apps, ecommerce services, order services, and event driven systems.

The plan should include SDK versioning, event taxonomy implementation, QA across app versions, schema validation, and release coordination.

When Custom Connectors Are Unavoidable

Custom connectors are appropriate when no standard option exists and the system is required for the initial use cases.

The plan should name the lead engineer, expected build time, authentication requirements, error handling rules, retry logic, monitoring plan, and long term maintenance owner.

A custom connector is not a one time task. It becomes software the organization must maintain.

Enforcing The Event Taxonomy With ODCS Data Contracts

The event taxonomy only works if it is enforced.

A taxonomy stored in a spreadsheet or planning document can be ignored by source systems. A source team may rename a field, change a data type, remove a required property, or modify an event payload without realizing that downstream segmentation, activation, and identity logic depend on that schema.

ODCS data contracts provide the enforcement layer.

Why Data Contracts Belong In The Integration Plan

The integration plan should specify which data contract applies to each integration and where validation occurs.

The data contract should define required fields, optional fields, data types, allowed values, timestamp format, schema version, and failure handling rules.

If a source sends a malformed event, the event should not silently become a bad profile attribute. It should fail validation, route to the correct dead letter queue, and alert the named owner.

This prevents schema drift from becoming invisible CDP data quality degradation.

What The Data Contract Section Should Specify

For each integration, the plan should document:

• Contract file location
• Contract owner
• Validation point
• Failure handling rule
• DLQ topic or queue
• Alert owner
• Replay eligibility
• Schema change notification process

The schema change process is especially important. Source system teams should notify the CDP team before production schema changes are deployed. The CDP team should update the data contract, field mapping, and downstream validation logic before the change reaches production.

How Stable Kernel Produces CDP Integration Plans

Stable Kernel produces the CDP integration plan as a formal Phase 3 planning deliverable before the integration build begins.

The process starts with the Phase 1 use case briefs and Phase 2 data source inventory. Every integration must trace to a named initial use case. Integrations that do not support the first use cases are documented in the Phase 2 backlog rather than absorbed into Phase 3 scope.

Sequenced By Complexity, Not Convenience

Stable Kernel applies the three question sequencing framework to every integration: does it support the initial use cases, does it provide an identity critical identifier, and what connector type does it require?

This sequencing determines the Phase 3 build order and timeline. Stable Kernel does not commit to a Phase 3 end date until the highest complexity integrations have been scoped and estimated.

Validated Through Data Contracts And Test Criteria

For Tier 1 and Tier 2 integrations, Stable Kernel defines event taxonomy, field mapping, identity identifiers, and ODCS data contracts at the ingestion boundary.

The integration plan also defines the validation criteria that will appear in the integration test report. That includes ingestion completeness, field completeness, schema compliance, identity contribution, activation success, and remediation ownership.

Built For Operational Handoff

A strong integration plan is useful beyond the implementation project. It becomes part of the operating documentation for the CDP.

When a source system changes its schema, when an activation destination fails, when identity match rate drops, or when a new use case requires an additional source, the integration plan tells the team how the current data flows were built and why those decisions were made.

Stable Kernel helps enterprise data engineering teams produce CDP integration plans that are use case traceable, sequenced by complexity, enforced by ODCS data contracts, and validated against measurable completion criteria.

Reflection Questions For Executives

1. Can every Phase 3 integration be traced to one of the initial CDP use cases?
2. Has each source system been classified by connector type, build effort, and maintenance owner?
3. Do we know which integration is the hardest and whether it sets the Phase 3 timeline?
4. Does every source system have an assigned ingestion method based on use case latency requirements?
5. Is the canonical event taxonomy defined before SDK or connector work begins?
6. Have field mappings and conflict rules been documented before build starts?
7. Does each source system’s identity contribution align to the identity strategy?
8. Are validation criteria measurable enough to support a clear pass or fail decision?

FAQ

How Do You Create A CDP Integration Plan?

Create a CDP integration plan in eight sections: integration scope and use case mapping, connector classification, integration priority and sequencing, ingestion method assignment, event taxonomy and naming convention, field level data mapping, identity resolution identifier specification, and integration validation criteria. Each section should produce a concrete artifact the build team can execute and the program team can validate.

What Is A CDP Integration Plan?

A CDP integration plan is the technical planning document that governs the Phase 3 integration build in a customer data platform implementation. It specifies how each source system and activation destination will connect to the CDP, including connector type, ingestion method, latency tier, field mapping, event taxonomy, identity identifiers, dependency sequence, and validation criteria.

Which CDP Integrations Should You Build First?

Build the integrations required for the initial use cases first, especially systems that provide the primary identity resolution identifier. Native and managed connectors can often be scheduled earlier because they require less engineering effort. Custom connectors should be scoped early because they often set the timeline, but they should not block unrelated Tier 1 work when independent build paths are possible.

What Is The Difference Between Native And Custom CDP Connectors?

A native CDP connector is maintained by the CDP vendor or platform and usually requires configuration, mapping, testing, and validation. A custom connector is built by the data engineering team when no native, managed, or SDK option exists. Native connectors are faster and easier to maintain. Custom connectors require engineering build, monitoring, error handling, retry logic, API change management, and long term ownership.

What Ingestion Methods Should A CDP Integration Plan Specify?

A CDP integration plan should assign streaming, API based, or batch ingestion to each source. Streaming is best for real time behavioral events and use cases where profile freshness matters. API based ingestion works for systems that can push updates through webhooks or event callbacks. Batch ingestion works for historical data, slower moving attributes, and use cases where hourly or daily freshness is sufficient.

What Is An Event Taxonomy In A CDP Integration Plan?

An event taxonomy is the standardized set of event names, required properties, data types, and source mappings used across all systems sending behavioral data into the CDP. It ensures that the same business action uses the same canonical event name across web, mobile, ecommerce, and server side systems. The taxonomy should be enforced at the ingestion boundary with data contracts.

What Is Field Level Data Mapping In A CDP Integration Plan?

Field level data mapping defines how each source field maps to the CDP’s canonical customer profile schema. It should include source field name, CDP target field, data type, transformation required, identity role, consent sensitivity, authoritative source rule, and conflict resolution rule. This prevents implementation rework and avoids overwriting trusted profile attributes with lower quality data.

What Are Integration Validation Criteria?

Integration validation criteria are the measurable pass or fail standards used to determine whether each integration is complete. They should include ingestion completeness, field completeness, schema compliance, identity resolution contribution, activation success, and latency where relevant. These criteria become the basis for the Phase 3 integration test report.

Can Stable Kernel Help Create A CDP Integration Plan?

Yes. Stable Kernel helps enterprise teams create CDP integration plans that map integrations to use cases, classify connectors, sequence the build, assign ingestion methods, define event taxonomy, document field mappings, specify identity identifiers, enforce ODCS data contracts, and establish validation criteria for the integration test report.