How exactly does a customer data platform work, and help marketers leverage data to gain a better, more accurate understanding of customer behaviour?
Ingesting and integrating data
The first element in understanding this is ingesting data. CDP’s ingest customer data from multiple sources. Typically, these will include website data, paid digital, transactional, direct mail, retail, email, and call centre. All data received by a CDP will relate in some shape or form to a customer. The data is usually sent to a CDP using an API or via an SFTP site.
Customers have multiple identifiers and these change over time, such as mobile phone number, email address, cookie ID, postal address, customer reference or landline number. This data is collected, and these identifiers are used to generate a single customer view also known as ‘Identify Resolution’. For example: if someone logs into your website with their current email, but with a different cookie ID, then the new cookie ID is added to that particular customer record on the assumption that they are using a new device. Equally, if a new transaction record is received with the same customer reference, but a new address, then a new address is added on the basis they have either moved or added an extra residence.
As new data is ingested, each record goes through what is called the ‘purning’ process. This is the stage at which the record’s personal identifier(s) are matched against all other customer records that are held in the CDP until a match is or is not found. At this point the data may be matched into an existing single customer view or a new one created. Each recognised customer is given a permanent unique record number or ‘purn’.
Identity resolution
Is at the heart of a CDP and is central to all the rest of its functionality. A good CDPs’ functionality is rooted in the knowledge that people have multiple identifiers, and that these identifiers can all change. Over time many or all of these identifiers are likely to change for an individual. The CDP should keep a history for every one of every version of these, although regarding the latest versions as most likely to be current. This collection of identifiers is what it calls on to build the single customer view.
The data in a CDP is held in what is called a schema. This is the way in which the data is organised. Every organisation using a CDP will need their own schema although within an industry, schemas will have a lot of similarities.
Engineering derived data
Engineered data is important for the value it provides for selecting specific customer groups for communications or developing customer insight. It can comprise any variable that can be calculated using an algorithm or other means from the raw data in the customer data platform.
Data engineering can take many forms, from simple examples like banding variables such as age, to more complex ones like keeping a counter on customer’s total historic value. A major use of engineered data is in developing and recording scores derived from algorithms such as propensity models.
An example of an engineered data field is where we want to know what each customer has contributed to a business after the cost of acquiring them. We can then:
- Use historic purchase data for each individual in say their first and second year since recruitment
- Deduct the cost of acquisition which can be derived the channel they came in from
- Deduct the cost of communications sent to them in the same period which is held in the contact history area
- Calculate an individual customer contribution
Engineered data is updated at an individual level every time a relevant event happens; so, each new home shopping purchase, eCommerce transaction or physical retail transaction can lead to a changed score in the engineered data section. A great benefit of engineered data is that it allows you to base axis for charts or selections for campaigns on these additional variables.
Analysing customer data
A CDP is essential for gaining a full and accurate understanding of customer behaviour. For instance, without a CDP that combines web browsing history with transactions, it would not be possible to understand the relationship between the two. Again, if individual contact history is not held against a customer record then the effectiveness of campaigns that are sent to the customer, and to which the customer may respond through different channels, cannot be accurately measured.
The CDP builds the single customer view, and it is against this that customer analysis can take place. It provides the dataset that becomes the one authoritative source of information about customer behaviour for an organisation. With this in place decision makers have a firm basis on which to proceed.
There are so many aspects to the analytical tools that can be used to analyse customer data that there is little merit in trying to list them all. Some are built into the CDP and others require data to be first extracted from the CDP and then transferred to them. What matters is that they have the best possible customer data set to analyse.
So, the results from customer analysis form the basis on which key decisions about customer marketing can be made. These include such areas as:
- Customer acquisition (targeting and channel choice)
- Digital planning
- Product development
- Customer relationship management
- Salesforce management
- Pricing
Even corporate mergers and company valuations.
Given how important these decisions are, it makes good sense when designing a CDP to first start with a list of the kind of results that will be required from customer analysis so that for instance data is held with sufficient granularity to make these possible.
Connectivity to external systems
The CDP can support other systems in their personalisation and management of customer communications. Typical examples are:
- Providing customer selections for email marketing systems
- Customer segmentations for web personalisation technology
- Names and addresses for postal marketing
- Target audiences for social media
So just as the CDP ingests data from multiple sources it also provides selected data to external systems. These connections are usually made via an API or via transfer of data to an SFTP site.
Delivering personalised customer experiences
Within the CDP we expect to find functionality for the selection of specific customer groups either on a one-off or on a recurring basis. These groups are usually selected for output to external systems that manage the actual communications. The selections themselves can be simple based on Boolean logic rules, or they may be more complex based on propensity scores applied within the engineered data. They can also be based on triggers, such as a new customer having just been recruited.
The CDP needs to enable these different types of selection, and crucially record what contacts each individual customer has been selected for. Functionality is also required for test and control, and for including source codes with the selection.
Associated with delivering personalised customer experiences needs to be functionality for measuring the results of campaigns. This is often automated within the design of the CDP and should always include the ability to attribute results such as orders back to campaigns, even if they respond through different channels.
What are the costs for a customer data platform?
UniFida is the trading name of Marketing Planning Services Ltd, a London based technology and data science company set up in 2014. Our overall aim is to help organisations build more customer value at less marketing cost.
Our technology focus has been to develop UniFida. Our data science business comes both from existing users of UniFida, and from clients looking to us to solve their more complex data related marketing questions.
Marketing is changing at an explosive speed, and our ambition is to help our clients stay empowered and ahead in this challenging environment.
