Fixing Google Analytics 4 in Joomla when it isn’t working

You added Google Analytics 4 to your Joomla site. The tag is in the page source, Google's Tag Assistant confirms the page_view is firing — and yet Realtime stays stubbornly empty and your reports show nothing. Before you reinstall the tag for the third time, stop. In 2026, Consent Mode v2 is a hard requirement across the EU, UK, EEA, and an expanding list of regulated markets worldwide — and Google has begun enforcing it more aggressively than ever. The tag is almost certainly fine. The problem is the consent signal attached to it, and the rules around that signal have tightened considerably. What used to be a one-parameter oversight is now a four-parameter puzzle, and the gap between "banner looks like it's working" and "banner is actually wired correctly" has never been wider.

TL:DR – This is still the most common "GA isn't working" situation on Joomla sites in 2026, but the diagnosis now has more layers. The fix still usually takes under fifteen minutes once you know where to look — and it almost never involves touching the GA4 tag itself.

Why this problem has got worse, not better

A few years ago, Consent Mode was an optional enhancement for publishers who wanted cleaner data. That framing is now obsolete. Google treats Consent Mode v2 as a prerequisite for personalised advertising across the EEA, UK, and Switzerland, and has extended similar expectations to other markets with active privacy legislation. If your site runs AdSense, Ad Manager, or any Google advertising product alongside GA4 and you haven't fully migrated to v2, you're likely losing ad revenue and analytics data simultaneously — two problems that look identical on the surface: an empty Realtime tab and flat reports.

The compounding issue in 2026 is that many Joomla site owners set up their consent banners one, two, or even three years ago and haven't revisited them since. Consent Mode v2 introduced two additional parameters beyond the original pair — ad_user_data and ad_personalization — and a banner that was correctly wired for v1 may now be sending partial signals: granting analytics storage but silently leaving the new ad parameters denied. The result is the same blank Realtime view that's been confusing site owners for years, but with an extra layer of misconfiguration to diagnose.

Several popular Consent Management Platforms (CMPs) have updated their Joomla integrations to handle v2, but only if you're running a recent version of their plugin. If you configured your banner more than twelve months ago and haven't updated it since, there's a real chance you're running a v1-only integration against a v2-required stack — and nothing in the Joomla admin will tell you so.

The tag is fine — the consent signal isn't

Modern Google tags don't just send data; they send data stamped with a consent state. If you run a cookie or consent banner — and across the EU, UK, and a growing number of other jurisdictions you generally must — Google's Consent Mode decides whether each hit counts as full, cookie-based measurement or a stripped-down, cookieless ping.

The state Consent Mode starts in is denied. A denied hit still reaches Google — that's why Tag Assistant sees it — but GA4 treats it as an anonymous, cookieless signal that cannot be attributed to an individual session.

How to diagnose it in 60 seconds

Open Google Tag Assistant, or use your browser's DevTools → Network tab, and load your site. Find the request to …google-analytics.com/g/collect and check the gcs parameter.

It reads like G1xy, where the first digit after G1 is ad consent and the second is analytics consent — 0 means denied, 1 means granted.

For a complete v2 picture, Tag Assistant's Consent tab now surfaces all four parameters — analytics_storage, ad_storage, ad_user_data, and ad_personalization — and flags which are granted or denied at the moment the tag fires. This is the fastest way to catch a partial v2 misconfiguration, and it's the first place you should look in 2026 before touching anything else.

Tip: accept your own banner, reload the page, and re-check gcs. If it's still G100 after accepting, the banner is the problem — not Joomla, and not the tag.

The fix: connect your consent banner to Consent Mode v2

A consent banner does two separate jobs: it records the visitor's choice, and it has to translate that choice into Google Consent Mode signals. Plenty of setups do the first but silently skip the second. In 2026, that translation must cover all four v2 parameters — not just the original analytics_storage and ad_storage pair.

Using Google's own consent banner

If you use Google's built-in consent banner — the "Privacy & messaging" tool inside your AdSense, Ad Manager, or Google Analytics account — open your GDPR message settings and confirm all of the following are active:

• Enable consent mode for advertising purposes (ad_storage)
• Enable consent mode for analytics purposes (analytics_storage)
• Enable ad user data consent (ad_user_data) — required since v2
• Enable ad personalisation consent (ad_personalization) — required since v2

Until all four are active, the banner may record an IAB Transparency and Consent Framework (TCF) choice but never push the full consent update to Google's tag layer. The result: analytics_storage stays denied, gcs stays at G100, and GA4 records nothing visible in any report. Enable them all, save, and re-test with Tag Assistant.

Using a third-party CMP

If you use a third-party CMP — Cookiebot (now Usercentrics), CookieYes, Complianz, or any other — the principle is identical, but there are two things to verify. First, confirm that the plugin version you're running explicitly advertises Consent Mode v2 support, not just "Consent Mode" generically; v1-only integrations are still in the wild. Second, confirm that the integration fires the gtag('consent', 'update', {...}) call before the GA4 tag fires its first hit. A consent update that arrives after the initial page_view is too late — that hit has already been stamped as denied and won't be retroactively counted.

It's also worth noting that Cookiebot rebranded under the Usercentrics umbrella in recent years, so if your documentation or plugin references the old Cookiebot branding, double-check you're on the current version of the plugin rather than an abandoned fork.

A note on Google Tag Manager setups

Many Joomla sites load GA4 through Google Tag Manager rather than a hardcoded snippet. If that's your setup, the consent wiring lives in GTM — not in Joomla itself — and the failure mode is slightly different.

Check that your GTM container has a Consent Initialization trigger configured, and that your CMP's GTM template is firing on that trigger before any GA4 tags. Most major CMPs now publish official, maintained GTM templates — use those rather than custom JavaScript variables where possible, since the official templates are updated when Google changes its consent API. If your GA4 configuration tag fires on "All Pages" without a consent prerequisite, it will always send the default denied state first, regardless of what the banner does afterward. That single misconfiguration accounts for a large proportion of the "GA isn't working" reports on Joomla GTM setups in 2026.

One newer wrinkle: GTM's own built-in consent overview (available under Admin → Container Settings in recent GTM versions) now gives you a container-level view of which tags have consent checks configured and which don't. If you haven't looked at this panel, it's worth five minutes of your time — it will immediately show you any GA4 or advertising tags running without consent guards.

Server-side tagging and Joomla: an emerging complication

A growing number of Joomla site owners have moved to server-side Google Tag Manager setups in pursuit of better performance and reduced ad-blocker interference. Server-side tagging introduces a new consent wrinkle: the consent signals still need to originate from the client and be forwarded correctly to the server container. If your client-side GTM snippet isn't passing the consent state to your sGTM endpoint, the server-side GA4 tag operates without consent context and defaults to a denied state — producing exactly the same empty Realtime symptom described above, but with an additional layer of infrastructure to audit.

If you're running a server-side setup and hitting this problem, confirm that your client-side GTM container is forwarding the consent_state event data to the server container, and that your server-side GA4 tag is configured to respect it. This is an area where the official GTM documentation has improved considerably, but the implementation details vary depending on which sGTM hosting provider you're using.

What "working" actually looks like in 2026

Once consent is correctly granted you'll see live users in Realtime — but calibrate your expectations carefully:

• Visitors who decline or ignore the banner will never appear in Realtime. That's not a bug; it's the entire point of consent. Their activity feeds GA4's modelled data instead, which surfaces in standard reports over time.
• In markets with high banner-decline rates — common across much of the EU and increasingly in other regulated markets — a sparse Realtime view on a quiet site is entirely normal. Judge success by whether consenting visits appear, not by whether Realtime looks busy.
• GA4's behavioural modelling has matured significantly, and aggregate trends in your reports will be more representative than raw session counts suggest. Modelled data is not missing data — it's a deliberate privacy-preserving estimate. Don't let a low consented-user count panic you into thinking the tag is broken again.
• If you operate across multiple regions, be aware that consent requirements and default denial rates vary by market. A site with a large EU audience will naturally show lower consented-hit rates than one serving primarily non-regulated markets. Segment your GA4 reports by region if you want a clearer picture of consent impact versus genuine traffic patterns.

The 2026 checklist for Joomla site owners

When Google Analytics "isn't tracking" on a Joomla site, resist the urge to rip out and reinstall the tag. Work through this order instead:

1. Confirm the tag fires to the right Measurement ID using Tag Assistant.
2. Read the gcs parameter on the collect request — G100 is your immediate red flag.
3. In Tag Assistant's Consent tab, check all four Consent Mode v2 parameters, not just the analytics one.
4. Accept your own banner, reload, and re-check. If gcs is still G100, the problem is the banner's v2 mapping — not the tag, and not Joomla.
5. Update your CMP plugin if it predates Consent Mode v2 support. Check the plugin changelog explicitly for "v2" language.
6. If you're using GTM, verify the consent initialisation trigger fires before any GA4 tags, and review GTM's consent overview panel for unguarded tags.
7. If you're on a server-side GTM setup, confirm consent state is being forwarded from the client container to the server container.