Google Analytics & Cookie Consent Explained • Feel Created

Adding analytics is easy. Getting consent right is harder

Adding Google Analytics to a website is straightforward. Making sure it respects cookie consent is where many websites get caught out.

You copy the GA4 tracking code, add it to the site, check that visits are coming through and move on. At that point, it can feel like the job is complete.

The problem is that adding Google Analytics and making it compliant are not quite the same thing.

By default, Google Analytics starts tracking as soon as it loads. That can mean the site starts using cookies before a visitor has accepted them, or before they have had a clear choice at all.

For most website owners, this is not deliberate. Most are simply using the default setup without looking too closely at what happens when someone lands on the site.

That is often where problems begin.

The default GA4 implementation is not always enough

Google Analytics 4 provides teams with a lot of useful reporting, but simply adding it to a website does not automatically make that website compliant.

If the script loads straight away, it may begin collecting data and setting cookies before the user has interacted with your cookie banner. That creates a mismatch between what the website is doing and what the visitor has agreed to.

In real terms, this can mean:

analytics cookies get set too early
tracking starts before a user has made a choice
consent settings not matching the actual behaviour of the website
reporting tools are in use before they should be

This is one of the reasons cookie compliance involves more than just adding a banner.

A banner is only the visible part. The more important question is what happens behind it.

This rarely happens because organisations deliberately ignore privacy requirements. More often, Google Analytics was installed years ago using Google’s standard implementation, a cookie banner was added later, and nobody revisited how the two worked together. As new marketing tools, plugins and third-party services are introduced, the overall tracking configuration gradually becomes more difficult to understand.

Blocking everything can solve one problem, but create another

The simplest compliant approach is to block Google Analytics completely until someone accepts analytics cookies.

That can be a clean compliance route. If the user does not consent, the site keeps GA4 switched off. It does not set analytics cookies or track the visit.

For some organisations, that may be perfectly acceptable.

The downside is that you also lose a lot of visibility. If a large percentage of visitors reject or ignore the cookie banner, your analytics data becomes much less complete. You may lose early page views, entry behaviour and useful information about how people move around the site.

That matters because teams often use analytics to improve content, check whether key journeys are working, understand campaign performance and spot issues in the user experience.

So the question becomes: can you respect consent properly without significantly reducing the insight your analytics provide?

In many cases, yes.

There is a more balanced way to handle GA4.

Google’s consent mode allows analytics to run in a limited state before a user has accepted cookies. This approach is often described as cookieless tracking.

In simple terms, GA4 can collect limited information without storing analytics cookies or building a persistent user profile. You can still see broad interactions and page views, but visitors are not tracked at the same level of detail as someone who has accepted analytics cookies.

Once consent is given, GA4 switches to full tracking and begins using analytics cookies.

This gives website owners a more practical balance. Visitors are not fully tracked before giving permission, and organisations can retain some visibility into how their website is being used without compromising consent.

In practice, however, it is worth setting realistic expectations. Consent Mode does not replace the depth or consistency of data collected when visitors accept analytics cookies. Even with a well-implemented GA4 setup, organisations should generally expect to see less analytics data than they were used to before introducing proper consent controls.

That does not mean website traffic has fallen. It simply means fewer visits can be analysed in the same level of detail because not every visitor consents to analytics tracking.

A better GA4 implementation usually starts with a default consent state, typically managed through a Consent Management Platform (CMP) and applied through Google Tag Manager or an equivalent tag management solution.

When the page first loads, the site tells Google Tag Manager or GA4 not to use analytics or advertising storage. At that point, it only allows essential storage.

Then, when the user selects an option in the cookie banner, the consent state is updated.

If they accept analytics, GA4 switches to full tracking and begins using analytics cookies from that point onwards. If they reject analytics, it remains in its more limited state.

Rather than assuming consent, the website follows a clear set of rules based on the visitor’s choice.

Something that often gets missed is what happens after someone accepts analytics cookies.

Some implementations only start tracking properly on the next page load. That means the visitor may accept analytics, but the current page view is still not recorded unless they refresh the page or move to another page.

The important detail is what happens next. When someone accepts analytics cookies, GA4 can load immediately. A small JavaScript event can also record the page they are already on, so analytics does not have to wait for a refresh or a second page view to catch up.

What cookieless tracking can and can’t tell you

Cookieless tracking is not magic, and it should not be mistaken for a complete replacement for normal analytics.

Google’s documentation describes Consent Mode as a way of retaining useful insight before consent is granted, and it can certainly provide additional visibility compared with blocking analytics completely. Our experience implementing it across real websites, however, is that the data can still be inconsistent and should be treated as indicative rather than complete.

Before consent, you can still retain visibility over page views, basic events, broad traffic patterns and general interaction data. What you will not get is the richer insight that relies on analytics cookies, such as persistent user journeys, detailed attribution or behaviour across multiple sessions. Even overall traffic reporting can differ more than organisations expect when compared with previous GA4 implementations.

The compromise is still worthwhile because it supports a compliant implementation while retaining some understanding of website activity. The important thing is to recognise that a fully consent-aware GA4 setup will usually report less data than a traditional implementation, even when nothing has changed about the number of people visiting the website. Some organisations also choose to supplement GA4 with privacy-focused analytics platforms to provide a broader comparison of overall traffic levels, rather than relying on GA4 alone.

Many cookie banners are technically present but not particularly helpful.

They give users a choice, but the language can be vague. The categories are not always clear, and the interface can feel like an afterthought rather than part of the website.

A more considered consent experience should be easy to understand and easy to use.

That usually means:

clear categories, such as analytics, marketing and preferences
plain explanations of what each category means
obvious options to accept, reject or customise
a design that feels part of the website, not bolted on

The better approach is to look at the tools running on the site and build the consent experience around those choices.

It is rarely just Google Analytics

GA4 is often the first thing people think about, but it is rarely the only script on a modern website.

A site may also use:

Meta or LinkedIn pixels
embedded videos
Google Maps
live chat tools
marketing automation scripts
personalisation tools
social media embeds

Each of these can introduce its own tracking behaviour. Some may set cookies or send data to third-party platforms. Others may need to stay inactive until the user has given a specific type of consent.

Consent only works if the tools follow the choices made by the user. If they say no to marketing cookies, marketing tools stay off. If they only accept analytics, the site loads only the tools related to analytics. Any new script that gets added needs the same treatment; otherwise the implementation soon starts to unravel.

That is often where websites become messy over time.

We generally recommend treating analytics and consent as part of the same implementation rather than separate tasks. When tracking, tag management and consent are planned together, websites are easier to maintain and less likely to fall out of compliance as new tools are introduced.

Websites change. Marketing teams add new tools. Analytics platforms update. Embedded content gets introduced. Campaign tracking evolves.

If scripts span templates, plugins, theme files, and third-party snippets, it becomes much harder to understand what the site is loading and when.

A more maintainable approach usually means:

managing scripts centrally
setting clear consent categories
putting each script in the right place
checking new tools do not slip around consent
testing what happens when users accept, reject or customise cookies

A well-managed implementation should not make the website more complicated for users. The aim is the opposite: clear structure behind the scenes, and a simpler experience on the front end.

It is easy to sort the banner once and assume that is enough. For a while, it might be. Then someone adds a new tracking tool, embeds a third-party service or changes how analytics works.

That is when cookie consent needs a bit of housekeeping. This should be reviewed in the same way you would check performance, security, accessibility or content quality.

The questions are practical ones:

What data are we collecting?

Why are we collecting it?

Which tools are active on the site?

Do users have a clear choice?

Does the website behave in line with that choice?

It is worth revisiting those questions whenever the site introduces new analytics, advertising or third-party tools.

A more practical way forward

For most organisations, improving GA4 and cookie consent doesn’t require a complete rebuild. It usually means establishing consent before analytics runs fully, using cookieless tracking where appropriate, and ensuring every additional script follows the same consent rules.

That is usually where a more considered setup pays off. Not just in compliance terms, but in the day-to-day management of the website.

Cookie consent shouldn’t be treated as a box to tick after a website launches. Like accessibility, security and performance, it’s part of how a well-built website behaves every day. When analytics, consent and implementation work together, organisations gain better insight while giving visitors genuine control over their data.

For organisations that rely heavily on reporting, it can also be useful to complement GA4 with privacy-focused analytics tools such as Cloudflare Web Analytics. These tools are not a replacement for Google Analytics and provide a much simpler view of website activity, but they can offer a helpful comparison point when interpreting traffic trends alongside consent-aware GA4 reporting.

Taken together, this can provide a more balanced picture of website performance. GA4 continues to deliver detailed analysis for visitors who consent, while supplementary analytics can help validate overall traffic levels without relying on the same tracking approach.