Consent Management: Klaro + Tag Manager
When does it make sense to use Klaro in combination with a Tag Manager?
We like to use the open source application Klaro to implement GDPR compliant Consent Management for websites and to provide all to meet all data protection requirements. In combination with a Tag Manager such as Matomo or the Google Tag Manager, a quick and easy-to-implement solution is feasible under certain conditions. The advantages of this are:
- Simple and quick to implement
- Customers and external parties (e.g. SEA agencies) can make changes to the scripts, ads and services used independently and without developers.
Klaro as an independent consent management app
In this approach, Klaro and the specific configuration for the respective website are embedded through a (custom) Drupal module, but there are no other points of contact. Klaro and Drupal function independently and do not need to know anything else about each other.
The tag manager used acts as a complement to the consent management dialog and loads the respective services or places them in its container within the website as soon as they are accepted by the user (and only then).
The Consent Management dialog: here users can select which services should be active.
In the Consent Management dialog, the services that should be active are selected (there are also services that are essential for the function of the page - these cannot be switched on and off, but must still be listed for reasons of transparency)
In the callback function that we have defined and which is called by Klaro when a service is accepted (and always when a page is loaded), the Tag Manager is informed of all active services:
onAccept: `
var _mtm = window._mtm = window._mtm || [];
// we notify the tag manager about all services
// that were accepted. You can define a custom event
// in MTM to load the service if consent was given.
for(let k of Object.keys(opts.consents)){
if (opts.consents[k]){
let eventName = 'klaro-'+k+'-accepted'
_mtm.push({'event': eventName});
console.debug('accepted: ' + k)
}
}
`The following is defined in the Tag Manager:
- so-called triggers that are triggered by the transmission of Klaro and that become active when an individual service is accepted
- the tags (additional HTML or JavaScript code) that integrate an additional service after the user has accepted it
This is what a simple configuration in the Tag Manager would look like - the tags that are (only) inserted into the website after a service has been accepted are defined here:
The overall process is therefore as follows:
- A user comes to the website and is presented with the Consent Management dialog (if they have not already saved it)
- The user agrees, for example, that Google Analytics may be used to include their page visits in the statistics
- The Klaro app sends a message to the Matomo Tag Manager: "Google Analytics is now accepted" - the trigger with the name
klaro-google-analytics-acceptedis triggered - The Matomo Tag Manager places the corresponding script for Google Analytics on the website in a so-called. container and the service then becomes active
- Whenever the user calls up the Consent Management dialog again and changes their preferences, this is immediately reflected: for example, if someone switches off their consent to Google Analytics, the service is immediately removed from the container and is no longer active on the website. All cookies that were previously set by Google Analytics are also deleted.
Conclusion
The approach described here uses a comparatively loose combination of Drupal, Klaro and a tag manager to ensure GDPR compliant consent management. This setup is simple and quick to implement and is suitable if only external services are managed anyway, which only need to inject Javascript or embed codes into the page for them to work (e.g. Google Analytics, YouTube, Instagram, LinkedIn ...).
In more complex cases, where Drupal modules need to be managed in Consent Management (see e.g. discussion at Drupal Starshot) or the dependency on an external tag manager is out of the question (e.g. in the scenario that Drupal must already work out of the box without further configuration), this "simple" approach is of course no longer suitable. In this case, a little more effort is required. We will deal with this in a separate blog article.