Can live chat be GDPR-friendly without cookies?

This post explains how the rules and the product work. It is not legal advice: your own adviser decides what your site needs.

The rule is about the device, not the cookie

The consent rule behind cookie banners is Article 5(3) of the ePrivacy Directive. The European Data Protection Board quotes it in its Guidelines 2/2023 on the technical scope of Article 5(3): "the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user" is only allowed with consent, or when it is necessary for the purposes the article lists.

So the rule is about storing anything on the visitor's device. A visitor ID in local storage is in scope just as much as a cookie. The same guidelines quote the Court of Justice of the EU: the protection applies "to any information stored in such terminal equipment, regardless of whether or not it is personal data".

One of those purposes matters for chat. Storage is allowed without consent when it is "strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service". A chat the visitor opens is a service they asked for. A visitor ID set the moment the page loads, before anyone has asked for anything, is harder to fit under that exception.

What chat widgets usually store

Many chat widgets set a visitor ID as soon as the page loads, so they can recognise a returning visitor and show an earlier chat. tawk.to's help centre, for example, says its cookies are stored as soon as the widget loads, unless its consent option is switched on. That is a fair design choice. It also means the chat is one more item your cookie banner has to cover.

Why banners matter

Banners are where consent tends to go wrong. In 2021 the privacy group noyb sent complaints about more than 500 websites. It found that 81% did not offer a "reject" option on the first page of the banner, and that companies get more than 90% of users to agree when industry figures show only 3% actually want to.

A whole industry of consultants and designers develop crazy click labyrinths to ensure imaginary consent rates. Frustrating people into clicking ‘okay’ is a clear violation of the GDPR’s principles.

Every tool that stores something on page load adds a line to that banner. A chat that stores nothing until it is used gives you one less thing to ask for and explain.

How TalkMerlin works

• Nothing stored before a chat. Until a visitor starts a chat, TalkMerlin stores nothing in their browser. Once they start one, it keeps a visitor ID in local storage. If your site runs its own consent tool, it can call TalkMerlin.consent() to allow that ID earlier.
• Visits counted with a daily hash. To show live visitors and the pages they viewed, TalkMerlin makes a hash of a secret salt, the site, the IP address and the browser's user agent. The salt changes every day and old salts are deleted, so returning visits are recognised for one day only. The IP address is not stored.
• Short retention. Visits without a chat are deleted after 30 days. Chats are kept for 30 days on Free, and for 24 months by default on Pro, which you can set anywhere from 1 to 120 months.
• EU storage. The app and database run on Hetzner servers in Germany, and files sent in chats sit in private Hetzner storage in Finland. Every service that processes personal data is on the sub-processors page.
• Export and delete. When a visitor asks for their data, you export it or delete it from the inbox.

Each site also gets a ready-made paragraph for its own privacy policy in the app's site settings. Our privacy policy lists what TalkMerlin stores and for how long. For the wider question of whether a chat is worth adding at all, see live chat on a small website.