CookieHawk › Guides › How to choose a consent solution
How to choose a consent solution without falling for the feature list
Every vendor ticks the same feature boxes. The difference only shows once you test what the solution actually does on your website. Here are the questions that separate them, and how to get answers before you pay.
We sell one of these ourselves. We have therefore stuck to questions you can put to any vendor, and to tests you can run without us. Where we have a view on what matters, we say so — but the criteria are the same whoever you choose.
The six questions that decide it
1. Does it block before loading, or after?
The most important question, and the one that most often is not in the feature list. A solution that shows a banner and stores the choice, but lets tracking scripts load with the page, gives you the choice in the interface without the effect behind it.
Ask the vendor directly: *do you block scripts sitting in the page source, or only what goes through Tag Manager?* The answer separates solutions more than anything else.
2. What does it do to page speed?
The consent solution loads first of all, on every page view. Its size therefore feeds straight into how fast the page feels — and speed affects both visitors and search visibility.
Ask for the size in kilobytes, compressed. The field ranges widely, from around 20 to over 200 kilobytes. Also ask whether the script must load synchronously first in <head>, because that blocks rendering while it loads.
3. Do you get a cookie list that stays current?
Most websites need an overview of which cookies are set. The point is not to have a list, but to have one that is accurate: if a plugin adds a new tracking tool in March, the list needs to know.
Ask whether the list is built from what is actually observed on your website, or filled in manually once.
4. Can you demonstrate that consent was given?
The burden of demonstrating consent sits with you as the controller. If asked, you must be able to show that a visitor consented, to what, and when.
Ask how long consents are stored, whether you can export them, and whether the log can be altered afterwards. A log that can be edited quietly demonstrates nothing in practice.
5. Does anything tell you when something changes?
This is where most setups fail over time. Your website changes — new plugins, a new theme, a campaign snippet from an agency — and tracking that was blocked in January can be back in April.
Ask whether the solution retests by itself, how often, and whether you are told when something new appears. If it does not, you need to set aside time to test yourself. Both are fine, as long as you know which one you chose.
6. What happens when something is wrong?
Finding a problem is half the job. Ask what happens next: do you get a report, an instruction, or help fixing it? If you are doing it yourself, you need an explanation you understand. If someone else is, you need to know what is included and what costs extra.
Test before you commit
Feature lists are easy to write. Do this instead — it takes half an hour and gives you comparable numbers:
- Measure your current setup first: which third parties are contacted before the choice, and what happens after “Reject all”? Without that baseline you cannot tell whether a new solution helped.
- Set up the trial on one website, not all of them.
- Repeat the measurement in exactly the same way, in a private window.
- Look at the difference. Did the list get shorter after a no? That is the entire point of the product.
- Finally, check how much the script added to load time.
A vendor who will not let you test before committing has answered question six without saying so.
Features that matter less than you think
- Number of languages. Useful if you have visitors in several languages. Otherwise decoration. Check instead that your own language was written by someone who speaks it — many banners are machine-translated, and it shows.
- IAB TCF. A framework for programmatic advertising. Unless you are a publisher selling ad space through ad exchanges, you almost certainly do not need it.
- Unlimited page views. Sounds good, but only matters if the alternative has a cap you would actually hit. Work out your own traffic before letting it decide.
- A/B testing the banner. It can raise the share who say yes, but tread carefully: optimising the design for maximum consent moves you quickly towards what regulators have described as deceptive design.
Two things that actually matter regionally
The blocklist decides what gets stopped. If it was assembled for a global market it will know Google and Meta, but not necessarily the regional services used heavily in your country. Ask whether local providers are covered.
And language: can you get support and documentation in a language your team works in, and was the banner written by someone fluent in it? It is not a legal requirement, but the visitor has to understand what they are agreeing to, and a clumsy translation does not help.
Common questions
What matters most when choosing a cookie banner?
That it actually blocks tracking before consent is given, rather than merely showing a banner and storing the choice. Everything else — language, design, feature list — counts for little if the data is sent anyway. Test it in the Network tab after “Reject all”.
Should I pick a local vendor?
Not automatically. What counts is whether the solution covers the services your website actually uses, and whether you can get help in a language you work in. An international solution with good regional coverage can beat a local one with poor blocking.
What should a consent solution cost?
It depends on what is included. If you will do everything yourself, there are cheap and free options that suffice. If someone is to monitor the website over time and fix what appears, you are paying for working hours, not software. Compare what is actually included before comparing prices.
Can I switch solutions later?
Yes. A banner is usually one snippet. What takes time is removing the old solution properly and testing that the new setup genuinely blocks. Budget an hour, not a project.
Test before you commit
Our free check shows what your website does before the choice and after “Reject all”. Run it on your current setup and on a trial setup — then you have comparable numbers instead of claims.
Check your website freeRead next
CookieHawk leveres av Webkompaniet AS · org.nr. 999 529 860 · Oslo · Vilkår · Personvern