Cookie opt-in example.

The challenge.

Before an external component such as user tracking, a live chat or an external contact form from a third-party provider may be activated and used, the user has to give consent. Why? Because when contact is made with the third party’s servers, personal data is already transmitted, even though no actual use has taken place yet. In the simplest case that is the IP address sent to the third party’s server.

A possible solution.

Before calls are sent to third-party servers, consent has to be given — and by the visitor or user themselves. That consent must also be revocable at any time. Which means: the status quo has to be stored. A good way to do that is to store the opt-ins given in a database and tie them to a unique ID. Since an ID is generated anyway when someone visits a website (the PHP session ID, for example), this example uses exactly that.

Before use, the visitor is first asked for consent to the storage and processing of personal data. Before that, an opt-out solution had established itself, generally referred to as “cookie consent”: it was enough to point out the use of cookies and the opt-out functions — often hidden away on the privacy page. The consequence: an opt-in is now necessary. Without an opt-in, personal data may not be collected and stored.

Required and optional — two segments.

A distinction has to be drawn between mechanisms that are necessary to run an application and functions that deliberately collect personal data in order to evaluate it afterwards, for instance. In the input mask shown, those two segments are simply separated into “required” and “optional”. The required functions are mandatory, because otherwise the application cannot be used — the settings made here are themselves stored as “necessary” cookies, for example.

Optional functions serve to improve usability or to target an application more precisely. For that, behavioural data such as usage patterns and usage intensity is of interest. No advertising content is played out in the process, and no personal content such as name or date of birth either. Personalised content is possible if the data required for it is pseudonymised or anonymised — through IDs that allow no conclusions about the person concerned at a processing point.

Processing that data requires the user’s consent. In this example it is about collecting data to improve the content of the application. The data is also collected anonymously — IP addresses are obscured, for instance (192.168.0.100 becomes 192.168.XXX.XXX).

Only after the user has ticked the box and clicked on “use current settings” are the respective JavaScript calls loaded and the connections to third parties established. So-called on-premise solutions can simplify implementation under the GDPR: the tracking tool Matomo, for example, can also be installed and operated on your own servers.

Everything in the operator’s hands.

The input mask shown is loaded through its own JavaScript and CSS call. The program can be stored and operated entirely on your own servers — a third-party provider for the opt-in dialogue is not needed. The opt-ins land in a database via a JavaScript call, and that database runs on your own servers as well. As a result, all collected data stays in the operator’s hands — and responsibility for that data always lies with the operator.

It is important to understand: ideally an opt-in has to exist for all third-party functions. Embedded videos, contact forms or other content from external providers may also transmit personal data. That may only happen with the user’s consent. If there is no opt-in, the content in question should not be loaded.