On Tuesday 1st October we presented the latest Customer Data Cloud Webinar with the focus on how to engage with your registered and consented customer base. The presenters of the session were:
In this webinar, we outlined the importance of engaging with your customers in a transparent way, before building a working demonstration to show how easy it is to implement a consent focused registration flow. You can find a link to the recording here.
This blog post focuses on the steps required to add consent to the existing Webinar demo site which featured in previous Webinars in August and September. The demo site is based on a fake travel company who through their registration process need to capture consent to cover the following use cases:
The end goal to satisfy these requirements is to create a registration form like the following example:
The first step in any consent implementation is to create the consent definition within the SAP Customer Data Cloud console. Consent is separated into three categories; terms of service, privacy policies and other consent statements. In our example, we created a mandatory terms of service for website registration and then two other consent statements representing consent for marketing and consent for data sharing.
When creating consent statements you can define localized templates in order to display the correctly translated purpose text (the label next to the checkbox) and document URL to the correct users.
Additional data can be associated to the consent record by creating key/value pairs in the custom data tab. In our example, we used the custom data to define a retention period value which represents a period for which we can use the collected consent. Custom data allows you to add any static data to consent records but is not suitable for dynamic data. To associate dynamic data to the consent record, tags would be the correct approach.
In our travel demo, we want the user to see a newsletter checkbox if they've agreed to be contacted for marketing purposes. This creates a form of parent/child relationship which gives end users more granularity in their consent choices. For this purpose, we also need to create a subscription field.
A subscription differs from a consent because it is not versioned and is created from within the schema menu:
Once we've created all of the consent fields we need to map them to a Screenset, so they can be presented to our end users. In the registration form, drag checkboxes that represent the different consent fields and map them to the isConsentGranted subfield of the relevant consent schema field via the mapped field dropdown. For consent checkboxes, use a placeholder value for the label:
This placeholder allows the Screenset to dynamically display the purpose text from the consent configuration based on the language that the Screenset is displayed in. You can see what it will look like on the live site through the preview function, which also allows you to switch locales.
Next we can add our newsletter subscription field by mapping another checkbox to the subscription schema field. We don't set the label text for subscriptions in the same way as consent, but it is possible to translate the values via the localization menu. To make the newsletter checkbox only visible if a user has checked the marketing checkbox, add the following to the visible when field:
For the data sharing consent, we wanted to enable another level of permissions that associate to the consent. The user should be able to choose which partner excursion companies they are happy to share their data with. This extra level of granularity provides the user with a better visibility of what is happening with their data.
To achieve this extra level of permissions, we use entitlements, which are a special subfield of the consent. To add an entitlement, map a checkbox to the entitlements subfield of the consent schema field. This will activate a new entitlement textbox in the checkbox properties, where you can provide an entitlement value:
In our example, we mapped two checkboxes to two fake excursion companies called Outdoor Adventures and My Excursions.
When configuring Screensets it is very important that we ensure that, at a minimum, mandatory consents are also added to the registration completion screen, as this screen will be triggered as part of a number of different user flows, including social registration and re-consent.
As part of our travel demo, we also mapped all optional consent fields to the profile update screen, using the same methods as described above. This allows the end user to manage their consent and preferences in an easy way:
Once a registration has been successfully completed, consent records can be viewed in a number of different ways:
The privacy tab gives you a snapshot of the consent as it currently stands. You can see the version which was accepted and when it was accepted. An customer service representative could even revoke the consent from this menu:
The consent history tab shows you a timeline of all user consent interactions, including grants, withdrawals and renewals:
You can further drill into any consent interaction to see additional details such as action timestamp, IP address, and what purpose text the user saw:
Consent data which is shown in Identity Access is specific to a user, but you can view data across all users through the consent vault. The consent vault shows the exact same data as the consent history tab with the addition of right to be forgotten events. This allows you to view the full lifecycle of a user's consent interactions, even if they've deleted their account, at which point they would no longer exist in Identity Access. Data is kept in the consent vault for 7 years, but could be extracted through a number of different mechanisms if you wished to keep it for longer.
SAP Customer Data Cloud supports both major and minor re-consent flows. Assuming the Screensets have been configured as described in this blog, re-consent is completely triggered through changes to the configuration.
A minor consent update might be required if there have been minor changes to the legal document behind the consent, such as a spelling mistake. To trigger a minor consent update, increment the effective as of value, but leave the re-consent cut-off value the same:
This configuration will ensure that any new registrants will have version 2.1 recorded in the consent record. Any existing users will have the previous version that they consented to recorded in their record. Existing users will not be required to perform any further action.
A major consent update might be required if there have been many changes to the legal document behind the consent. To trigger a major consent update, increment both the effective as of value and the re-consent cut-off value to match:
This will have the additional effect of forcing all existing users to provide re-consent at the point in which they next login, by re-checking the checkbox on the registration completion screen. This re-consent will be recorded in the user's consent record.
This ends our blog post which discusses how we can use the SAP Customer Data Cloud platform to easily setup registration flows to capture consent that is necessary to your organisation. We've seen that with almost no code, we can create flows that cover site registration, social registration, profile update and re-consent.
To learn more on this topic, please sign up for our next webinar on the 14th of November.
- Ratul Shah - Senior Product Marketing Managers, SAP Customer Data Cloud
- Alex James - Global Practice Lead, SAP Customer Data Cloud
- Ed Knight - Technical Architect, SAP Customer Data Cloud
In this webinar, we outlined the importance of engaging with your customers in a transparent way, before building a working demonstration to show how easy it is to implement a consent focused registration flow. You can find a link to the recording here.
This blog post focuses on the steps required to add consent to the existing Webinar demo site which featured in previous Webinars in August and September. The demo site is based on a fake travel company who through their registration process need to capture consent to cover the following use cases:
- Website terms of service
- Sending marketing material including a holiday offers newsletter
- Sharing data with specific partner excursion companies
The end goal to satisfy these requirements is to create a registration form like the following example:
Consent Configuration
The first step in any consent implementation is to create the consent definition within the SAP Customer Data Cloud console. Consent is separated into three categories; terms of service, privacy policies and other consent statements. In our example, we created a mandatory terms of service for website registration and then two other consent statements representing consent for marketing and consent for data sharing.
When creating consent statements you can define localized templates in order to display the correctly translated purpose text (the label next to the checkbox) and document URL to the correct users.
Additional data can be associated to the consent record by creating key/value pairs in the custom data tab. In our example, we used the custom data to define a retention period value which represents a period for which we can use the collected consent. Custom data allows you to add any static data to consent records but is not suitable for dynamic data. To associate dynamic data to the consent record, tags would be the correct approach.
In our travel demo, we want the user to see a newsletter checkbox if they've agreed to be contacted for marketing purposes. This creates a form of parent/child relationship which gives end users more granularity in their consent choices. For this purpose, we also need to create a subscription field.
A subscription differs from a consent because it is not versioned and is created from within the schema menu:
Screenset Configuration
Once we've created all of the consent fields we need to map them to a Screenset, so they can be presented to our end users. In the registration form, drag checkboxes that represent the different consent fields and map them to the isConsentGranted subfield of the relevant consent schema field via the mapped field dropdown. For consent checkboxes, use a placeholder value for the label:
This placeholder allows the Screenset to dynamically display the purpose text from the consent configuration based on the language that the Screenset is displayed in. You can see what it will look like on the live site through the preview function, which also allows you to switch locales.
Next we can add our newsletter subscription field by mapping another checkbox to the subscription schema field. We don't set the label text for subscriptions in the same way as consent, but it is possible to translate the values via the localization menu. To make the newsletter checkbox only visible if a user has checked the marketing checkbox, add the following to the visible when field:
For the data sharing consent, we wanted to enable another level of permissions that associate to the consent. The user should be able to choose which partner excursion companies they are happy to share their data with. This extra level of granularity provides the user with a better visibility of what is happening with their data.
To achieve this extra level of permissions, we use entitlements, which are a special subfield of the consent. To add an entitlement, map a checkbox to the entitlements subfield of the consent schema field. This will activate a new entitlement textbox in the checkbox properties, where you can provide an entitlement value:
In our example, we mapped two checkboxes to two fake excursion companies called Outdoor Adventures and My Excursions.
When configuring Screensets it is very important that we ensure that, at a minimum, mandatory consents are also added to the registration completion screen, as this screen will be triggered as part of a number of different user flows, including social registration and re-consent.
As part of our travel demo, we also mapped all optional consent fields to the profile update screen, using the same methods as described above. This allows the end user to manage their consent and preferences in an easy way:
Viewing consent records
Once a registration has been successfully completed, consent records can be viewed in a number of different ways:
- Privacy tab
- Consent history
- Consent vault
The privacy tab gives you a snapshot of the consent as it currently stands. You can see the version which was accepted and when it was accepted. An customer service representative could even revoke the consent from this menu:
The consent history tab shows you a timeline of all user consent interactions, including grants, withdrawals and renewals:
You can further drill into any consent interaction to see additional details such as action timestamp, IP address, and what purpose text the user saw:
Consent data which is shown in Identity Access is specific to a user, but you can view data across all users through the consent vault. The consent vault shows the exact same data as the consent history tab with the addition of right to be forgotten events. This allows you to view the full lifecycle of a user's consent interactions, even if they've deleted their account, at which point they would no longer exist in Identity Access. Data is kept in the consent vault for 7 years, but could be extracted through a number of different mechanisms if you wished to keep it for longer.
Re-consent
SAP Customer Data Cloud supports both major and minor re-consent flows. Assuming the Screensets have been configured as described in this blog, re-consent is completely triggered through changes to the configuration.
A minor consent update might be required if there have been minor changes to the legal document behind the consent, such as a spelling mistake. To trigger a minor consent update, increment the effective as of value, but leave the re-consent cut-off value the same:
This configuration will ensure that any new registrants will have version 2.1 recorded in the consent record. Any existing users will have the previous version that they consented to recorded in their record. Existing users will not be required to perform any further action.
A major consent update might be required if there have been many changes to the legal document behind the consent. To trigger a major consent update, increment both the effective as of value and the re-consent cut-off value to match:
This will have the additional effect of forcing all existing users to provide re-consent at the point in which they next login, by re-checking the checkbox on the registration completion screen. This re-consent will be recorded in the user's consent record.
Conclusion
This ends our blog post which discusses how we can use the SAP Customer Data Cloud platform to easily setup registration flows to capture consent that is necessary to your organisation. We've seen that with almost no code, we can create flows that cover site registration, social registration, profile update and re-consent.
To learn more on this topic, please sign up for our next webinar on the 14th of November.
- SAP Managed Tags:
| User | Count |
|---|---|
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
