CDI and CDP Implementation Strategy

Suggest Edits

Objective:

This guide aims to provide instructions for implementing both Customer Data Infrastructure (CDI) and Customer Data Platform (CDP) within the same martech stack. As each tool offers a range of features, various approaches exist for data pipeline management, customer profiling, segment creation, and marketing activation. To ensure the successful implementation and maintenance of CDI and CDP, it is essential to follow best practices that establish the roles of each platform in the customer journey and define their relationship.

Implementation:

To effectively implement a CDI and CDP, follow these steps to minimize redundancies in the architectural process flow.

Identify the key roles of each platform in the martech strategy, including:

  1. Determining which platform will handle website tagging and collect web-based data.
  2. Defining the data that will flow directly into the CDP and what requires processing through CDI before reaching the CDP.
  3. Scoping identity resolution and determining how each tool will contribute to resolving identities.
  4. Establish which activation/conversion channels will be connected to CDI and CDP.

Consider the following best practices when deploying these solutions within the same organization:

  1. Simultaneous implementation: To ensure seamless data flow through CDI, it is crucial to understand the desired end state of the data, which is the CDP. Without knowledge of the transformation capabilities of the CDP, the CDI data piping process may need reworking after CDP implementation.
  2. Limit duplicate features: Decide which platform will be the primary solution for identity resolution, data transformation, segmentation, activation, and personalization. A complex architecture with overlapping features in both systems will be harder to maintain.

Key Roles

Before loading data into either platform, it is important to clarify the roles each platform will play in the martech strategy. Focus on answering the following questions:

  1. Why was a CDP purchased? (e.g., activation, segmentation, CMS, modeling, client-side interaction)
  2. Why was a CDI purchased? (e.g., data collection, routing, transformation)
    Once these questions are answered, identify the areas of overlap between the two tools.

This identification will help identify potential bottlenecks during the architectural design phase. By defining the role of each platform in activation, it becomes easier to determine which features within each tool should be utilized. This approach streamlines scoping and data onboarding.

Data Flow and Schema Creation:

After identifying the roles of CDI and CDP, determine the primary activation use cases. These use cases, or tactics will drive the types and formats of data to be passed to each tool. CDI can handle and pipe data unrelated to marketing activation or the user journey to downstream tools outside the CDP. On the other hand, the CDP should primarily contain data utilized for marketing activation. While there may be an overlap in the CDI and CDP data schemas, the intended use of that data will likely differ. The CDP should follow the user's interaction across the martech stack, while CDI aggregates data from upstream channels to enable the CDP.

Identity Resolution:

Tracking the user's conversion through funnel stages quickly is crucial for a seamless user journey. Design an identity resolution strategy that stitches data and unifies profiles as soon as more customer information becomes available. Both CDI and CDP will have identity resolution capabilities, and they should work together to create an agile ID resolution strategy that provides marketers with a holistic view of consumers. The CDI and CDP may use different identifiers, but collaboration ensures efficient data management.

Activation Channel Scoping:

The final step is to determine which platform will handle activation. If both platforms handle activation, understand which channels each system (CDI or CDP) will connect to. Differentiate between client-side and server-side integrations.

Client-side integrations are typically used for:

  1. Activating anonymous profiles through platforms like Google, Facebook, LinkedIn, etc.
  2. Personalization through modals, content recommendations, inline elements, etc.
  3. Sharing segment membership with advertising tools.
  4. JavaScript tag implementation.
  5. Cookie synchronization.

Server-side integrations are usually employed for:

  1. Known activations (e.g., email, advertising, etc.).
  2. Data warehouse connections.
  3. Event data transfer for analytics and reporting.

By identifying the capabilities of the CDI vs. CDP and the use cases, it should become apparent what tool is better suited to communicate through the specified channel. Martech teams should avoid overlapping in that the same activation channel should not pass data to both platforms. In most cases where this happens, they are duplicative processes that are most likely doubling data storage, transfer, and transformation costs.

The one caveat to that is the javascript tag. Each platform and tool has its own Javascript tag that can range from having a ton of embedded features to simply being a data piping method. In the case of the Lytics CDP, for instance, the Javascript tag and SDK are responsible for data piping, personalization, and content gathering, as well as a number of client-side integrations with downstream tools. Essentially although each tool has a javascript tag, they should not be seen as duplicate channels but rather completely separate integrations that rely on the same technical framework.

Ongoing Maintenance:

Once the roles of each platform are established, it is crucial to maintain this information within the martech Center of Excellence (COE). As the martech stack evolves, new tools and data routes may be added. A defined framework and role definitions provide a clear process for integrating these new capabilities and data sets into the existing architecture.

Key pieces of the framework that should probably be defined are:

  1. Syncing new sources using the definition created during initial implementation.
  2. Monitoring new features and re-evaluating the architectural flow to identify how new features can address pain points.

Updated 4 months ago