Google Consent Mode v2: Why Your Website Needs It Now.

Most South African websites start tracking visitors the moment the page loads. Analytics cookies, the Google Ads tag, a Meta pixel, a chat widget: all of them running before the visitor has been asked for permission.

This happens when a site has no cookie consent banner, and no Google Consent Mode v2 behind that banner to control what each tracking tag is allowed to do. Nothing on the page looks broken when this is the case, which is why it often goes unnoticed for years.

It creates two problems at the same time. The first is legal. You are collecting personal information without permission, and you have no record that proves otherwise. The second is commercial, and far fewer businesses spot it. Google needs to be told what each visitor agreed to. When your website never sends that answer, you lose access to advertising features that depend on it, and your conversion reporting gets thinner without anything warning you that it has.

The money involved is real. World Wide Worx puts South African online retail spend at R159-billion in 2026, or roughly 10% of national retail turnover. Businesses chasing that spend set their budgets and bids using conversion numbers. If the consent layer underneath those numbers was never built, the numbers are incomplete, which makes measuring performance properly impossible.

What Is Google Consent Mode v2, and Why Does It Matter?

Google Consent Mode v2 is a framework that passes a visitor’s consent choices to Google’s tags, so those tags can adjust what they collect before they collect it. Google describes it as a way to “adjust tag and app SDK behaviour based on user consent choices”. It sits between your consent banner and your measurement stack, translating a click on “Accept” or “Reject” into instructions every Google tag understands.

It works through four consent parameters. Google’s reference documentation defines each one:

The first two existed in the original Consent Mode. Version 2 added ad_user_data and ad_personalization, and Google introduced them so that advertisers could signal consent specifically for sending data to Google and for personalising ads.

Each parameter has a default state set before the banner appears, and an updated state set the moment the visitor chooses. Getting those defaults right by region is the part most implementations fail on, and it is the difference between a banner that looks compliant and a setup that actually governs your tags.

Why “We Don’t Sell to Europe” Is Not a Defence

This is the objection that comes up in almost every measurement conversation, and it falls apart on two fronts.

The first is local. POPIA applies to processing in South Africa regardless of where your customers sit. The Act defines consent as a “voluntary, specific and informed expression of will”, and section 11(2)(a) puts the burden of proof squarely on you: the responsible party bears the burden of proof for the data subject’s consent. A tag that fires before anyone has been asked produces no proof of anything.

That burden now has teeth. In July 2023 the Information Regulator issued a R5 million infringement notice to the Department of Justice and Constitutional Development for failing to comply with an enforcement notice. The regulator is no longer only publishing guidance.

The second front is Google’s own rules. Google’s EU user consent policy applies to end users in the European Economic Area, the UK and Switzerland, and it requires consent for the use of cookies or other local storage where legally required, and for the collection and use of personal data to personalise ads. Google is explicit about the consequence in its advertiser documentation: if you don’t send consent signals, you will lose ads personalisation capabilities.

Here is where South African businesses get caught. If your site serves different currencies or pricing by IP address, you are already serving users in those jurisdictions. You do not need a European office. You need one European visitor.

What Happens When There’s No Consent Banner and No Consent Mode?

When a website has no consent banner and no Consent Mode implementation, tracking tags collect visitor data without permission, and Google is sent no consent signals at all. That costs the business access to ad personalisation, remarketing and modelled conversions, and it leaves the business exposed on compliance at the same time.

It helps to separate the two, because they get solved by different people.

The compliance side is the one that gets attention in board meetings. The measurement side is the one that costs money every single day. Without consent signals, Google Ads management runs on thinner conversion data, bidding algorithms optimise against an incomplete picture, and remarketing audiences stop building properly.

A proper digital audit surfaces both at once, because they come from the same root cause. It is also a good illustration of what a good audit diagnoses. A business usually reports this problem as “our conversion numbers look wrong”. The actual fault is almost never in the reporting. It is in what the tags were allowed to do before the report was ever generated.

Basic or Advanced Consent Mode: Which Should You Implement?

Advanced Consent Mode is the stronger implementation for most advertisers, because Google tags load with default consent states set to denied and continue to send cookieless signals when a visitor declines. Basic Consent Mode blocks tags entirely until the visitor interacts with the banner, which means Google receives nothing at all from users who never respond.

Google’s documentation sets out the difference plainly. In advanced mode, tags load “with defaults set to denied” and send consent state and measurements without cookies, which supports an advertiser-specific model. Basic mode is blocked until interaction and falls back to a general model with less detailed modelling.

That distinction matters because modelling is how you recover what consent rejection takes away. Google reported in 2021 that conversion modelling through Consent Mode recovers more than 70% of the ad-click-to-conversion data lost to cookie consent choices, while noting that results vary widely by consent rate and setup. Treat it as a meaningful recovery rather than a guarantee.

Modelling also has entry requirements, and this is where thin implementations quietly disqualify themselves. Google requires a threshold of 700 ad clicks over a seven-day period per country and domain grouping for conversion modelling, and warns that without cookieless pings its systems cannot generate advertiser-specific calibration factors. For behavioural modelling in GA4, Google requires at least 1,000 events per day with analytics_storage denied for at least seven days, plus 1,000 daily consented users on seven of the previous 28 days.

Block your tags until someone clicks the banner and you may never reach those thresholds.

How Do You Implement Consent Mode v2 Correctly?

A correct Consent Mode v2 implementation starts with a consent management platform and ends with validation, and the order matters because each step depends on the one before it. Skipping straight to tag configuration without settled default states produces a setup that passes a visual check and fails a real one.

The sequence we work through:

1. Deploy a consent management platform. The banner is the input to everything else. Install the CMP tag on Consent Initialization so it runs before any other tag in the container.
2. Set default consent states by region. Defaults should reflect the applicable requirements for each market you serve, not a single global setting applied because it was easier.
3. Map every tag to its consent categories. Google Ads, Analytics and Floodlight tags carry built-in consent checks. Third-party tags such as social pixels and heatmaps do not, and each needs additional consent checks configured explicitly.
4. Fix the trigger, not only the tag. Tags still using an All Pages trigger will not re-evaluate when consent updates, so a returning visitor’s stored choice may never be honoured on first load. A custom consent-update trigger solves this.
5. Align GA4 and Google Ads settings. Confirm consent settings in the GA4 property and check that data is not automatically marked as consented.
6. Validate, then validate again. Consent signals take time to register. Check the consent status reporting in Google Analytics after roughly 48 hours rather than assuming the deployment worked.

Run this alongside the rest of your measurement governance. DataLayer clean-up, server-side tagging and audience consolidation all sit on top of the consent layer, and doing them first means redoing them later. The same logic applies to search engine optimisation reporting, which depends on the same analytics foundation.

One point worth stating clearly: server-side tagging does not remove consent obligations. Consent must be established before data is collected, processed or forwarded, no matter which side of the connection does the forwarding.

Web Is Only Half the Job: Consent in Your App

Businesses running both a website and a mobile app routinely fix one and forget the other. Google provides consent mode for apps through the Google Analytics for Firebase SDK, using the same four consent types set as default key-value pairs and updated at runtime through the setConsent method.

Reviewing the website in isolation leaves a gap that shows up later as inconsistent audiences and conversion counts that do not reconcile across properties. If the same customer can reach you through a browser and through an app, the consent setup needs to behave the same way in both. Treat the website and the app as one measurement environment with two entry points.

Where iLEAD et al Fits In

We have been a Google Premier Partner for 10+ years, which means we work inside Google’s measurement products daily and see how these implementations fail in practice rather than in theory.

Our approach is diagnostic first. We audit what is actually firing on your site, in what order, and against which consent categories, then sequence the fixes so the consent layer is settled before anything is built on top of it. That usually means consent and privacy requirements, then Advanced Consent Mode v2, then DataLayer and tag governance, then server-side migration and audience consolidation.

One boundary we are careful about: legal advice sits outside our remit. The applicable legal requirements and the appropriate consent model should be confirmed by your legal or privacy team. Our job is to make sure the technical implementation does exactly what that decision requires, and that it is validated rather than assumed.

The Consent Layer Comes First

Two things are worth taking away. Consent is a measurement requirement as much as a legal one, and the businesses treating it as purely a legal checkbox are the ones losing campaign performance without knowing why. And the order of work is not negotiable: the consent layer establishes whether your measurement technologies may operate at all, so everything else waits its turn.

If you are not certain what your site is collecting before a visitor agrees to anything, that is a question with a definite answer and it takes an afternoon to find. Get in touch with our digital strategy and consulting team and we will tell you exactly where you stand.

Frequently Asked Questions

Is Google Consent Mode v2 mandatory in South Africa?

Consent Mode v2 is not required by South African law, but POPIA does require valid consent for processing personal information, and section 11(2)(a) places the burden of proving that consent on your business. Consent Mode v2 is also required by Google’s EU user consent policy if you serve visitors in the EEA, the UK or Switzerland, which many South African sites do without realising it.

Does Consent Mode v2 replace a cookie consent banner?

No. Consent Mode v2 communicates consent choices to Google’s tags, but it does not collect those choices. You still need a consent management platform to present the banner, record what each visitor agreed to, and pass that decision into Consent Mode. The banner and Consent Mode are two halves of one system.

What is the difference between basic and advanced Consent Mode?

In basic Consent Mode, Google tags are blocked until a visitor interacts with the consent banner, so no data is sent beforehand and Google falls back to a general model. In advanced Consent Mode, tags load with defaults set to denied and send cookieless signals even when consent is refused, which supports more detailed advertiser-specific modelling.

Will I lose conversion data if visitors reject cookies?

You will lose observed conversions, but advanced Consent Mode allows Google to model a portion of what is missing. Google reported in 2021 that conversion modelling recovers more than 70% of the ad-click-to-conversion data lost to consent choices, though it notes that results vary widely by consent rate and implementation quality. Modelling also requires meeting Google’s data thresholds.

Does server-side tagging remove the need for consent?

No. Server-side tagging changes where data is processed, not whether you are allowed to process it. Consent must be correctly established and respected before data is collected, processed or forwarded through a server-side environment. Server-side GTM improves governance and control, and it sits on top of the consent layer rather than replacing it.