Does a booking page need a cookie banner?
Published on
The cookie banner is the most thoughtlessly copied element on the European web. It appears on sites that have nothing to ask, and is missing exactly where things go wrong. For a booking page the question is concrete enough to answer properly, and the answer surprises most business owners: you probably do not need one.
The law is not about cookies
That sounds like wordplay and it is not. It is the entire reason so many banners sit in the wrong place.
The rule comes from Article 5(3) of the ePrivacy Directive, implemented separately by each member state. It does not say you need consent for cookies. It says you need consent for the storing of information, or the gaining of access to information already stored, in a user’s terminal equipment. Cookies are one technique for that, and merely the oldest.
The EDPB spelled this out again in October 2024, in guidelines on the technical scope of that provision. Three points are worth carrying with you. Information covers both personal and non-personal data. Storing or reading is enough on its own, you do not have to do both. And the technique is irrelevant: localStorage, a tracking pixel, a script that reads the canvas, or identifiers passed in the URL are all in scope.
So anyone basing their banner on “do I use cookies?” is answering the wrong question. The right one is: does my page put anything on the visitor’s device, or read anything from it, and if so, what for?
The exemptions
Article 5(3) provides two exemptions, and every member state has them. Some countries added a third.
- Sole purpose of carrying out a transmission. Technical storage needed to make the communication happen at all. Narrower than it sounds, and rarely the one you end up relying on.
- Strictly necessary for a service the user explicitly requested. This is the one that matters. A basket that remembers what is in it. A session that keeps you logged in. A token that stops a form being submitted twice. Note the word strictly: it means what would break the service, not what would make it nicer.
- Low-impact analytics, in some countries. The Netherlands added this in 2015. Germany did not: section 25(2) of the TDDDG lists only the first two. This is the single biggest divergence to watch if you operate across borders.
If what you do falls under an exemption, you do not need consent. You usually still have to inform people: that is a separate obligation and it does not disappear with the banner.
What that means for a booking page
Take a bare booking page. Someone opens your link, sees which times are free, picks one, enters a name and an email address, and gets a confirmation. What in that chain genuinely requires storage on that visitor’s device?
Almost nothing. The free slots come from the server. The booking goes to the server. Whatever is needed locally, a token against double submission for example, is strictly necessary for precisely the service the visitor requested. Second exemption, no banner.
What flips the answer is nearly always something you added yourself:
- a Meta or LinkedIn pixel for conversion tracking;
- Google Analytics in its default configuration;
- an embedded Google Map or YouTube video;
- a chat widget;
- fonts fetched from an external CDN on load;
- an A/B testing tool.
Each of these stores or reads information for a purpose the visitor did not ask for. That needs consent, and it needs it before anything happens.
The analytics exemption is narrower than you hope
Where a national analytics exemption exists, regulators read it tightly. The Dutch authority’s position is that you may use such cookies to count visitors, and that the data must not be used to treat people differently. The moment the same data lets you recognise someone, follow them, or serve them a different page, the exemption is gone.
A default Google Analytics install fails that test. It does more than count, and the data goes to a party that does its own things with it. There are analytics tools that can be configured within the exemption, but then “no banner needed” is a conclusion you reach after reading the settings, not an assumption you start with.
And even where the exemption applies, informing people remains mandatory. An ordinary privacy statement does that. It does not require a pop-up.
Why an unnecessary banner costs you something
“I will just put one up to be safe” looks free. It is not, for three reasons.
It costs you bookings. A booking page has one job, and every click that is not about a time works against it. You are adding friction and getting nothing back.
It can put you in breach rather than out of it. This is the counter-intuitive one. Regulators actively enforce against banners that do not work properly: pre-ticked boxes, refusing made harder than accepting, or scripts that already ran before anyone clicked. A banner that asks for consent and then ignores the answer is demonstrably misleading. No banner, with nothing to ask, is not.
It weakens your story. When a client asks what happens to their data, “we put nothing on your device” is a stronger answer than pointing at a pop-up they dismissed.
Where Calio stands
The fair question to ask of an article on a vendor’s own site: so what do you do?
Calio’s public booking page sets no cookies. Not one. There is no session, no visitor id, and nothing is read from the browser to recognise anyone. You do not have to take our word for it: it is visible in the response headers of every page.
We do count how often a booking page was viewed, because that is what lets us show you how many viewers actually book. That is a counter per event type per day, in our own database. No IP address, no user agent, no cookie, no session. Nothing is stored that could link two visits together, and therefore nothing that could be used to treat anyone differently. That sits well inside the analytics exemption, and frankly it is simpler than the exemption allows.
Where it does become your responsibility: the widget on your own website. It sets nothing itself, but the page around it is yours. If there is an advertising pixel on it, the question is about that pixel.
Everything else about our processing, including subprocessors by name and country, is in the privacy policy and the data processing agreement.
In short
- The consent rule hangs on storing or reading on the device, not on the word cookie. Pixels, localStorage and fingerprinting all count.
- What is strictly necessary for the service the visitor requested needs no consent. A bare booking page usually never gets that far.
- National analytics exemptions differ. The Netherlands has one and reads it narrowly; Germany has none. Informing people stays mandatory either way.
- A banner you do not need costs bookings and can put you in breach rather than out of it. Check what your page loads first, then decide.
Frequently asked questions
Do I need a cookie banner if all I have is a booking page?
Probably not. The consent rule applies to storing or reading information on the visitor’s device. A booking page that shows free slots and records a booking does not need to do that beyond what is strictly necessary for the service the visitor asked for, and there is an exemption for exactly that. The moment you add a pixel, an embedded video, a chat widget or an analytics package, the answer changes.
Are functional cookies exempt from consent?
Yes, provided they are genuinely functional. Article 5(3) of the ePrivacy Directive exempts storage whose sole purpose is carrying out a transmission, and storage strictly necessary to provide a service the user explicitly requested. A session token that makes your booking form work qualifies. A cookie that is merely “useful later” does not.
Can I run Google Analytics without consent?
In practice, no. Some member states, the Netherlands among them, have a narrow exemption for analytics with minimal privacy impact, but it only covers counting visitors without using the data to treat people differently. Germany has no such exemption at all under section 25 of the TDDDG. A default Google Analytics install does more than count, so consent is required in either case.
Does this apply to the widget I embed on my own site?
Nothing changes for the widget itself: it sets no cookies. But your own site is your responsibility. If there is an advertising pixel on the page the widget sits in, the question is about that pixel, not about booking. The assessment always covers the whole page, not one component of it.
Sources
- Directive 2002/58/EC (ePrivacy), Article 5(3) — EUR-Lex
- EDPB, Guidelines 2/2023 on the technical scope of Article 5(3) ePrivacy, version 2.0, October 2024 (pdf)
- Dutch Telecommunications Act, Article 11.7a — wetten.overheid.nl
- Section 25 TDDDG (Germany) — gesetze-im-internet.de
- Dutch Data Protection Authority on cookies
This article explains regulation in plain language and is not legal advice. For your own situation, consult a lawyer.