Consent experience

Cookie consent analytics,
and proof of every single choice

Cookie consent analytics show how visitors respond to your banner: how many accept, which categories they allow, and where in the world they are. Underneath the charts, Kukie keeps every individual decision as a dated record with its own receipt identifier, so a single visitor's choice can be looked up and confirmed later.

Start free → Compare plans and retention

Consent data does two jobs, and they are not the same job

One is a management question you ask yourself, usually after changing something: are people accepting, and has that moved? The other is a question somebody else asks you, once, in writing, about one visitor on one day. The first needs charts. The second needs a record that still exists. Kukie produces both from the same stream of answers, and you will use them at completely different moments.

The dashboard

What everybody is doing

Aggregate figures, drawn from every answer your banner has collected: the split between accepting, refusing and picking individual categories, how that has moved day by day, which categories visitors are actually willing to allow, and how any of it differs by country.

This is the half you look at voluntarily. It tells you what your measurement really covers, which is not the same thing as what your analytics tool reports, and it is the only way to know whether a change to the banner made any difference at all.

The record

What one person did

Every individual decision is stored on its own, with a receipt identifier that can be looked up afterwards to confirm what that visitor was shown and what they chose. Refusals are stored exactly as carefully as acceptances, and so is a later change of mind.

This is the half you never think about until the day you need it, which is the day a complaint, a client questionnaire or a supervisory authority arrives asking you to demonstrate that consent was actually given. It cannot be created retrospectively.

What the consent dashboard shows you

Nothing to set up and nothing to instrument. From the moment the banner is live, every answer feeds these five views for the site you are looking at.

The headline split: How many decisions were collected in the period, and what share of them accepted everything, refused everything, or opened preferences and chose category by category. The third figure is the interesting one: it tells you how many people engage with the detail rather than taking the shortcut.
A day-by-day trend: The same split plotted over time, across the last 7, 30 or 90 days, or any date range you type in. This is what turns "we changed the wording" into something you can check, because you can see the line before and after the day you changed it.
Acceptance by category: Consent is not one number. Visitors routinely allow analytics while refusing marketing, and seeing the gap between the two changes how you read your reporting: your measurement coverage and your advertising coverage are governed by different consent rates on the same site.
A country breakdown: Decisions grouped by the country they came from, each with its own accepted, refused and customised counts. If you run different consent rules in different regions through geo-targeting, this is where you see the effect of them side by side.
Today, live: Today's figures are not held back for an overnight aggregation step. Publish a banner change in the morning and you can watch the answers arriving in the afternoon, which matters most in the first hours after a change when you are checking that nothing has broken. Completed days are summarised for speed; today is read straight from the incoming decisions.

One thing the dashboard will not give you is a target to hit. Acceptance rates vary enormously by audience, region, traffic source and how the banner is written, so a figure that would be alarming on one site is unremarkable on another. The reading and benchmarking guides below are the honest treatment of that question. Any of these views can also be downloaded as a CSV if you would rather work in a spreadsheet.

What happens when somebody asks you to prove it

Under the GDPR the burden of proof is yours. Where you rely on consent, you have to be able to demonstrate that the visitor consented, and the request usually does not come from a regulator first. It comes from a customer who wants to know why they are being followed around by your advertising, from a client's legal team filling in a supplier questionnaire, or from a buyer doing due diligence on the site you are selling.

Whatever the source, the awkward part is the same. Your current banner proves nothing about what somebody was shown last March, and "we have always had a banner" is a claim, not evidence. Without stored records there is no version of that conversation that ends well, and there is no way to build the records after the fact.

1. Narrow it down

The consent log filters by date range, by the type of decision and by country, so a query about a particular period or a particular market becomes a short list rather than an archive dig. Records are listed newest first, one row per decision.
2. Read the record itself

Each row carries the timestamp, the decision, the categories that were allowed, the country, the page it happened on and its receipt identifier. The full specification is in the table below, and it is deliberately boring: everything in it is there because somebody might one day have to justify it.
3. Confirm a single receipt

The receipt identifier is unique to that one decision and can be looked up afterwards to confirm it exists and what it says. That is what makes an individual record checkable rather than a line you typed into a spreadsheet yourself.
4. Hand it over as a file

Whatever the filters are showing can be exported as a CSV, which is the format anyone asking for evidence expects to receive. No screenshots of a dashboard, no copying rows by hand.

Kukie supplies the technical infrastructure for consent management, including the record. Whether the consent it records was validly obtained depends on how your banner is configured, and may require additional legal measures specific to your organisation. The banner itself is where most of that is decided.

What a single consent record contains

One row is written for one visitor answering the banner once. Every field below is stored for every decision, refusals included, and travels with the record into the CSV export.

The fields stored in a single Kukie consent record and the purpose of each
In the record	What it holds	Why it is there
Timestamp	The date and time the decision was made	Establishes that consent existed before the cookies that depend on it were set
Receipt identifier	A unique identifier for that one decision	Lets a specific record be looked up and confirmed later, on its own
Decision	Accept all, reject all, a custom selection, an update to an earlier choice, an implied consent or an opt-out	The answer itself, in the form the banner collected it, including the region-specific ones
Categories allowed	The exact list of consent categories the visitor permitted	Shows what was agreed to and, by omission, what was refused
Banner version	The version of your banner configuration that was live at that moment	Ties the decision to the wording and controls the visitor actually saw, not to today's banner
Country	The two-letter country code the visit resolved to	Shows which regional consent rules applied to that visitor
Page	The page the decision was made on	Locates the visit, and shows where on your site people are being asked
IP address and user agent	A one-way hash of each, never the raw value	Corroborates the record without storing anything that identifies the person

Keeping the proof without keeping the person

There is a trap in consent logging that catches people who take it seriously. Proof of consent is only useful if it is specific, and the obvious way to make it specific is to store more about the visitor: the IP address, the browser string, whatever else is to hand. You then hold a permanent, searchable file of who visited what and when, in the name of privacy compliance.

Kukie stores a one-way hash of the IP address and the user agent instead of the values themselves. A hash cannot be read back into an address, so the record still corroborates a decision without carrying the identifiable part of it. This is data minimisation applied to the evidence itself, and it means a consent log is a far less attractive thing to lose. The wider picture, including where the data is stored, is on the security page.

The same logic applies to how long you keep records. They are evidence, but they are also personal data, so holding them forever is not the cautious option it looks like. Retention in Kukie is configurable, older records are cleared automatically once they pass the window, and how far back you can go depends on the plan. If a long retention window matters to you, check it on the pricing page before you commit.

Not in a consent record

A name
An email address
A raw IP address
A raw browser user agent

What remains is enough to demonstrate that a decision was made, and not enough to build a profile of the person who made it.

Who needs consent records most

Every site relying on consent should be keeping them, because the cost of having them is nothing and the cost of not having them lands all at once. These are the situations where that bill arrives soonest.

You sell to businesses

Supplier questionnaires and procurement reviews now ask how consent is recorded, and the answer has to be more than a description of your banner. Being able to send a dated export ends that thread in one reply.

You work for clients

Consent records are how an agency demonstrates that what it installed is working, month after month, without asking the client to take anything on trust. They also settle the question of who was responsible for what, and when.

Your traffic numbers dropped

When analytics falls off a cliff after a banner goes live, the useful question is what share of visitors are actually allowing the analytics category. The category breakdown answers it directly, instead of leaving you to argue about the tracking.

Somebody else will inherit the site

A sale, a handover or simply a new person in the role. Records and a history mean the next owner can answer questions about a period they were not there for, which is otherwise impossible.

Consent logging can be switched off per site if you would rather not keep records at all, and it is on by default because most people should. The categories visitors are choosing between come from your cookie scan, so a record is only as meaningful as the categorisation behind it.

Features that feed this one

Consent records are produced by the banner and secured by the platform underneath it. These are the pieces closest to them.

Cookie banner

Layouts, categories and consent modes

Cookie scanner

Find every cookie automatically

Security

EU storage, hashing, audit logs

See the full feature set

Consent analytics and records

What site owners ask about measuring consent, and about proving it afterwards.

What is a consent record?

A consent record is the stored evidence of one visitor answering your cookie banner once. In Kukie it holds the date and time, the decision itself, the exact list of categories that were allowed, the country the visit resolved to, the page it happened on, the version of your banner configuration that was live at that moment, and a unique receipt identifier for that single decision. It is written for every answer, including refusals and later changes of mind.

How do you prove cookie consent if a regulator asks?

You produce the records. Under the GDPR the burden of proof sits with you: where you rely on consent, you have to be able to demonstrate that the visitor consented, and a screenshot of your current banner does not do that because it says nothing about what any individual was shown months ago. A consent record does, because it is dated, it names the categories that were allowed and it is tied to the banner configuration in force at the time. Kukie provides that record and lets you export it; whether your consent was validly obtained still depends on how the banner was configured.

How long should consent records be kept?

There is no single number in law. The working principle is that you should be able to demonstrate consent for as long as you are relying on it, and no longer than you need it, since the records are themselves personal data. Kukie makes the retention window configurable per organisation and clears older records automatically once they pass it. How far back you can keep going depends on the plan you are on.

Are cookie consent logs personal data?

Treat them as personal data, yes. A dated record of what a particular browser chose is information about a person even when it carries no name. That is why Kukie stores a one-way hash of the IP address and the user agent instead of the raw values: the record still corroborates the decision, but the identifiable part is not sitting in your database waiting to be exported or breached. There is no name and no email address in a consent record.

Can I see cookie consent rates by country?

Yes. The dashboard breaks consent down by country, showing how many decisions came from each one and how they split between accepting, refusing and choosing individual categories. It is the fastest way to see whether the rules you have set for a region are producing the behaviour you expected, and whether one market behaves very differently from the rest.

How current is the data in the consent dashboard?

Today's figures are live. There is no overnight aggregation step to wait for, so a banner change you publish this morning shows up in the numbers this afternoon rather than tomorrow. Historical days are summarised for speed, and the day-by-day trend covers whichever window you select, from the last seven days to any date range you type in.

Start recording consent properly today

Free plan, no card required. The dashboard and the records begin filling from the first visitor.

Start Free → View pricing

Cookie consent analytics,
and proof of every single choice