The cookie banner costs you conversions. Here is what it may not cost you.
A legally clean consent banner loses you measurement and some traffic. Dark patterns are illegal and also do not work. What a compliant banner must actually do under DSGVO and TTDSG — and how to run a shop when a large share of visitors say no.
Photo: free stock photography (Unsplash licence) — see imprint
Everyone wants to talk about the banner. The banner is the symptom.
The conversation always starts in the same place: can we make the reject button smaller, can we make it grey, can we put it a click deeper. What is actually being asked is 'how do we get consent from people who would not give it if they understood the question', and once you say the sentence out loud it stops sounding like a design decision. The banner is only the visible edge of a real question — which is what your shop does with data, and whether you can explain it without flinching.
The legal frame in Germany has two layers and people routinely conflate them. The TTDSG governs storing or reading information on the user's device — that is the cookie itself, and it needs prior consent unless it is strictly necessary for a service the user explicitly requested. The DSGVO governs what you then do with the personal data. A banner can be flawless under one and useless under the other. Get advice from a lawyer for your specific setup; what follows is what we see technically, not legal advice.
What a banner has to do, stated plainly
Consent under the DSGVO has to be freely given, specific, informed and unambiguous, and it has to be as easy to withdraw as it was to give. Translated into a shop: nothing non-essential fires before the user has acted, there is a real reject option available at the same level as accept, pre-ticked boxes are not consent, and continuing to scroll is not consent either. The user has to be able to change their mind later without writing you an email.
The technical failure we find most often is not the design at all — it is that the tags fire anyway. A perfectly worded banner sits on a page where Tag Manager loaded Analytics on DOM ready, or where a chat widget dropped its own cookie before anybody clicked anything, or where the consent tool blocks its own list and knows nothing about the plugin someone installed in March. Open your shop in a fresh browser, decline everything, and look at what is in storage. That check takes four minutes and it fails more often than it passes.
- Nothing non-essential fires before an actual click — check it in a fresh browser.
- Reject is one click, same level, same weight as accept.
- Withdrawal is as easy as consent — a permanent, findable link.
- The cookie list matches reality, including the plugin installed last quarter.
Dark patterns are illegal and they also do not work
The grey reject button, the accept button that pulses, the three clicks to say no, the 'legitimate interest' toggles pre-set to on: these are well documented, regulators and consumer groups have been going after them, and courts have not been kind. Treating them as a growth tactic is treating a legal risk as a conversion experiment. That is a bad trade even on purely commercial terms, because the downside is not a worse quarter — it is a warning letter and a rebuild.
The commercial argument is the more interesting one though. Consent obtained by exhaustion is low-quality consent: you get a user who clicked accept to make the wall go away, who is now in your remarketing audience, who will not convert, and whose data you are now paying to store and defend. Meanwhile the banner is the first thing a new visitor sees of your shop. A tricky one tells them, before a single product, exactly what kind of company they are dealing with. That impression is not free.
When a large share decline, your analytics becomes a sample
This is the part that costs real money and nobody prepares for it. Say a substantial minority of your visitors decline — the exact figure varies wildly by audience and we will not invent one for you, but it is never small in Germany. Your Analytics no longer measures your shop; it measures the subset of your shop that says yes. And that subset is not random. It skews by device, by browser, by age, by how technical the visitor is. Which means your channel attribution is measuring a biased sample and reporting it as fact.
The way out is not a cleverer banner. It is to stop asking the browser for numbers the server already has. Your order table knows every order, with no consent required, because processing an order someone placed is not analytics. Revenue, order count, average basket, repeat rate, product mix, delivery country: all of it lives in your shop database and all of it is complete. Use Analytics for the questions only it can answer — where traffic comes from, what happens before the order — and accept those answers as directional. Steer on the server numbers. Explore with the sample.
The cheapest fix is to need less consent
Every third-party script on your shop is a thing you must ask permission for, disclose, keep listed, and defend. Most shops carry several they cannot justify: a heatmap tool nobody has opened since 2020, two ad pixels for campaigns that ended, a font loaded from someone else's server, a chat widget used twice a month. Remove them and the banner gets shorter, the page gets faster, the privacy policy gets honest, and the share of visitors who accept tends to go up — because a short, specific ask is easier to say yes to than a list of forty vendors.
| Question | Answer without consent | Needs consent |
|---|---|---|
| Revenue and order count | Complete — it is in your database | No |
| Average basket, repeat rate | Complete — server side | No |
| Which channel brought the order | Partial — biased sample only | Yes |
| On-page behaviour, funnel steps | Little — this is browser territory | Yes |
| Remarketing audiences | Nothing | Yes, explicitly |
- Most banners fail on the tags, not the wording — decline everything and check storage.
- Consent won by exhaustion is a legal risk buying you data that does not convert.
- With a big decline rate your analytics is a biased sample — steer on server-side numbers.
- Deleting unused third-party scripts shortens the banner and raises the accept rate.
Frequently asked questions
Only if it stores or reads things on the device that are not strictly necessary for the service the user asked for. A session cookie that carries the basket through checkout is necessary and needs no banner. Analytics, ad pixels, embedded video and chat widgets are not. A shop that carries none of those needs no banner at all — which is rarer than it should be.
This is exactly the design regulators and consumer groups have been pushing back on, and the direction of travel is clear: consent must be freely given, and a choice engineered to be tiring is not free. Beyond the legal exposure, it buys you consent from people who clicked to escape and will never buy anything. Put reject next to accept, same level, and take the honest number.
You lose very little actual traffic — people still shop. What you lose is measurement of the people who decline, and that share varies enormously by audience, so distrust anyone quoting you a universal percentage. The right response is not to fight for the number but to move your key reporting server-side, where your order data is complete and no consent is involved.
Yes, for the storage access itself. IP anonymisation is a DSGVO-side measure about the data you process; the TTDSG question is whether you wrote to or read from the device at all, and analytics cookies do. This is the distinction most 'we anonymise, so we are fine' arguments miss. Confirm your specific setup with a lawyer rather than with a plugin's marketing page.
Yes, and you should — your consent tool can log the decision itself, since counting a click on your own banner is not tracking the user across anything. Watching that rate over time is genuinely useful: it tells you whether a shorter vendor list or clearer wording moved anything. It is also the number that tells you how much of your Analytics you are allowed to believe.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer