Why I Finally Left GA4 (And Why It Took Me Too Long)
I held on to GA4 longer than I should have. Eighteen months longer, if I'm being honest with myself. The combination of inertia, client expectations, and the vague hope that Google would fix the things that were making my SEO reporting feel like guesswork kept me in place well into 2025. Then a client asked me why their organic sessions had dropped 34% month-over-month, and I spent two hours trying to explain data thresholds, blended session definitions, and the quirks of GA4's event-based model before I realized I couldn't actually give a clean answer. Not because the traffic had changed. Because the tool had changed what it was counting.
That was my breaking point.
What followed was a four-month evaluation period across four tools: Plausible, Matomo, Fathom, and PostHog. I ran them in parallel on real client sites, ranging from a 40,000-visit-per-month SaaS blog to a 1.2-million-visit e-commerce property. I tracked not just the numbers each tool reported, but the time it took me to get from a question to an answer. Latency to insight, I started calling it. That phrase will matter by the end of this piece.
This article is the synthesis of that process. Not a theoretical comparison. Not a feature-matrix regurgitation. What I actually found when I tried to do real SEO work inside each tool.
What SEO Reporting Actually Needs in 2026
Before I get into individual tools, I want to be specific about what "SEO reporting" demands from an analytics platform, because it's a different ask than general product analytics or marketing attribution.
For organic search specifically, I need:
- Accurate landing page data with the ability to filter by traffic source at the page level
- Reliable session counts that don't shift retroactively
- Crawlable, consistent UTM parameter handling
- Engagement signals (scroll depth, time on page, bounce behavior) that map to what search engines are inferring about user satisfaction
- Fast enough reporting that I'm not waiting for queries to resolve during a client call
- Some form of data ownership, or at minimum, clear data retention windows
I also need the tool to not terrify non-technical stakeholders. This sounds soft, but it's operationally real. If the person reviewing the monthly report needs a 30-minute onboarding session to read a dashboard, the tool is creating work, not removing it.
GA4 fails on several of these. Retroactive data sampling, sessions that restart on UTM parameter changes, the removal of universal metrics that SEOs had built workflows around, and a UI that requires navigating through five screens to answer a question a previous generation of tools answered on page load. None of that is a secret in 2026. The question is what to move to.
Plausible Analytics: The Minimalist That Punches Up
Plausible is the tool I underestimated most going into this evaluation. I assumed "simple analytics" meant "limited analytics." I was wrong.
The dashboard loads in under two seconds, every time. The default view gives me traffic by source, top pages, geographic breakdown, and device type in a single scroll. For an SEO audit call, this is exactly what I want to walk a client through. No loading spinners. No permission errors. No "data is being processed" placeholders where numbers should be.
For SEO-specific use, Plausible handles UTM parameters cleanly. Organic search traffic is segmented correctly. I can filter to any landing page and see source breakdown without building a custom report. The entry page filter is particularly useful: it's one click, not a pivot table construction project.
Plausible's Pricing in Real Terms
Plausible prices by pageview volume, not events. For a 500,000 pageview-per-month site, the current pricing sits at around $79/month on the Growth plan. Scale to 2 million pageviews and you're at $169/month. Compare that to GA4's pricing if you're using GA4 360 at enterprise scale: the floor is roughly $150,000 per year, and the event-based billing model in BigQuery exports adds cost unpredictably depending on how aggressively you're instrumenting. For most of the sites I work on, Plausible's cost is a rounding error.
The one honest limitation: Plausible does not do funnel analysis or user journey mapping in the way PostHog or even Matomo does. For pure SEO reporting, this rarely matters. For clients who want to understand how organic visitors convert across multi-step flows, it starts to matter. I flag this before recommending it.
Latency to Insight
Plausible: approximately 4 minutes from "I have a question" to "I have a defensible answer." This is not hyperbole. The interface is opinionated enough that there aren't many wrong turns.
GA4 equivalent: I stopped timing it after 22 minutes on the same question type. Exploration reports, custom dimensions, and the event model that requires knowing in advance which events to look at all add friction. Every. Single. Time.
Matomo: The Enterprise Workhorse With a Complicated Personality
Matomo is the tool I have the most complicated relationship with, because it is genuinely the most capable and also the most likely to punish you for using it incorrectly.
The self-hosted version gives you complete data ownership. No sampling. Full SQL-level access to your own database. GDPR compliance that actually holds up under scrutiny, not just under your own reading of the documentation. For clients in regulated industries — healthcare, finance, legal — Matomo self-hosted is sometimes the only tool that clears their compliance review.
I run Matomo on two client sites. One is a healthcare-adjacent content property where data sovereignty is non-negotiable. The other is a high-volume news site where retroactive data changes from any cloud tool would be catastrophic for the trust of the internal analytics team. In both cases, Matomo is the right call and I don't second-guess it.
What Matomo Gets Right for SEO
Matomo's SEO-specific features go further than any other tool in this comparison. There is a built-in keyword ranking integration (pulling from search console data, similar to how GA4 does it but more configurable), a heatmap tool that helps correlate engagement with ranking behavior, and an A/B testing module that lets you validate whether SEO-driven content changes are improving engagement metrics. The funnel visualization is genuinely useful for understanding organic visitor behavior beyond the landing page.
The visit log is also something I've come to rely on. In Matomo, I can look at individual session-level data, see exactly which pages an organic visitor hit, and understand the content journey. This kind of granularity is unavailable in Plausible and Fathom by design. PostHog offers it, but through a different interface paradigm.
The Real Cost of Matomo
Here is where I have to be direct: Matomo is not free if you value your time. The self-hosted version requires server maintenance, plugin updates, and the occasional database performance investigation when a query starts timing out on a high-traffic month. I've spent real hours on Matomo infrastructure that I've never spent on Plausible or Fathom.
Matomo Cloud removes the infrastructure overhead but reintroduces data hosting by a third party, which defeats one of the main reasons people choose Matomo over simpler alternatives. The cloud pricing is also not small: at 2 million monthly hits, you're looking at around $230/month. That's more than Plausible at the same scale, with a more complex interface to justify the difference.
For teams with a dedicated data engineering resource, Matomo is powerful. For a solo SEO consultant or a small agency team, it can become a distraction.
Fathom Analytics: The One I Recommend to Clients Who Hate Analytics
Fathom is the most opinionated tool in this comparison. It makes decisions for you. It does not offer a way to build custom segments from scratch, does not expose raw event logs, and does not give you a heatmap or session recording. It is, by design, a privacy-first pageview counter with a clean source breakdown and a filter system that covers about 80% of the questions a content-focused SEO team needs to answer.
That 80% figure is the whole argument for Fathom.
I started recommending Fathom specifically to clients who were coming from a place of analytics paralysis, where GA4's complexity had caused them to stop looking at their data at all. This is more common than people in the analytics industry like to admit. A dashboard that nobody checks is worse than a limited dashboard that gets reviewed every week. Fathom gets reviewed every week by clients who previously opened GA4 twice a year.
Fathom's SEO Utility
Referrer tracking in Fathom is accurate and uncluttered. Organic search traffic segments cleanly. UTM parameters are parsed and presented in a filterable table. There's a goal-tracking system that covers the most common conversion events without requiring custom event schema design. For SEO reporting that centers on "which pages are getting organic traffic and what happens next," Fathom answers that question faster than anything else I've tested.
Pricing is simple: $15/month up to 100,000 pageviews, $35/month up to 500,000, scaling from there. No per-event pricing. No BigQuery export fees. No surprises at the end of the month. The cost per million events is effectively the lowest in this comparison once you factor in the total time and infrastructure cost of alternatives.
Where Fathom Falls Short
Multi-site management. Fathom handles multiple sites under one account but the cross-site reporting is minimal. For agencies managing 20+ client properties, the lack of a proper multi-site view is a genuine workflow problem. I work around this with a custom dashboard that pulls from Fathom's API, but that's a workaround, not a feature.
Also: no server-side option. Fathom relies on a client-side script, which means ad-blocker and privacy-tool data loss is a real factor. Plausible has the same limitation without a proxy setup. Matomo and PostHog both offer server-side tracking that largely solves this problem.
PostHog: When Your SEO Team and Product Team Finally Share a Tool
PostHog is the outlier in this comparison. It is not primarily a web analytics tool. It is a product analytics platform that has expanded into web analytics, session replay, feature flags, A/B testing, and a data warehouse. It is also, somewhat remarkably, the best-funded and fastest-moving tool in this list, with an open-source core that has attracted serious engineering contributions.
I started using PostHog for SEO reporting almost accidentally. A client was already using it for product analytics, and I needed landing page performance data. What I found was that PostHog's web analytics module had quietly become good enough to replace GA4 for traffic analysis, while the session replay and funnel tools answered questions about organic visitor behavior that I'd previously needed separate tools for.
PostHog for SEO: The Actual Use Case
PostHog's event-based model is similar to GA4's in architecture but dramatically more transparent. When I set up a custom event in PostHog, I can immediately query it. No 24-48 hour processing delay. No "this dimension is not yet available in your reports" message. The query interface is fast, the filters work as expected, and the data is not sampled by default for standard usage volumes.
The session replay feature is where PostHog genuinely separates from the field for SEO work. When a high-value organic landing page has a high bounce rate, I can watch actual session replays of organic visitors to understand why. This is the closest thing to qualitative research that an analytics tool offers, and it's directly useful for diagnosing content issues that ranking data alone can't surface.
PostHog Pricing: The Math Changes at Scale
PostHog's free tier covers 1 million events per month. After that, the pricing is event-based: roughly $0.00045 per event, which sounds small and is small, until you're instrumenting a high-traffic site aggressively. At 10 million events per month, you're looking at approximately $3,800/month before any discounts. For SEO reporting specifically, where you're tracking pageviews and basic engagement events rather than dense product telemetry, the event volume stays manageable. But this is worth modeling before you instrument.
The self-hosted option (PostHog Cloud on your own infrastructure) changes the calculus entirely. Event costs disappear; infrastructure costs appear. For teams with engineering support, this is a genuinely attractive option. For solo practitioners, it's a different kind of overhead than Matomo's, but overhead nonetheless.
Side-by-Side: The Numbers That Actually Matter
| Tool | Pricing Model | Cost at 2M Events/Month | Data Ownership | Latency to Insight | Ad-blocker Resistance | SEO-Specific Features | Session Replay |
|---|---|---|---|---|---|---|---|
| Plausible | Per pageview | ~$169/mo | Cloud (EU servers) | ~4 min | Low (no proxy default) | Good | No |
| Matomo (Self-hosted) | Infrastructure cost | $20–80/mo (server) | Full ownership | ~12 min | High (server-side) | Excellent | Yes (premium) |
| Matomo Cloud | Per hit | ~$230/mo | Cloud (Matomo hosted) | ~12 min | Medium | Excellent | Yes (premium) |
| Fathom | Per pageview | ~$79/mo | Cloud (CA servers) | ~3 min | Low (no proxy) | Moderate | No |
| PostHog (Cloud) | Per event | ~$900/mo | Cloud (US/EU) | ~6 min | Medium (proxy available) | Good + growing | Yes (included) |
| GA4 (Free) | Free / 360 enterprise | Free (sampled) | None | ~20+ min | Low | Limited | No |
A note on the "cost at 2M events" column: these figures assume pageview-equivalent tracking only, no additional product events. PostHog's cost rises steeply if you instrument user interactions, form fields, scroll depth events, and other behavioral signals in addition to pageviews. At that level of instrumentation, self-hosted PostHog or Matomo self-hosted become the only cost-effective options at scale.
Implementation Notes: Scripts, Proxies, and Custom Events
This section gets technical. Skip it if you're evaluating at a strategic level and come back when you're in implementation mode.
Basic Script Tags
All four tools can be deployed with a simple script tag. Here's the minimal implementation for each:
<!-- Plausible -->
<script defer data-domain="yourdomain.com" src="https://plausible.io/js/script.js"></script>
<!-- Fathom -->
<script src="https://cdn.usefathom.com/script.js" data-site="ABCDEFGH" defer></script>
<!-- Matomo -->
<script>
var _paq = window._paq = window._paq || [];
_paq.push(['trackPageView']);
_paq.push(['enableLinkTracking']);
(function() {
var u="https://your-matomo-instance.com/";
_paq.push(['setTrackerUrl', u+'matomo.php']);
_paq.push(['setSiteId', '1']);
var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s);
})();
</script>
<!-- PostHog -->
<script>
!function(t,e){var o,n,p,r;e.__SV||(window.posthog=e,e._i=[],e.init=function(i,s,a){function g(t,e){var o=e.split(".");2==o.length&&(t=t[o[0]],e=o[1]);t[e]=function(){t.push([e].concat(Array.prototype.slice.call(arguments,0)))}}(p=t.createElement("script")).type="text/javascript",p.crossOrigin="anonymous",p.async=!0,p.src=s.api_host+"/static/array.js",(r=t.getElementsByTagName("script")[0]).parentNode.insertBefore(p,r);var u=e;for(void 0!==a?u=e[a]=[]:a="posthog",u.people=u.people||[],u.toString=function(t){var e="posthog";return"posthog"!==a&&(e+="."+a),t||(e+=" (stub)"),e},u.people.toString=function(){return u.toString(1)+".people (stub)"},o="capture identify alias people.set people.set_once set_config register register_once unregister opt_out_capturing has_opted_out_capturing opt_in_capturing reset isFeatureEnabled onFeatureFlags getFeatureFlag getFeatureFlagPayload reloadFeatureFlags group updateEarlyAccessFeatureEnrollment getEarlyAccessFeatures getActiveMatchingSurveys getSurveys getNextSurveyStep onSessionId".split(" "),n=0;n<o.length;n++)g(u,o[n]);e._i.push([i,s,a])},e.__SV=1)}(document,window.posthog||[]);
posthog.init('YOUR_API_KEY', {api_host: 'https://app.posthog.com'})
</script>
Server-Side Proxy for Plausible (Nginx)
If you want to reduce script-blocking by ad blockers, routing Plausible through your own domain is the most practical approach. An Nginx proxy configuration looks like this:
# Nginx configuration for Plausible proxy
# Add to your server block
location /js/script.js {
proxy_pass https://plausible.io/js/script.js;
proxy_set_header Host plausible.io;
proxy_ssl_name plausible.io;
proxy_ssl_server_name on;
proxy_buffering on;
expires 1d;
add_header Cache-Control "public, max-age=86400";
}
location /api/event {
proxy_pass https://plausible.io/api/event;
proxy_set_header Host plausible.io;
proxy_ssl_name plausible.io;
proxy_ssl_server_name on;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_buffering off;
}
Then update your script tag to point to the proxied path:
<script defer data-domain="yourdomain.com"
data-api="/api/event"
src="/js/script.js">
</script>
Custom Event Tracking for SEO Engagement Signals
For tracking scroll depth as an organic engagement signal across Plausible and PostHog (the two tools where this is most useful for SEO correlation work):
// Universal scroll depth tracker — works with Plausible and PostHog
(function() {
var milestones = [25, 50, 75, 90];
var reached = {};
function getScrollPercent() {
var h = document.documentElement;
var b = document.body;
var st = 'scrollTop';
var sh = 'scrollHeight';
return (h[st]||b[st]) / ((h[sh]||b[sh]) - h.clientHeight) * 100;
}
function trackMilestone(pct) {
var label = 'Scroll ' + pct + '%';
// Plausible
if (typeof plausible !== 'undefined') {
plausible('Scroll Depth', {props: {milestone: label}});
}
// PostHog
if (typeof posthog !== 'undefined') {
posthog.capture('scroll_depth', {
milestone: label,
page_path: window.location.pathname,
traffic_source: document.referrer
});
}
}
window.addEventListener('scroll', function() {
var pct = Math.floor(getScrollPercent());
milestones.forEach(function(m) {
if (pct >= m && !reached[m]) {
reached[m] = true;
trackMilestone(m);
}
});
}, {passive: true});
})();
My Framework for Choosing: SALT
After four months of parallel testing, I needed a way to communicate tool recommendations to clients without walking them through a 3,000-word evaluation every time. I built a framework I call SALT.
S — Sovereignty. Who owns the data? Can you export it, delete it, take it with you? Does the vendor's business model create incentives to monetize your data in ways you haven't fully understood?
A — Accuracy for your specific use case. Not accuracy in the abstract, but accuracy for the questions you're actually asking. Plausible is highly accurate for landing page source breakdown. Less so for funnel analysis. PostHog is highly accurate for event-level behavior. Less useful if you need fast, at-a-glance traffic comparisons without configuration.
L — Latency to insight. My most consistent finding across this evaluation was that the tool people actually use is the fast one, not the comprehensive one. Fathom gets checked because it loads in two seconds and the answer is on screen. GA4 does not get checked because the path from question to answer is too long and too uncertain. Latency to insight is a real operating cost that almost nobody puts in their comparison spreadsheet.
T — Team fit. Who is reading these reports? A technical SEO who wants SQL access needs a different tool than a content manager who needs to know whether a blog post is getting organic traffic. Matching tool complexity to team capability is not dumbing things down; it's ensuring that the tool creates insight rather than confusion.
I use SALT to score each client situation before making a recommendation. High sovereignty need + technical team + high traffic = Matomo self-hosted. Low sovereignty concern + non-technical client + content focus = Fathom. Growth-stage team that wants SEO and product data in one place = PostHog. The rest, which is most cases, lands on Plausible.
Two Things Nobody Wants to Hear
Contrarian Take 1: GA4 Is Not the Problem. Your Reporting Process Is.
I realize this undermines part of my argument for leaving GA4, so let me be precise. GA4 has real problems: the data model is opaque, the interface is slow, the session definition creates misleading comparisons with historical data, and the sampling at high traffic volumes produces reports that feel authoritative but aren't. These are genuine flaws.
But I've watched teams solve the wrong problem by switching tools. They move from GA4 to Plausible, find that Plausible is simpler, and conclude that their reporting has improved. What has actually improved is the experience of looking at a dashboard. The underlying question, "what is our organic traffic doing and why," is still being answered with roughly the same depth. The problem was never the tool. It was the absence of a reporting cadence that forced regular engagement with the data.
The best analytics tool is the one embedded in a process. Not the one with the best features.
Contrarian Take 2: Privacy-First Analytics Is a Marketing Claim, Not a Technical Guarantee.
Plausible, Fathom, and Matomo all market themselves on privacy. And in relative terms, they are more privacy-respecting than GA4. But "no cookies" and "no cross-site tracking" do not mean "users are anonymous." Plausible's fingerprinting method, which the company has published documentation about, hashes IP address + user agent + a daily salt to produce a unique visitor count. This is not surveillance-level tracking, but it is also not invisibility. A determined entity could potentially correlate that data with other sources.
I'm not saying don't use these tools. I use them and recommend them. I'm saying that the privacy marketing language creates a false binary between "Google Analytics = bad privacy" and "alternative tools = pure privacy." The reality is a spectrum, and different client contexts require actually reading the data handling documentation rather than trusting the marketing copy.
My Admitted Mistake
I deployed Matomo for a client in early 2025 and told them it was "essentially zero cost" because self-hosting was included in their existing server setup. Six months later, I had spent approximately 14 hours on Matomo infrastructure issues: a database that needed index optimization after a traffic spike, a plugin compatibility issue after a Matomo version update, and a caching configuration that was causing sessions to undercount. If I had charged my actual hourly rate for that time, Matomo would have been the most expensive tool in this comparison by a significant margin.
I did not account for ongoing maintenance time when I made the initial recommendation. I should have. I now include an explicit infrastructure overhead estimate in any proposal that involves self-hosted analytics.
Where I Land in May 2026
My own sites run Plausible. Most of my clients are on Plausible or Fathom, depending on how frequently they want to engage with their data and whether they have technical staff who will explore beyond the default dashboard. Two clients are on Matomo self-hosted and will stay there because data sovereignty is a genuine operational requirement, not a preference. One client is on PostHog because their product and growth teams insisted, and the SEO reporting has been good enough that I've stopped wishing for something else.
I still have GA4 access on most client accounts. Not because I rely on it, but because it's still where certain stakeholders feel comfortable, and Search Console integration continues to make it the path of least resistance for keyword data. Removing it entirely is a conversation I have selectively, when the cost of maintaining dual instrumentation outweighs the comfort it provides.
The broader shift in 2026 is that this choice is now genuinely mainstream. Two years ago, recommending against GA4 felt contrarian enough to require justification. Now, the default assumption among sophisticated digital teams is that GA4 is one option among several, not the automatic answer. That is a real change, and the tools in this comparison deserve credit for making it possible.
If you're starting fresh today, on a new site with no legacy data dependencies and no client who has memorized the GA4 interface, there is no compelling reason to begin with GA4. Start with Plausible, add PostHog if your team is ready for event-level depth, and revisit Matomo only if you reach a scale or compliance context that actually requires it.
For further reading on the technical implementation side, this guide to analytics setup for SEO-first sites covers the full tracking plan I use for new client onboarding. For the question of how analytics data feeds into content strategy, the workflow I use to connect traffic data to content decisions covers that process in detail. On the technical compliance side, current guidance on GDPR-compliant analytics in 2026 is the right follow-on read if the privacy discussion above raised practical questions. The Plausible blog's comparison post is worth reading as a counterpoint, with the caveat that it is written by a party with an obvious interest in the outcome. The Matomo team's GDPR analysis is the most technically detailed public resource on this topic and is worth the time if you're navigating EU data regulations.
The decision is yours. The data is yours. That's the whole point.
