- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
A banner that appears after the tracking has already run is decoration, not consent.
Cookie consent banner page: what it is for and what it actually has to do
A consent banner is one of the few elements on a site that every visitor sees and nobody wants. That makes it easy to treat as a box to tick — install something, accept the default wording, move on — and the version installed that way usually does not do the thing it was installed for. A banner that appears after the tracking has already run is decoration, not consent.
What follows is about the mechanics: what has to happen in which order, how the banner relates to the policy page behind it, and what it does to the numbers you report afterwards. Requirements differ by jurisdiction and by what a site actually collects, so treat the specifics as questions for a qualified adviser rather than answers — the mechanics below are what any answer has to be implemented on top of.
The banner and the page are two different things
| The banner | The policy page | |
|---|---|---|
| Purpose | Collect a decision | Explain what is collected and why |
| Length | A sentence and two or three controls | As long as it needs to be |
| Where it lives | Overlaid on every page | Its own URL, linked from the footer |
| How often it changes | Rarely | Whenever the tools on the site change |
The banner should link to the page rather than trying to be it. A banner that attempts a full explanation is a banner nobody reads, and the page is where a visitor who genuinely wants detail will go. Link it from a reusable header and footer as well, since a policy reachable only from a dismissed overlay is effectively unreachable afterwards.
Order of operations is the whole thing
The point of a consent mechanism is that non-essential scripts do not run until a decision has been made. That is an ordering requirement, and it is the part most installations get wrong: the banner is added to the page, the analytics and advertising tags stay exactly where they were, and both run on load regardless of what the visitor clicks.
The scripts to gate are the ones that are not needed to deliver the page — analytics, advertising and remarketing tags, heatmaps, chat widgets that profile visitors, embedded media that sets its own identifiers. The ones that stay are those the site cannot function without, such as the session that keeps a cart or a form’s progress intact.
In practice this means code placed in the page header has to become conditional rather than unconditional. If a tag is pasted directly into the header with no gate around it, adding a banner changes nothing about when it fires.
Categories, and how many to offer
Splitting non-essential cookies into a small number of named categories — typically something like measurement, advertising, and personalisation — lets a visitor make a real choice rather than an all-or-nothing one. More categories sound more respectful and produce more abandonment, because the banner becomes a form. Two or three, plainly named, is where most sites land.
Whatever the categories, the controls should be as easy to decline as to accept. A prominent accept button beside a hidden or multi-step decline is the pattern regulators have repeatedly objected to, and it is also the one that makes a site feel untrustworthy at the first interaction.
Record the decision, not just the click
A consent decision is only useful if it can be shown later: what was agreed to, when, and which version of the policy was in force at the time. Most consent tools keep this; where one does not, keeping the record in a record kept outside the platform is better than having nothing. It belongs with the other evidence of what a visitor agreed to, which is the same reasoning behind a terms and conditions checkbox.
Decisions also expire. A consent captured a long time ago against a policy that has since changed is not evidence of agreement to the current one, so plan for the banner reappearing periodically and after any material change to what the site collects.
What it does to your reporting
Once a banner is gating analytics, the numbers describe visitors who agreed rather than all visitors. This is the single most common source of confusion after an install: traffic appears to fall sharply on the day the banner went live, and nothing about the traffic has changed.
Three consequences follow. Comparisons across the install date are not like-for-like and should be annotated rather than explained away. Attribution weakens, because UTM parameters may be captured for some visitors and not others, and tracking outbound link clicks inherits the same gap. And any measurement you were relying on to settle a decision — declaring a split test winner in particular — needs a longer window to reach the same confidence.
Do not respond to the drop by weakening the banner. Respond by writing down what the numbers now represent, so that six months later nobody reads the step in the chart as a real event.
Where it sits, and the mobile problem
A banner that covers the content on a phone is the version people dismiss without reading, and if it overlaps a call to action it costs conversions directly. Check it against a sticky header, since a sticky header plus a bottom banner can leave very little of a small screen showing actual content.
hiding an element on mobile is not an answer here — a banner hidden on mobile is a banner not doing its job on most of your traffic. Make it smaller instead, with the explanation on the linked page rather than in the overlay.
On funnel steps the question is the same as with showing a footer on chosen pages: the banner is site-wide by nature, and suppressing it on a checkout step to protect conversion is not a decision to make casually.
Common failures worth checking for directly
- Tags firing before a decision — the most common failure, and invisible from the front end without checking what loads.
- The banner reappearing on every page because the decision is not being stored.
- A decline that stores nothing, so the visitor is asked again on the next visit.
- The policy page linked from the banner returning a 404 after a site restructure.
- A banner script heavy enough to be visible in a page speed score, which is worth checking since it loads before everything else.
- Advertising tags placed by a campaign — a paid social funnel is the usual route — added after the banner was configured and never gated.
The last is the one that recurs. A consent setup is correct on the day it is built and drifts every time a tag is added by someone who was not thinking about it. Re-check what loads before consent whenever a new tool goes on the site, and treat tracking code that is not firing as a prompt to check the gate rather than to remove it.
Frequently Asked Questions
Does every site need a cookie consent banner?
It depends on where the visitors are and what the site actually collects, which is a question for a qualified adviser rather than a general rule. A site that sets no non-essential identifiers has much less to ask about than one running analytics and advertising tags, so the honest first step is an inventory of what is actually loading.
Why did my traffic drop the day I installed the banner?
It did not. Analytics now runs only for visitors who agreed, so the reports describe a subset rather than everyone. Annotate the date, treat comparisons across it as not like-for-like, and expect any test you are running to need a longer window to reach the same confidence.
Which scripts should be blocked until consent is given?
Anything not needed to deliver the page: analytics, advertising and remarketing tags, heatmaps, profiling chat widgets, and embedded media that sets its own identifiers. What stays is the functional minimum, such as the session that keeps a cart or a partly completed form intact.
How many consent categories should the banner offer?
Two or three, plainly named. More categories look more thorough and turn the banner into a form, which increases the number of people who dismiss it without engaging. Whatever the number, declining must be as easy as accepting.
Does adding a banner automatically stop the tags from firing?
No, and this is the most common failure. A banner placed on a page alongside tags that were already loading unconditionally changes nothing about when they run. The tags have to be made conditional on the stored decision, which usually means changing how they are installed.
How long does a consent decision last?
Not indefinitely. A decision recorded against an older version of the policy is not evidence of agreement to the current one, so plan for the banner reappearing periodically and after any material change to what the site collects or which tools it uses.
Should the banner appear on funnel and checkout steps?
It is site-wide by nature, and suppressing it where it costs conversions is not a decision to make casually. The better fix is a smaller banner that does not cover the action, with the detail on the linked policy page rather than in the overlay.
What should the banner link to?
A policy page at its own URL that explains what is collected and why, kept up to date as the tools on the site change. Link that page from the footer as well, since a policy reachable only through an overlay the visitor has already dismissed is effectively unreachable.
We build your GoHighLevel account for you
CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.
- Setup (one-time)$850
- Ongoing (per month)$38.80
No obligation quote · reply within 1 business day
This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.