Fixing GA 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, with Consent Mode v2 now a hard requirement across the EU, UK, and an expanding list of other regulated markets, the tag is almost certainly fine. The problem is the consent signal attached to it — and the rules around that signal have tightened considerably since this issue first started catching site owners out.

TL:DR – This remains one of the most common "GA isn't working" situations on Joomla sites, but the diagnosis has become more nuanced. The fix still usually takes ten minutes once you know where to look.

What's changed in 2026

When Consent Mode first rolled out, wiring it up was optional for most publishers. That's no longer true. Google now enforces Consent Mode v2 as a prerequisite for personalised advertising across the European Economic Area, the UK, and Switzerland. If your site runs AdSense, Ad Manager, or any Google advertising product alongside GA4, and you haven't migrated to v2, you're likely losing both ad revenue and analytics data simultaneously — two problems that look identical on the surface.

Consent Mode v2 introduced two additional consent parameters beyond the original pair: ad_user_data and ad_personalization. These sit alongside the familiar analytics_storage and ad_storage. A banner that was correctly wired for Consent Mode v1 may now be sending partial signals — granting analytics 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 now with an extra layer of misconfiguration to check.

Additionally, several popular third-party 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 set up your banner more than a year ago and haven't updated it since, there's a real chance you're running a v1-only integration on a v2-required stack.

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 more complete v2 picture, Tag Assistant's Consent tab now shows all four parameters — analytics_storage, ad_storage, ad_user_data, and ad_personalization — and flags which are granted or denied at the point of the tag firing. This is the fastest way to catch a partial v2 misconfiguration.

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 needs to cover all four v2 parameters, not just the original two.

If you use Google's own 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) — new in v2
• Enable ad personalisation consent (ad_personalization) — new in v2

Until all four are active, the banner may record an IAB choice but never push the full consent update to Google's tag layer. The result: analytics_storage stays denied, gcs stays at G100, and GA records nothing visible. Enable them all, save, and re-test.

If you use a third-party CMP — Cookiebot, CookieYes, Complianz, or any other — the principle is identical, but check two things: first, that the plugin version you're running explicitly advertises Consent Mode v2 support (not just "Consent Mode"); second, that the integration is configured to fire 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 for that hit to be counted as consented.

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. Check that your GTM container has a Consent Initialization trigger configured, and that your CMP's GTM template (most major CMPs now publish official GTM templates) is firing on that trigger before any GA4 tags. 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.

What "working" actually looks like

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

• 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 modeled data instead, which surfaces in standard reports over time.
• In markets with high banner-decline rates — common across much of the EU — a sparse Realtime view on a quiet site is entirely normal. Judge success by whether consenting visits appear, then watch your standard reports over several days.
• GA4's modeling has improved substantially, so aggregate trends in your reports will be more representative than raw session counts suggest. Don't mistake modeled data for missing data.

The takeaway for Joomla site owners in 2026

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 smoking gun.
3. In Tag Assistant's Consent tab, check all four Consent Mode v2 parameters, not just the analytics one.
4. If parameters are denied after accepting consent, fix the consent banner's Consent Mode v2 mapping — update the plugin if necessary — rather than touching the tag.
5. If you're using GTM, verify the consent initialisation trigger fires before any GA4 tags.