Consent banners, and the part of your audience the widget was never loaded for

A consent layer is a piece of code that runs early and decides what else is allowed to run. The usual implementation does not ask the other scripts to behave. It prevents them from executing at all, either by holding their tags back until a category is accepted, or by rewriting the tag to a type the browser will not run and swapping it back later, or by wrapping every third party include in a check.

The consequence for anything embedded with a tag is total rather than partial. There is no degraded mode. The widget does not load in a limited state, it is simply absent, and nothing on the page reports its absence because from the page's point of view nothing was requested.

This is worth understanding precisely, because it changes where the problem can be fixed. Nothing inside the widget can address it. By the time any of the widget's own logic could run, the decision has already been made somewhere above it, in a layer configured by whoever set up the banner, usually before the widget existed.

Consent layers sort scripts into categories, and the category decides the default. The names vary but the shape is familiar: something strictly necessary that runs regardless, something functional, something for measurement, and something for advertising. Where a chat widget lands is a decision, not a fact, and it is usually made by whoever was configuring the banner on the day.

It frequently lands in the marketing bucket, for an understandable reason: it came from an external supplier, it looks commercial, and when in doubt the cautious configuration is the strictest one. In a banner where nothing is on until it is accepted, that classification means the widget is off for everybody who does not actively opt in.

It is worth saying plainly that this classification is a legal and policy question in your jurisdiction rather than a technical one, and the correct answer depends on what the thing actually does and stores. The point here is narrower: whatever the right answer is, somebody chose one, probably quickly, and probably without anybody checking afterwards what that choice does to the support experience. Go and look at which category yours is in. Most people have never seen the screen.

It depends on your site, and anybody who gives you a single number for it is describing their own traffic rather than yours. The share of visitors who decline is driven by the audience, the country, the device, the wording of the banner, whether declining takes one click or several, whether the accept button is visually louder, and whether the default is on or off before anybody touches it.

Those factors move it a long way in both directions. A banner where declining requires opening a preferences panel and toggling four categories produces a very different outcome from one with two equally weighted buttons. A consumer site and a site whose visitors are mostly on managed work machines produce different outcomes again, and the same site can produce different outcomes in different markets.

So the honest position is that the number is unknown to you until you measure it on your own site, that it is not negligible on most sites, and that it is not something to reason about from a figure somebody quoted in a conference talk. The next section is about why measuring it is harder than it sounds.

There is no reason to expect the declining population to be a random slice of your traffic, and several reasons to expect it to be skewed towards people with a real problem. Somebody with a sensitive question is more likely to be cautious about what a site is allowed to load. Somebody reading your policy pages carefully is, by disposition, also somebody who reads the banner.

Add the mechanical overlaps. People on locked down work machines often have the decision made for them by policy. People running blockers, or older browsers, or a privacy oriented configuration, frequently end up in the same bucket without ever seeing a banner. None of these are casual browsers who wandered in from a search result. Several of them are the people whose questions are hardest and most worth catching.

That is the part that makes this an operational problem rather than a technical curiosity. If the widget were missing for a random tenth of visitors, you would lose a tenth of the value and nothing else. If it is missing disproportionately for the cautious, the constrained and the careful, then the questions it never sees are systematically different from the ones it does, and the picture you build from your logs is biased in a direction you cannot see from inside the logs.

The instrument you would naturally reach for to measure this is almost always behind the same gate. Measurement scripts are the archetypal consent category, so on most sites the visitors who declined are missing from the analytics for the same reason the widget is missing from their page. You are trying to count an absence with a tool that has the same absence.

What this produces is not a small error, it is a consistent one in a predictable direction. Your traffic totals under count the declining population. Your ratio of conversations to sessions is computed over a denominator that already excludes most of the people who could not have had a conversation. The number looks better than reality and it looks stable, which is worse, because stability reads as reliability.

There are ways round it and they all involve counting from somewhere the consent layer does not reach. Server side request counts for the pages themselves are one. A comparison between two independent counters, one gated and one not, is another, and the gap between them is the interesting quantity. Neither gives you a clean figure, and both are better than a number produced entirely inside the gate. If nothing else, load your own site in a fresh private window, decline everything, and look at the page. That single observation tells you whether you have a gap at all, which is more than most teams know.

Reclassifying the widget into a category that runs by default is the change with the largest effect and the one you cannot make on technical grounds alone. It is a question about what the thing stores, for how long, and under whose rules, and it needs whoever owns that decision in your business to make it deliberately rather than a support person changing a dropdown. The cost is that it is genuinely a decision, with genuine consequences if made carelessly.

Loading only on interaction is a narrower version: nothing runs until the visitor deliberately opens the assistant. It changes what is loaded before consent rather than the classification itself, and whether that helps depends entirely on the rules you are operating under. The cost is that the launcher itself has to come from somewhere, so this is a partial answer rather than a full one.

Putting a route that is not a script on every page is the option nobody likes and everybody should take. A plain contact link, a phone number, an address, marked up in the page itself so that it survives every blocker, every banner, every failed load and every browser you did not test. The cost is a small amount of page furniture. The benefit is that the visitors most likely to be excluded by everything else still have somewhere to go.

And the last option is to accept the gap knowingly, which is legitimate as long as it is a decision rather than an oversight. What is not legitimate is reporting on the assistant's performance as though the excluded population did not exist, because that is where the gap turns from a limitation into a wrong conclusion.

The durable conclusion from all of this is that the widget should never be the only way to get an answer or reach a person. Not because widgets are unreliable, but because everything loaded from a script tag lives downstream of decisions made by banners, blockers, network conditions and browser settings that you do not control and cannot enumerate.

This has a pleasant side effect. A site where the important answers are on the pages, and where a route to a person exists in the markup, is a site where the assistant is a convenience rather than a dependency. That is also the site where the assistant performs better, because the material it answers from is the same material a visitor could have found unaided.

It also gives you a clean fallback story for every other failure mode. The visitor who declined, the visitor on a bad connection, the visitor whose corporate proxy blocks unfamiliar origins and the visitor who simply never noticed the launcher all end up in the same place, which is a page that answers the question without one.

Open your own site in a private window and decline everything the banner offers. Note whether the launcher appears. Then accept and reload, and note the difference. That comparison takes two minutes and it is the entire diagnosis.

While you are there, check three things that go wrong even when consent is granted. Whether the banner sits on top of the launcher, which is common because both like the bottom corner and neither knows about the other. Whether the launcher appears before the banner is dismissed and steals attention from it. And whether keyboard focus is trapped anywhere between the two, which is the version of this problem that affects people who cannot simply click past it.

Then find out who owns the consent configuration in your organisation and ask them which category the widget is in and why. Not to overturn it. To know, and to make sure that whoever changes it next knows there is a support consequence attached.