Why Setting Up Analytics Is Still Broken in 2026

Analytics tools have had 15 years to sort out the installation experience. They haven't.

In 2026, getting accurate data into a web analytics dashboard still requires copying script tags, configuring proxy rewrites, fighting consent banners, debugging blocked requests, and manually verifying that anything actually works. Almost every tool has the same fundamental problem: setup is manual, verification is non-existent, and when something breaks you get silence — not an error.

This post documents what actually goes wrong, tool by tool. If you recognise any of these problems, you are not alone.

Google Analytics 4

GA4 replaced Universal Analytics in 2023. The migration was not smooth, and the tool has not gotten easier since.

Consent Mode v2. As of March 2024, GA4 requires Consent Mode v2 compliance in the EU. This means adding a CMP (consent management platform), configuring gtag('consent', 'update', ...) calls on user acceptance, and ensuring that the GTM tag fires correctly in every consent state. There is no built-in verification — you must use the browser's network tab and the GTM preview mode to confirm it works. Getting this wrong does not produce an error; it silently drops events or inflates modelled data.

Modelled vs observed data. When consent is denied, GA4 fills in gaps using machine learning. Your reports may show visitor estimates rather than actual counts — and it is not always clear which is which. If you are making product decisions from GA4 data in a GDPR-scoped region, a portion of your numbers may be synthetic.

14-month retention limit. GA4's default data retention is 2 months. You must manually change it to 14 months in the admin panel. Anything older than your retention window is gone — there is no export, no archive, no BigQuery fallback unless you set that up separately.

GTM container conflicts. Large sites accumulate GTM tags from multiple teams over years. Duplicate tags fire the same event twice. Competing consent configurations override each other. The recommended debugging process (GTM preview + network tab + DebugView) requires a GA4-literate developer and takes hours.

The reset problem. Universal Analytics to GA4 migration destroyed historical data for most organisations. There was no data portability. Teams that had years of trend data lost it overnight. This is not a theoretical risk — it has already happened once.

Plausible (self-hosted)

Plausible Community Edition is the open-source version of Plausible. Self-hosting is popular for teams with privacy requirements or budget constraints.

Startup crashes. Plausible v3.1.0 introduced a regression where newly created sites caused the application to crash on first event ingestion, requiring a container restart. This class of bug — where a common action breaks the system silently until restart — is endemic to containerised analytics. There is no health check endpoint that catches it.

Bot traffic overwhelming. Plausible Cloud has aggressive bot filtering. Community Edition does not. On any site with meaningful traffic, the self-hosted version will accumulate bot pageviews, distorting your session counts and bounce rate. Advanced bot filtering is a cloud-only feature.

Reverse proxy misconfiguration. Plausible behind Caddy or Nginx requires specific header forwarding to preserve visitor IP addresses for geolocation. A common misconfiguration — forwarding X-Forwarded-For incorrectly — causes all visitors to appear from the same IP. You see accurate pageview counts but broken country data. There is no error. There is no warning. You discover it three months later when your country breakdown shows 97% "Unknown".

Funnels and goals stripped. Plausible's funnel analysis and goal tracking are Community Edition features in some versions but cloud-only in others. Depending on the version you deployed, you may be missing features that do not exist in your tier.

Umami

Umami is the other widely deployed open-source analytics tool. It has similar reverse-proxy sensitivity.

503s at scale. Umami behind Nginx with 12+ websites can hit connection pool exhaustion. The symptom is intermittent 503 errors on the dashboard and event ingestion — not consistent enough to alert on, consistent enough to miss hours of data.

Post-login 404s. Umami has a known class of bug where CDN caching or reverse proxy configuration causes the dashboard to 404 or 500 immediately after login. The fix requires either cache-busting headers or specific Nginx try_files configuration — neither of which is documented prominently.

MySQL dropped in v3. Umami v3 dropped MySQL support, migrating exclusively to PostgreSQL. Teams running Umami on MySQL-based infrastructure (common in shared hosting environments) cannot upgrade without a full database migration. The upgrade guide exists but the migration process is not automated.

Debugging requires source access. Umami's containerised deployment does not expose structured logs via Docker without pulling the repository locally. Production debugging involves reading stdout from a container and mentally correlating it to the request that caused the error. This is a significant operational burden for small teams.

Fathom

Fathom is a privacy-first hosted analytics tool. It is simpler than GA4 and the self-hosted alternatives, but it has its own class of setup problems.

WordPress plugin conflicts. WP Rocket and SiteGround Optimizer — two of the most popular WordPress caching/optimisation plugins — both have options that minify or combine JavaScript. When they process Fathom's tracking script, they break it. The recommended fix is to exclude Fathom from minification, but the exclude rule syntax differs between plugins and caching layers. This is a common support ticket on Fathom's site.

CSP blocks. Fathom scripts served from cdn.usefathom.com require a Content-Security-Policy entry. Sites with strict CSPs (common in fintech and healthcare SaaS) frequently break Fathom silently — the script is blocked, events are dropped, no error is visible to the site owner.

SPA pushState. Fathom does not automatically track soft navigations in single-page applications. React Router, Next.js, and SvelteKit all use history.pushState for client-side routing. Without a manual fathom.trackPageview() call on route change, Fathom records only the initial page load. This produces a bounce rate of ~100% and a pages-per-session of 1, regardless of how engaged your visitors are.

Canonical tag mismatch. Sites with canonical tag configurations that differ from the actual URL pattern (common with staging environments, trailing slash normalisation, or www/non-www redirects) show all traffic attributed to the canonical URL. You see only homepage data. This takes significant debugging to identify because the script appears to be running correctly.

The structural problem

These are not bugs waiting to be fixed. They are the natural consequence of a shared architectural choice: every one of these tools requires you to:

1. Manually copy a script tag or configure a package.
2. Manually verify it works (by watching network requests or DebugView).
3. Manually configure reverse proxies, consent managers, and CSPs.
4. Discover misconfiguration by noticing bad data weeks later.

There is no install-time validation. There is no "your analytics is misconfigured" alert. There is no automated check that verifies the script is loaded, events are arriving, and country data is resolving correctly.

The industry has treated analytics setup as a one-time developer task. But developers change, infrastructure changes, plugins update, and CSPs tighten. The setup that worked six months ago may be silently broken today.

A different approach

Antlytics handles setup differently. The CLI installer (npx @antlytics/init) detects your framework, configures the tracking snippet, and verifies the install is working before it exits. The MCP server includes a check_install tool that lets your AI agent query the health of any tracked site at any time.

If you have just set up analytics and want to verify it is working, you can ask your AI agent directly:

Check that my analytics install is receiving data for site [your-site-name].

The agent queries the check_install tool, gets the event count for the last hour, and tells you whether setup succeeded — without you visiting the dashboard or reading network logs.

Setup should not require debugging. See the quick-start guide if you would like to try it.