Data Governance and Compliance

peter_gergen · ‎11-23-2021

How does CDP play a role in it?

By Peter Gergen, Solution Architect CX

Consent is an important building block in the processing of customer data. Indeed, it is not enough to simply collect and analyze customer data from the various data silos, consent must also be provided by each customer, in order for the data to be collected, stored, analyzed and assessed. There is no fast-track for a company being penalized for a breach of the regional data protection regulation like insufficient procedures for the logging of customer consent when, for example, their data is processed for marketing purposes without their permission. European GDPR (General Data Privacy Regulation) is the most restrictive data protection legislation, with serious penalties incurred when companies violate its terms. Many data protection policies implemented around the world are based on this European Directive. It is therefore a good idea to look at the exact procedures used for processing customer data, and to then check whether the customer's consent has been obtained for each step of the procedure.

Customer information

Well, we have seen that customer information is found in many data silos: CRM, DMP, ERP systems, commerce platforms, order management systems, ERPs, feedback services, service and support landscapes, and last but not least, marketing systems. Here, I would like to start by highlighting that this information about customers comes in two facets: "customer data" and "master data". I make this distinction quite deliberately because these are two processing operations to which the customer, but also the company, have only limited rights.

First of all, let's talk about "customer data": This is data that belongs to the customer. This data is what he provides to us so that we can customize his "Customer Experience" for his needs. This includes data such as name, nickname, email address, preferences, interests, activities, social media contacts, browser data, and so on. The customer provides this information to the company either actively by entering it when registering on the website, or passively such as through browsing behavior. The customer has the right to view, modify, delete and download this data himself. These are the data whose management is granted to him by the data protection regulations in force. The most important entity for the management of this data is the SAP Customer Data Cloud (or any other CIAM solution), which allows him to manage his data, his preferences for communication with him and the Company, and his consents for the processing of his data. Last but not least, he must be able to export -, and request the company to delete his data.

Customer master data, in turn, is the data that is indispensable for the contract execution of purchased products or services. This includes billing data, delivery data, warranty agreements and so on. This data includes customer information, but it is beyond the reach of the customer itself, which means it under control of the company. This does not mean that the company is now allowed to process this data for marketing or any other purposes, it is solely bound to the purpose of implementing the customer's contractually agreed services. Master data is required to comply with all contract-related dependencies such as warranties, guarantees or service deadlines with the customer. However, the data protection regulations also apply here: the customer has the right to have his information carefully stored and managed, to have it backed up after a defined retention period, and finally to have it deleted. The essential entity for the management of this data is the Master Data Governance System (MDG), which is responsible for the management, synchronization and data quality of this data. Another system that is responsible for managing the storage, backup and, above all, deletion of this data is the so-called Information Lifecycle Management (ILM).

So we've seen that customer information is a Janus face, "customer data" and "master data," and that they both have different purposes, they serve different processes, and they have different owners.

Ok, so far, so good. And now the Customer Data Platform comes into play. Why? As described in other blogs, it contributes the information necessary for the perfect customer experience to the "Next Best Action". I won't rehash the relevance of this system, however, just say this: it operates on "Customer Data”, the first bullet point in the list above (and the blue boxes in the grapic). Thus, all the conditions for this part of customer information take effect, first and foremost the customer's consents that and how this data is processed in the CDP.

CDP and Consent: How do they go together?

So, we’ve established that a CDP is a data processing platform that integrates all data silos containing “Customer Data”. The goal here is to ensure that this data is brought together in a unified customer profile, and used to create the best possible customer experience. However, this also means that (with the customer's consent) this data is sourced from the “Customer Data” in the same way as from the “Master Data”. In particular, given the context of seeking to ensure the best customer approach possible, it is important that “Master Data” is combined with the “Customer Data”. If this profile information is now made available to operating channels, such as marketing or customer service, and it is imperative that the purpose of the data processing is adhered to in compliance with the customer's consent. Sounds complicated? Let me give you an example:

A customer who has an issue with a product calls the service department. At this point, her phone number is recorded for customer service call processing. This information can be passed on by the customer services department to the CDP to further populate the customer profile. If the customer does not consent to this telephone number, or even a recording of the entire service call, being passed on to the marketing department within the company, then the CDP cannot make this data available for marketing, even if the same customer has registered for the newsletter with their email address and name. Accordingly, the CDP must adhere to purpose-specific data governance that prevents customer data from being used without restriction within the company.

SAP CDP can do this. If the customer's consents are transferred to the CDP from outside, it can evaluate this information and determine exactly which data is transferred to which channels. It doesn't even have to be direct consents themselves - it can be standard events that are assigned a purpose in CDP's processes. For example, a recording of an order that is entered into the CDP as an event by a customer via a Commerce Cloud application is marked with the purpose "Transactional". A purpose like this means that all channels involved in fulfilling the contractually-defined order processing can obtain this data via the CDP without the need for explicit consent from the customer. At the same time, however, marketing is excluded from this data, at least until the customer gives consent for this. And even then, the company can decide how much of the collected data is actually necessary for marketing and whether a subset of this data is sufficient to inform the customer in a marketing-oriented manner.

To operate a CDP, these aspects of data governance must be highlighted. Data protection regulations are taking an increasingly critical stance in regard to companies' compliance with their policies. Even though these regulations are sometimes provided in high detail and are multi-faceted, they have in common the two aspects of “data economy” and “purpose limitation” through customer data collection. By consistently implementing these two notions within the Customer Data Cloud and the Customer Data Platform, SAP has created a unique opportunity for companies to process their customers' data in compliance with data protection and, not least, in accordance with the requirements stated by the customers themselves.

Purpose and Consent Processing in the CDP

In order to understand how a customer's consent is implemented, from recording to processing within the CDP, I would like to break down this process into its various individual parts.

First of all, how is consent recorded? Well, customers give their consent through the various touchpoints, which in turn pass this data on to the Customer Data Cloud. This should, but not by obligation, be the only input vector for consent. Our protocol requires that every consent is stored by the company centrally in the Customer Data Cloud (and therein the Consent Vault) in order to have a central place where customer consents are registered, processed and managed. So, let's just assume that the consents come from the CDC, although there may be other input channels that can transfer customer consents into the CDP – in technological terms, there is little difference here.

The collection of customer data at the various touchpoints are so-called events that are transferred to the Customer Data Platform. This means that, when a connection is established between the Customer Data Cloud and the Customer Data Platform, the corresponding connector is used and the associated events are then configured in the CDP. Let's take a closer look at such an event in the CDP:

If the connector to the CDC is activated, an event - for this example we’ll use one called "Get new Accounts from Gigya CIAM" - is configured in the sources. Here, a detail of the Customer Data Platform comes to light, which is not directly visible in the schema definition: in the CDP schema, an area named "Privacy" is preserved, which is not displayed in the configurative area of the schema definition in the CDP UI. However, here, when mapping the event "Get new Accounts from Gigya CIAM", "subscription", and "preferences" from the CIAM can be mapped into this privacy segment of the customer profile.

Now, we assume that a user visits a website, registers, and that CDC is the major CIAM user store. Their data, as well as the consents, are recorded there. We have already described in previous blog posts how the CDC manages this consent in the Consent Vault: the data is stored in line with audit-proof methods and is available for audits. So, let's look at the data as it is stored in the CDC. For each customer, what is known as an "Identity Record" is created in the CDC database. You can look at this data via an API call. This is most easily done, for example, via a tool like Postman, which launches an API call against the Customer Data Cloud and then displays the result. I don't want to get bogged down in the details of the CDC APIs and how they are operated by Postman now, but let’s just look at the result of an "accounts.getAccountInfo" query here. For this example, I selected a customer's consent for a website's terms and conditions, which is a mandatory consent for website registration. We will likely also find a marketing consent, which will or will not be confirmed by the customer. In short, the profile of a customer, especially the Consent section of this profile, looks like this in the CDC:

Within the CDC, the information is available, for each profile, on how the customer decided on the individual points of the consents. So, that’s sorted. Now, this information just needs to get into the CDP, but how exactly?

We saw above how, via the CDP UI, the incoming event information was mapped to the "privacy" areas of the user profile. If the customer now registers via the CDC, their data will appear in the profile in the CDP. Let's assume that they have registered on the website, the CDC has provided the necessary screensets, and has taken over the customer data during registration. The event for this was transferred to the CDP, and the corresponding customer data was forwarded to the CDP.

I have outlined this in the following image:

This acts as a bridge, connecting the initial recording of the customer's consent via the CDC and the transfer of the consent to the privacy sector of the customer profile in the CDP. So, how is this information evaluated? This is where the "Processing Purpose" functionality comes into play.

A “Processing Purpose” is a predefined and configurable data governance path in CDP, that specifies exactly how data that enters the CDP as a result of a specific event or via a specific consent is processed. It is defined from the "externalID" (see graphic above) and allows for the application of precise filters to the data to be processed via "Inbound Data Governance" or "Outbound Data Governance".

The difference between the two types of governance lies in where the incoming data is processed. With inbound governance, the data is only accepted in CDP when the corresponding consent for recording has been received from the customer. If this consent is missing, the data is not accepted in the CDP, point blank. In the case of "Outbound Govenance", only the data that is flagged in an outbound channel, such as for marketing, is processed on the profile data (i.e. name, email, newsletter-subscription, etc.).

At this point, the path from the capture of consent by the customer to data processing to one of the connected target systems’ ends. We could elaborate much further, but this summary should suffice for an initial overview.

Summary

A CDP should represent a comprehensive digital image of a customer. For this to be achieved, and for the CDP to be able to collect and process the data and pass it on to the target systems with high accuracy, the customer must give their consent. In this blog, we have covered this path: from the collection at one of the touchpoints completed by the customer to the data processing in the CDP. Every company handling customer data is required to comply with this data governance.