CDP Implementation: Basic Configuration

CDP implementation: stages of implementation

The valantic blog series on CDP implementation provides you with in-depth insights into the structured approach to project implementation: from planning to the individual phases of the implementation process to the downstream further development of the CDP. After initial preparations, the formation of the team, the distribution of roles and the specification, stage two now focuses on the basic configuration.

Basic configuration of the CDP: finding the right setup

Now that both the functional and technical specifications have been established, the actual implementation of the CDP can begin.

In the first step, a so-called tenant is created in the CDP. This is a client account in which users can manage their licenses or applications. It is important to note here that it is advisable to distinguish between development and production environments – especially with regard to the data repository that will be created. In the preferred setup, both systems are separate and independent from each other. This has the advantage that changes in the development environment do not affect the live system in the production environment. In addition, extensive tests can be carried out to check the functionality of the implementation.

Define customer schema and connect the source system

The use cases defined in the specification phase are now implemented within the CDP, and the customer schema is finally defined. In the process, it has to be determined which data records from the different systems – such as customer numbers or cookies – are combined to form a comprehensive customer profile. Here, too, however, some details need to be considered:

Since the respective hard and soft IDs can neither be renamed nor deleted later, special care is required. The ID concept should be well thought through in order to always assign all information to the right users. This is especially true if not all source systems share the same ID and several hard IDs are used.

Soft ID: The so-called soft ID is, for example, information collected with cookies. Here, each customer can have several IDs if identification takes place via different browsers or devices, for example.

Hard ID: A hard ID is usually the email address that customers use when registering.

Based on the defined IDs, the “merge & match logic” can then be designed in the CDP, which ultimately maps the 360-degree profile of the individual customers.

Creation of consent and subscription categories

After defining the customer schema, the next step is to integrate the consent and subscription categories. These determine which data may be used for the creation of personalized content. However, since personal data may not be used for marketing purposes without consent, special care must be taken with regard to the CDP’s consent management.

Technical integration

The responsible developers carry out the technical integration of the different source systems. This should begin promptly, which is why the respective endpoints and access data must be provided. During this step, it is important to ensure that the rights assigned within the CDP are precisely defined and that login data cannot be misused for exports or incorrect changes.

In addition, there is the configuration of the various interfaces. Most CDP systems already come with a wide range of standard integrations, such as e-mail, WhatsApp or social media.

Integration of further software tools

Further software tools can be flexibly configured via webhooks. Most CDPs usually also provide very precise step-by-step instructions for their configuration process.

The following basic configurations are crucial as well:

• Frequency policies: As the name suggests, frequency policies are used to ensure that customers do not receive too many offers, emails or similar automated content within a certain period of time.
• Rights & roles: The rights and role management within the CDP ensures that all roles receive the necessary rights. It’s possible to precisely define which employee has access to personal customer data or which rights must be enabled to produce analyses and reports.
• Expiry date and deletion of data: The concept created must be DSGVO-compliant but at the same time, it should not have a negative impact on use cases or CDP reporting.

Once the basic configuration of the CDP is complete, the data repository can be created in the next stage of the project.