How to Set Up GA4 and Google Tag Manager to Fire Only After Consent (a WordPress Guide)

A friendly, UK-focused walkthrough using WPConsent and Google Consent Mode v2, based on how it’s actually configured on this site.

If your WordPress site fires Google Analytics 4 or Tag Manager the moment someone lands on a page, that is a problem worth fixing. Under UK law, analytics cookies need the user’s prior, informed consent before they can be set. That means no GA4 pings, no GTM tags loading anything non-essential, until the user has actively chosen to allow them.

This guide walks through how to make that happen on WordPress using WPConsent and Google Consent Mode v2. It is written from experience: this is the exact setup running on PrivacyAlly. There is a small trade-off on the stats you see afterwards, and I will be straight with you about what that looks like in practice.

The legal reality (and why “legitimate interest” is not the get-out you might hope)

The rule to know is not really GDPR on its own. It is PECR, the Privacy and Electronic Communications Regulations 2003. Regulation 6 says that any storage of, or access to, information on a user’s device needs prior consent, unless it is strictly necessary for a service the user has requested. Analytics cookies do not meet that bar. The ICO has been clear that measurement cookies benefit the site owner, not the user’s ability to receive the content they came for.

That means opt-in, not opt-out. It also means legitimate interest is the wrong legal basis here. PECR does not offer a legitimate interest exemption for non-essential cookies. If you have seen guides suggesting otherwise, they are getting it wrong.

In practice, small sites are rarely audited. But “unlikely to be caught” is a shaky operating principle for any business, and it is a particularly poor look for anyone working in privacy, legal services, healthcare, financial services, or any field where trust is part of the offer. In small businesses this often defaults to the IT manager, who was hired to run infrastructure rather than to police PECR.

What Google Consent Mode v2 actually is (and isn’t)

Consent Mode v2 is a signalling tool. It tells Google’s tags what the user has agreed to, using four parameters:

• analytics_storage for GA4

• ad_storage for Google Ads cookies

• ad_user_data (added in v2) for whether user data can be sent to Google for advertising

• ad_personalization (added in v2) for personalised advertising

There are two modes worth understanding.

Basic mode blocks Google tags entirely until consent is granted. Nothing loads, nothing pings, and you get data only from users who accept.

Advanced mode lets Google tags load in a limited state and send cookieless, anonymised pings before consent. Google then uses these to model behaviour for the users who declined, and can partially fill in the gaps in your reports.

One thing to be clear about: Consent Mode v2 does not make your site compliant on its own. It is a way of signalling consent state to Google. You still need a consent management platform (CMP) doing the actual work of blocking scripts, storing the user’s choice, and letting them change their mind later. That is where WPConsent comes in.

Why WPConsent

Plenty of consent plugins exist for WordPress. WPConsent is worth considering because it stores consent records in your own database rather than routing them through a third party, it supports Consent Mode v2 natively, and it handles the default-denied state without you needing to touch any code.

Other credible options exist. Complianz, CookieYes, and WebToffee’s plugin are all Google-certified CMPs. The plugin you pick matters less than getting the configuration right. This guide uses WPConsent because it is what runs on PrivacyAlly, so everything below reflects a live setup.

Step-by-step setup

1. Install and activate WPConsent

From your WordPress dashboard, go to Plugins > Add New, search for WPConsent, install, and activate it. The setup wizard launches automatically. Work through it and select UK or EU as your primary jurisdiction.

2. Confirm Google Consent Mode is enabled

Go to WPConsent > Settings > Cookie Configuration. Google Consent Mode should already be active by default. If it is not, switch it on. This sets the default consent state to denied for all four Consent Mode parameters before any tag loads.

3. Configure your banner properly

Under WPConsent > Banner, three things matter:

• Accept and Reject buttons should carry equal visual weight. Same size, same prominence, no design trick that makes Reject harder to find. The ICO has flagged non-parity as non-compliant. Google’s own CMP certification requires it too.

• No pre-ticked boxes for non-essential categories. Consent has to be an active choice.

• A visible “Manage preferences” option so users can pick and choose by category.

4. Add GA4 through GTM (or directly)

You have two routes. If you are running GA4 through Google Tag Manager, install the GTM container in your WordPress header using a plugin like WPCode, or through your theme’s header injection. GTM itself is excluded from consent blocking when Consent Mode is enabled in WPConsent, because GTM does not set tracking cookies. It is the tags inside GTM that need to respect consent, and Consent Mode handles that automatically for Google tags.

In GTM, open your GA4 Configuration tag. Under Advanced Settings > Consent Settings, check that “Built-in Consent Checks” is active. This is on by default for GA4 tags in recent GTM versions, but worth verifying.

If you are running GA4 directly without GTM, WPConsent can inject the GA4 measurement ID and manage consent for you. That is the simpler route for most small sites.

5. Handle non-Google tags separately

Consent Mode v2 only governs Google tags. If you also fire Meta Pixel, LinkedIn Insight Tag, HubSpot, or anything similar, these need explicit consent triggers in GTM. WPConsent pushes a wpconsent_consent_processed event to the dataLayer with the user’s category choices. Create a custom GTM trigger that fires on this event when the marketing category equals true, and use it as the trigger for those tags. Skip this step, and your non-Google pixels will fire regardless of consent, which is a compliance breach.

6. Test with Tag Assistant

Install Google’s Tag Assistant browser extension. Open your site in an incognito window with no prior consent stored. In Tag Assistant, check:

• The first event should show all consent states as denied.

• Click Accept All on your banner. Look for a consent_update event.

• Confirm analytics_storage, ad_storage, ad_user_data, and ad_personalization have all flipped to granted.

• Check the GA4 request URL for the gcs parameter. G111 means full consent. G100 means no consent. G110 means analytics only.

Then test again with Reject All. GA4 should not send hits, or should only send cookieless pings if you are in advanced mode.

The honest trade-off on data

You will see fewer visitors in GA4 than before. That is unavoidable, and it is correct. Rejection rates vary, but a reasonable planning assumption is that anywhere from 30 to 50 per cent of users will decline analytics cookies on a well-designed banner. Fewer if you have a highly trusting audience, more if your banner is very upfront about what tracking involves.

Advanced mode softens this by modelling behaviour from the anonymised pings, but it has thresholds. Google generally requires roughly 1,000 events per day with granted consent before it will populate modelled data in your reports. If you run a small consultancy site or a new blog, you may not hit that threshold, so what you see is what you get.

Two things worth keeping in mind:

1. The data you are “losing” is data you were not legally entitled to collect anyway. Reports built on non-consented data are a poisoned dataset. Technically accurate, legally unusable.

2. Server-side or cookieless analytics tools like Plausible, Fathom, or self-hosted Matomo configured with IP anonymisation may not require consent at all under PECR, depending on how they are set up. If losing GA4 visibility is genuinely painful, that is a separate conversation worth having.

On trust, honestly

A well-designed consent banner does not delight users. Nobody wakes up hoping to click cookie banners. But a banner that treats visitors as adults, offers a clear Reject option, and stops the tracking they have declined does say something about you. It signals that you have thought about this and are choosing to be straight with them rather than nudge them into consent through design tricks.

Whether that materially lifts conversions is hard to prove. What it does do is reduce complaints, keep the ICO off your back, and put you on the right side of a legal line that is being enforced more actively each year.

Common mistakes to avoid

• Loading GA4 or GTM in the site header before the CMP script has initialised. Order matters. The CMP needs to set default consent states before any Google tag runs.

• Assuming Consent Mode v2 replaces the need for a CMP. It does not. It signals; the CMP blocks.

• Forgetting non-Google tags. Meta Pixel and LinkedIn Insight need their own consent triggers.

• Using pre-ticked boxes or unequal button styling. Both are ICO non-compliance flags.

• Only testing with “Accept All.” Test with “Reject All” too, and with returning visitors who have prior consent stored.

FAQ