ConsentLift
Book a demo

Cookie consent glossary

Updated

The same words don't mean the same numbers from one tool to the next. An 80% "consent rate" on one dashboard and a 50% "opt-in rate" on another can describe exactly the same visitors. This glossary gives, for each metric, the definition we use, its formula, and the way it most often gets misread.

We follow the most common market convention, the one Didomi also documents for its own analytics. Where ConsentLift departs from it or makes it more precise, we say so.

One display of the consent banner to a visitor. It is the starting point for every other calculation, and the denominator of the opt-in rate.

The catch. Tools don't all count the same thing. Some count every page where the banner loads, some count once per session, and some also count re-displays when someone clicks "Cookie settings" in the footer. Before comparing two numbers, find out which of the three you are looking at. Bots inflate this count too: they load the page, the banner appears, and nobody ever clicks.

Decision

A visitor's answer to the banner: accept all, reject all, save a custom selection, or close the banner when the CMP records that as a choice. A "Continue without accepting" link counts as a rejection.

The catch. A visitor can change their mind on the same page: accept, reopen the settings, reject. Each change is a decision. It's rare, but on a small segment (an uncommon browser, a low-traffic page) it is enough to push a rate above 100%. That isn't a calculation error.

Acceptance

An "accept all" decision.

How ConsentLift counts it. A custom selection counts as a decision, not as an acceptance, even when it allows analytics. The category-by-category detail (analytics, advertising, preferences) is reported separately. Some tools count a partial acceptance as an acceptance, which is a common reason two dashboards disagree.

No-decision banner

Formula: banners shown − decisions

A banner that was shown and never answered. The visitor left, kept browsing without clicking, or couldn't click because the banner was hidden or broken.

The catch. From the visitor's point of view it isn't a rejection. From a legal point of view it isn't consent either: under UK and EU rules, carrying on browsing is not a valid way to agree to non-essential cookies. For your analytics and advertising tools, these visits are lost just like a rejection. And there are a lot of them: in its 2026 study of 2025 data, Didomi puts the "no choice" share between 21.7% and 27.4% depending on the region of Europe.

Opt-in rate

Formula: acceptances ÷ banners shown (bots filtered)

The share of banners shown that end in an acceptance. It is the number closest to what marketing actually cares about: the share of your traffic that your analytics and ad tools will be able to see.

The catch. It falls when the banner is ignored, badly displayed or blocked, even if its wording convinces everyone who reads it. A falling opt-in rate doesn't tell you, on its own, whether the problem is the message or the display. Read it with the decision rate. The full worked example: opt-in rate vs consent rate.

Formula: acceptances ÷ decisions (bots filtered)

Among visitors who answered, the share who accepted. It measures how persuasive the banner is with the people who actually read it.

The catch. It ignores everyone who didn't answer. A banner half your visitors never see can still post an excellent consent rate. It is the higher of the two rates, and often the one that makes benchmark headlines: when a 70% or 80% figure goes around, check its denominator first. Our guide to what a good cookie consent rate is puts the published figures in context.

Decision rate

Formula: decisions ÷ banners shown (bots filtered)

The share of banners that get an answer. It tells you about visibility and friction more than persuasion.

It links the two previous rates:

opt-in rate = decision rate × consent rate

With 60% of banners answered and 80% of those answers being acceptances, the opt-in rate is 48%.

The catch. A decision rate that collapses on a single browser or a single page almost always points to a technical problem, not a change of heart. Two real cases seen at clients: a Firefox-only bug that stopped clicks on the banner, and a popup that sat on top of it. Because it counts decisions rather than people, this rate can also go above 100% on low volumes.

Decided-session rate

Formula: sessions with at least one decision ÷ sessions shown a banner (bots filtered)

The same idea as the decision rate, counted per session instead of per display. It cannot exceed 100%.

The catch. It doesn't compare with the decision rate: the denominators differ. A session that sees the banner on three pages and answers on the third counts as one decided session, but as three banners and one decision.

Session shown a banner

A browsing session (one tab, from the first page load until it closes) during which the banner was displayed at least once, bots filtered. A reload or a page change in the same session doesn't count it twice.

It is the unit ConsentLift bills on, because a customer can reconstruct and check it.

Bots filtered

Visits by automated programs (search crawlers, monitoring tools, script-driven browsers) set aside before the rates are calculated.

Why it matters. A bot sees the banner and never clicks. Without a filter, every bot adds a banner with no decision, which drags down both the opt-in rate and the decision rate.

How ConsentLift spots them. An event is classed as a bot if it shows at least one strong signal (a user agent that declares itself a bot or automation tool, a connection from a hosting or cloud provider's network, a script-driven browser) or two weak signals together (an unusually short user agent and no declared language).

The limit. No filter is perfect. Some bots pass for ordinary browsers, and a network-based filter can set aside real visitors who come through a VPN or a privacy relay. That is why the filtered volume should stay visible, not just the resulting rate.

CMP (consent management platform)

The tool that displays the banner, records the visitor's choice and passes it to the site's tags: OneTrust, Cookiebot, Didomi, Usercentrics, Axeptio, Complianz and others.

The catch. Each CMP computes its statistics its own way: what counts as a display, what counts as an acceptance, how bots are treated. Two sites on two different CMPs can't be compared using their own dashboards. You need a common measurement layered on top. See the supported CMPs.

Consent categories

The groups of trackers a visitor can accept separately: analytics, advertising, preferences, social media. Strictly necessary cookies aren't one of them, because they don't require consent.

The catch. Names change from one CMP to another ("C0002" in OneTrust, "statistics" in Cookiebot, free-text labels elsewhere), and some CMPs file necessary cookies under a "functional" category. In ConsentLift, categories only describe what is optional: a reject-all sets every category to zero, whatever the CMP calls them.

The mechanism through which Google tags (GA4, Google Ads) adapt to the visitor's choice, using four signals: analytics_storage, ad_storage, ad_user_data and ad_personalization. Since early March 2024, Google has required consent signals for European Economic Area visitors to keep ad personalisation, remarketing and audiences.

The catch. You often hear that Google's modelling "fills in" the lost data. It only switches on above thresholds: at least 1,000 events a day with analytics_storage denied for at least 7 days, and at least 1,000 users a day with analytics_storage granted on at least 7 of the previous 28 days. Below that, nothing is modelled. For a mid-sized site, every lost point of opt-in stays lost.

IAB TCF

IAB Europe's Transparency & Consent Framework, now at version 2.2: a standard that lets the CMP pass consent to advertising partners as an encoded string. Almost every site that sells programmatic advertising uses it.

The catch. TCF purposes (about a dozen, numbered) don't map one-to-one onto the categories shown in the banner. A visitor can accept "advertising" in the banner and still object to some purposes in the detail view.

CMP change

Replacing one CMP with another, or any change to the banner that can alter how visitors behave: wording, button order or colour, a "Reject all" button on the first layer, showing the banner only on some pages.

The catch. Without an exact date, there is nothing to measure. And if you compare the old CMP using its own numbers and the new one using its own, you are comparing two definitions, not two banners. In ConsentLift, each change is entered by hand in the CMP Change Timeline, with its date, and the before/after comparison uses the same measurement on both sides. The full protocol: switching CMP without losing consent.

Before/after test (z-test)

A statistical test that compares two proportions, say the opt-in rate in the two weeks before a change and the two weeks after, and tells you whether the gap is bigger than chance would produce.

The catch. A significant result says the gap is real, not that the change caused it. A campaign launched the same week, school holidays or a spike in mobile traffic can produce the same effect. On low volumes, a three-point gap can be pure noise, which is exactly what the test is there to settle. Leave out the day of the change itself: it mixes both versions. How much traffic you need is covered in our CMP migration guide.

Sources: Didomi, "Consent rate vs Opt-in rate" (product documentation); Didomi, European consent benchmark, published 19/03/2026 on 2025 data; Google, "[GA4] Behavioral modeling for consent mode"; ICO guidance on cookies and similar technologies.; Google, "[GA4] Verify and update consent settings in Google Analytics": https://support.google.com/analytics/answer/14275483