What to do if you get a complaint about your cookie banner
Measure before you answer. Record what your site actually does on each consent path, on a clean profile, then reconcile the complaint point by point against that evidence: concede what holds, rebut what does not with the request or cookie that disproves it, and counter propose where the remedy is wrong. The cause is usually not on the list.
The console is not evidence. The payload is.
The instinct when a complaint arrives is to reach for a compliance checklist. Those are the right reference for what a banner must do, and the regulators and the major consent vendors cover it well. They answer a different question from the one in front of you: not what a compliant banner looks like, but what your site did to the person who complained.
So the first move is a recording, not a settings review. Four paths on a clean profile: first load with nothing clicked, accept, refuse, and a returning visit with the choice stored. Note the cookies and vendor domains each produces. Ten minutes, and the only thing here that carries weight later.
The container we worked on had an audit reporting every tag configured for consent, nothing left unconfigured. The same day, a clean profile with the banner still on screen set seven cookies and called six vendor domains. Neither statement was false. They answered different questions.
Expect the list to be partly wrong
A complaint arrives as a numbered list and it is tempting to work down it as a verdict. Read it as a set of claims, each true or false, each checkable in the recording you just made.
On the estate this article draws on, the list had eight numbered points. Three were incorrect: the claim that no tag set a denied default was wrong, because the defaults were already correct and had been for some time; three of the tags named as ungated were in fact already gated; and one point named the wrong tag entirely. Four were correct and were conceded without argument. One was correct about the problem and wrong about the remedy, and needed a counter proposal rather than a yes or a no.
The distribution matters more than the individual points. Conceding something untrue is as damaging as denying something true: it commits you to a change that fixes nothing and weakens every other statement in the reply. Both directions want the same treatment, evidence attached to the answer.
The cause is usually not on the list
A complainant reports what is visible from outside: cookies present, vendors called, a banner that stopped neither. What loaded them is the part you find yourself.
Two places account for most of it, and neither shows up in a tag manager audit. The first is a vendor tag that loads other vendors. Here a marketing platform tag pulled in two advertising pixels of its own, so gating that one tag stopped all three, inverting an earlier conclusion that the container alone could not close the complaint. Check for it first: we covered the version people notice most often in why the Facebook pixel still loads when your tags are blocked.
The second is your own site head. Scripts pasted into the template load before the container can have an opinion, and no consent setting reaches them, by construction rather than misconfiguration. Three remained here after the container work finished, and needed a developer rather than tag manager access.
The order that produces a defensible reply
The sequence matters: each step decides what the next one may claim.
Record the four consent paths before you write anything
Private window, network and storage panels open, on a page you have not visited. Capture first load with nothing clicked, then accept, then refuse, then a returning visit with the choice stored. Save the cookies and vendor domains for each.
Reconcile the complaint point by point against that recording
Mark each numbered point correct, incorrect or partly correct, with the specific request or cookie that decides it. Do not answer from the tag manager console: it shows what is configured, and a complaint is about what happened.
Look for the cause that is not on the list
The points you were sent describe what was visible from outside. Ask separately what is loading those cookies: whether one vendor tag is loading others, and what sits hardcoded in your site's own head.
Split the fixes by who owns them
Sort each confirmed problem into three buckets: fixable in the container, only in the site's code, or only in a vendor's portal. They have different owners and lead times, and a reply promising a container fix for a site head script will not survive the follow up.
Verify on all four paths again, not in the audit view
Repeat step one against the published version and compare the recordings. Confirm a cached container file is not fooling you. It is served with a short cache, and our own first verification run here was reading the previous version with no sign of it. Check the version in the file you are being served before believing a failure.
Reply with the measurement, not with assurances
State what you measured, what you found, what was corrected, and what remains with a date and an owner. Points you dispute get the evidence attached, not a flat denial.
Two things worth having before one arrives
A baseline recording, taken while nothing is wrong, turns all of the above into a comparison rather than an investigation: testing a cookie banner before going live is the same procedure at a calmer moment. And the consent record, since a banner proves what was offered rather than what anyone chose, and only the record answers that.
Where we sit on this
We build a consent platform, so read this with that in mind. We treat the payload as the source of truth because it is also where the measurement damage shows: consent choices commonly hide around 34% of sessions from analytics, and a correctly configured consent layer typically recovers 20 to 40% of what would otherwise be lost. Figures are measured ranges across Amplio Data client implementations, not a guarantee. Recovery depends on your traffic mix, regions and how your tags are configured.
The uncomfortable version is that a banner can be well chosen, correctly installed and still leaking, because most of what leaks was never in the consent tool's reach. That gap exists at every price point, ours included.
Common questions
What people ask about this topic.
What should you do if you get a complaint about your cookie banner?
Measure before you answer. In a private window with the network panel open, record what happens on four paths: first load with no choice made, accept, refuse, and a returning visit with a stored choice. Then reconcile the complaint point by point against that recording. Only then do you know which points hold, which do not, and what is actually causing the problem.
Is a cookie banner complaint usually accurate?
Partly. On the remediation this article draws on, three of the numbered points were wrong when checked against the live payload rather than the console, four were correct and conceded, and one needed a counter proposal. Treat the list as claims to test, not a verdict: conceding an untrue point commits you to a change that fixes nothing.
Where do the scripts come from if the tag manager says everything is gated?
Two places the tag manager cannot see. Your own site head, where hardcoded scripts load outside the container entirely. And a vendor tag that loads other vendors: here one marketing platform tag pulled in two advertising pixels of its own, so gating that single tag stopped all three. A container audit reports on the container, and neither is in it.
Can you rely on the tag manager's own consent audit?
No, and this is the specific trap. On the container in question the built in audit reported every tag configured for consent, while a clean profile with the banner still showing set seven cookies and called six vendor domains. The audit describes configuration. A complaint is about behaviour, and only a recording shows that.
How do you prove your cookie banner was fixed?
Record the same four consent paths again after publishing and keep the before and after side by side. That pairing is what makes a reply defensible: it names the cookies and vendor calls that existed before and shows their absence afterwards. Watch for a stale cached container file: it is served with a short cache, and a run against the previous version reports a failure that is not real.
Your banner, your consent,
your data — all in one place.
