GA4 Plugins That Play Nicely With Consent Mode v2
Consent Mode v2 has been a requirement for advertising and measurement features in the European Economic Area since March 2024, and it is the part of analytics setup most likely to be quietly wrong. The signals look simple, the implementation spans three components, and nothing tells you when it is broken.
The question worth answering is not which analytics plugin supports it, but where the implementation actually lives, because in most correct setups it is not the analytics plugin at all. This article explains the signals in one section, sets out which component owns what, and gives you a test to run before trusting any of it.
Verified August 2026. This is general information about software, not legal advice. Requirements vary by jurisdiction and change; consult your own advisers.
The signals, in one page
Consent Mode is a way of telling tags what the visitor has agreed to, so they can adjust behaviour rather than simply being blocked or not.
Analytics storage. Whether measurement cookies may be set. Denied means the tag still runs but sends cookieless pings without identifying a returning visitor.
Advertising storage. Whether advertising cookies may be set, which governs remarketing and conversion attribution.
Two further advertising signals were added in version two, covering whether personal data may be sent to advertising services and whether it may be used for personalised advertising. These are the additions that made v2 a separate requirement rather than an update.
Two implementation details decide whether it works. The default state must be set before any tag loads, denied for European visitors, or a tag fires with consent it was never given. And when the visitor chooses, an update must be sent so tags adjust immediately rather than on the next page.
The 6 options compared
1. Your consent banner plugin
This is where the implementation belongs, and recognising that resolves most confusion in this area.
The banner is the only component that knows what the visitor chose, so it must set the default state before anything loads and send the update when they decide. The established consent plugins do this properly, including region detection so European visitors get a denied default while others do not, and they maintain the implementation as requirements change. Choose your banner on the strength of its consent signalling rather than its appearance, because everything downstream depends on it. If your banner only blocks scripts without sending consent signals, no analytics plugin can compensate, and the whole setup is misconfigured regardless of what else you install.
- Owns the implementation: Yes, correctly
- Sets defaults before tags: Yes, if properly configured
- Best for: Every site in scope
- Watch out for: Banners that block without signalling
2. A tag manager container
The cleanest place to enforce consent when several tags are involved, and the reason larger setups end up here.
A container can hold every tag behind consent requirements defined once, so analytics, advertising and anything else obey a single configuration rather than each plugin implementing its own interpretation. That is both easier to verify and far less likely to be subtly wrong, because there is one place to inspect. It also means adding a new destination later inherits the existing consent handling automatically rather than needing its own. Combined with a free data layer plugin, this is the setup most agencies standardise on. It requires competence with the container, which is the honest cost.
- Owns the implementation: Enforcement, yes
- Sets defaults before tags: Works with the banner
- Best for: Sites with several tags
- Watch out for: Requires container competence
3. Site Kit
The free official plugin, which installs the tag and expects your consent plugin to govern it.
Its position in this architecture is straightforward: it puts the tag on the page, and consent signalling comes from the banner. The established consent plugins are aware of it and integrate accordingly, so the combination works provided the banner is configured for consent signalling rather than script blocking alone. Because it is first-party, it also tends to track platform changes in this area reasonably promptly. The thing to verify is ordering: the consent default must be set before the tag initialises, which is a plugin loading-order question and the most common cause of an otherwise correct setup leaking a tag on first load.
- Owns the implementation: No, installs the tag
- Sets defaults before tags: Depends on load order
- Best for: Free setups with a good banner
- Watch out for: Verify ordering on first page load
4. MonsterInsights and ExactMetrics
The paid dashboards, which integrate with consent plugins rather than implementing consent themselves. From $99.50, with e-commerce and dimensions at $199.50.
They document compatibility with the major consent plugins, and in a correctly configured setup that works. What they do not do is remove the requirement for a properly configured banner, and it is worth being clear that paying for an analytics plugin does not buy you consent compliance. The practical checks are the same as anywhere else: confirm defaults are set before the tag loads, confirm the update fires on the visitor’s choice, and confirm no cookies are set before consent. Verify the specific combination of your banner and your analytics plugin rather than relying on a compatibility list, because the interaction is where problems live.
- Owns the implementation: No, integrates
- Sets defaults before tags: Via your banner
- Best for: Sites already using these products
- Watch out for: A licence does not buy compliance
5. Analytify
The cheaper dashboard, in the same architectural position. $99 for two sites, $199 unlimited.
As with every dashboard plugin, it places the tag and reports on the data; consent governance belongs to the banner. Its lower price does not change the architecture and neither does a higher one. The useful framing for anybody choosing an analytics plugin with consent in mind is that this is not a differentiator between them: the decision that matters is which consent plugin you use and whether it is configured to signal rather than merely to block. Pick the analytics plugin on price and features, pick the consent plugin carefully, and test the combination.
- Owns the implementation: No
- Sets defaults before tags: Via your banner
- Best for: Cheaper dashboard, same architecture
- Watch out for: Consent is not an analytics plugin feature
6. Self-hosted analytics instead
The option that reduces the problem rather than implementing it, and which deserves consideration for European sites.
Analytics that records visits in your own database, without cookies and without sending data to a third party, changes the consent question substantially. Depending on how the tool works and what it stores, it may fall outside the requirement for prior consent for measurement entirely, which means complete data from every visitor rather than partial data from those who accepted. That is a genuine accuracy advantage as well as a simplification. Confirm the specifics with your own advisers, since it depends on what the tool actually stores. What you give up is depth and advertising integration, so this suits content and service-business sites better than stores running paid acquisition.
- Owns the implementation: Reduces the need
- Sets defaults before tags: Often not applicable
- Best for: European content and service sites
- Watch out for: Confirm the specifics for your setup
Comparison table
| Component | Role | Sets defaults | Sends updates | Enforces blocking |
|---|---|---|---|---|
| Consent banner plugin | Owns consent | Yes | Yes | Yes |
| Tag manager container | Enforcement layer | With the banner | Reads the signal | Yes, centrally |
| Site Kit | Installs the tag | No | No | No |
| MonsterInsights / ExactMetrics | Installs and reports | No | No | No |
| Analytify | Installs and reports | No | No | No |
| Self-hosted analytics | Avoids the question | Often not applicable | Not applicable | Not applicable |
Testing that tags respect consent
Nothing warns you that this is wrong. Run these checks after setting it up, and again after any plugin update.
- Load the site in a clean private window and check cookies before choosing. Analytics or advertising cookies present before you touch the banner means consent is not being respected, and this is the single most common failure.
- Watch the network requests before consent. A cookieless ping is expected under denied consent; a request carrying an identifier is not.
- Accept, and confirm the update fires immediately. Tags should adjust on the same page rather than on the next one. If nothing changes until you navigate, the update is not being sent.
- Decline, and confirm nothing sets cookies afterwards. Then reload and confirm the choice persisted and is still honoured.
- Test from a European address if your default is region-based. A geographically conditional default that you only ever test from outside the region is untested.
- Retest after updates to the banner, the analytics plugin or the container. This breaks silently, and the first evidence is usually somebody else noticing.
On modelled conversions, be realistic. Where consent is declined, platforms may estimate some of the missing activity from aggregate patterns. That recovers part of the reporting picture, and it is an estimate rather than observed data. It does not restore individual visitor journeys, it varies by traffic volume, and it should not be treated as a reason to worry less about the implementation. Get the signalling right and treat modelling as a partial consolation rather than a solution.
Frequently asked questions
Which plugin implements Consent Mode v2?
Your consent banner, because it is the only component that knows what the visitor chose. Analytics plugins install the tag and follow the signal.
Does a paid analytics plugin make me compliant?
No. Compliance depends on your banner being configured to set defaults before tags load and send updates on choice. The licence fee is unrelated.
Is blocking scripts the same as consent signalling?
No, and the difference matters. Blocking stops tags entirely; signalling lets them run in a restricted mode, which preserves some measurement without setting cookies.
How do I know it is working?
Open a clean private window and check for analytics cookies before touching the banner. If any are present, consent is not being respected.
What do modelled conversions actually recover?
An estimate of some activity lost to declined consent, based on aggregate patterns. It is not observed data and does not restore individual journeys.
Can I avoid the whole question?
Possibly, with a self-hosted cookieless analytics tool, which may fall outside prior-consent requirements depending on what it stores. Confirm the specifics with your advisers.
The verdict
Choose your consent banner carefully, because it owns this. Analytics plugins install a tag and follow the signal; none of them makes the implementation correct on its own, whatever the price.
With several tags, enforce consent in a tag manager container. One configuration governing everything is easier to verify and far less likely to be subtly wrong than each plugin interpreting the banner separately.
For a European content or service site, consider self-hosted analytics instead. Cookieless measurement in your own database may sidestep the requirement entirely and gives you complete data rather than partial.
Then test it in a clean private window, and again after every update. Cookies before consent, an update that fires immediately, a declined choice that persists. This breaks silently, and nobody will tell you.
