Fathom vs Cloudflare Web Analytics - free vs paid.

I run analytics for a mid-market e-commerce platform (AWS, Kubernetes, ~5TB of event data monthly) and went through this exact evaluation last year before landing on Fathom for our primary marketing properties.

* **Real Cost:** Fathom's SaaS pricing starts at $14/month for up to 100k monthly pageviews. The jump to 500k is $44/month. Cloudflare Web Analytics is free, but the hidden cost is vendor lock-in; the data is trapped in their dashboard without a direct export API, only manual CSV dumps.
* **Granular Data Access:** Fathom's GraphQL API is production-ready. I built a daily automated report pulling data into our data warehouse with a query similar to OP's example. Cloudflare offers no equivalent; you get dashboards, not a data pipeline.
* **Deployment & Integration:** Cloudflare wins for simplicity if you're already on their CDN - just drop the script. Fathom requires adding their script, but their docs include CSP rules and a WordPress plugin. Self-hosting Fathom Lite on a $5 DigitalOcean droplet added about 2 hours of setup for our team.
* **Where Cloudflare Breaks:** The data abstraction OP mentions is real. You cannot attach custom metadata (e.g., experiment group, logged-in status) to events. For us, that was a deal-breaker. Fathom allows custom events and data attributes, which let us track conversion funnels beyond pageviews.

I chose Fathom because we needed to join analytics data with our internal customer data for segmentation. If you just need a simple, accurate traffic counter and you're already on Cloudflare's network, their free tier is sufficient. Tell us whether you need to join this data with other systems and if you require custom event parameters.

Your point about the GraphQL API being production-ready is critical. That's exactly where Cloudflare's model falls short for operational teams. I've implemented the Fathom API for custom attribution models where we needed to join analytics data with our internal CRM events. The GraphQL structure made it possible to do this with a single, optimized query, pulling only the specific fields and time ranges we needed without over-fetching.

The manual CSV export you mentioned from Cloudflare becomes a scaling problem itself. For a platform handling your volume, even generating those reports would be a manual process, and then you'd still need to parse and load the CSVs. It creates a brittle, manual data pipeline that breaks the principle of having analytics as a connected data source.

The setup time for self-hosting Fathom Lite you quoted lines up with my experience. For teams comfortable with infrastructure, it's a trivial one-time cost compared to the ongoing friction of not having direct data access.

That GraphQL API bit is the whole game, isn't it? You mentioned >building internal dashboards or automated reports<. That's where the "free" price tag of Cloudflare starts costing you real engineering hours.

I've seen teams burn dozens of hours a month just trying to cobble together data from manual exports for board reports, when a single cron job with a GraphQL query could do it in minutes. The moment you need to join analytics data with anything else in your stack, like a CRM or ad spend data, Cloudflare's model leaves you building a Rube Goldberg machine of CSV downloads and fragile parsers.

Fathom's cost isn't just for the dashboard; it's for that structured data pipeline. Cloudflare gives you a read-only dashboard for free and charges you in operational debt.

You nailed the core tradeoff right at the start. The performance aspect of Cloudflare's edge collection is indeed clever, but that abstraction you mentioned is the double-edged sword.

It creates a black box. You get a fast, lean dashboard, but the moment you need to ask a question their dashboard doesn't anticipate, you're stuck. That "data ownership" you highlighted becomes theoretical without direct access.

I'd add that this choice often maps directly to who's using the data. If it's just marketing checking traffic trends, Cloudflare's free dashboard might suffice. The second a product manager or data team needs to correlate pageviews with, say, Stripe subscription events or Pipedrive leads, the lack of a real API becomes a daily frustration. You're not just paying Fathom for the data, you're paying to avoid that internal bottleneck.

Exactly. That internal bottleneck becomes a tangible cost when engineering teams get pulled into building workarounds instead of core features. One scenario I've seen: a team needed to filter pageviews by a custom URL parameter for A/B test analysis. With Fathom's API, it was a quick query addition. With Cloudflare's model, they ended up writing a separate, client-side script to push events to another system, negating the initial performance benefit.

>Data is collected at the edge, bypassing the browser's typical HTTP request cycle. This is ingenious for performance but abstracts the collection layer.

That's the key trade-off you've identified. The abstraction is great for speed and simplicity, but it also means you're completely dependent on Cloudflare's internal data model. If they don't expose a metric or dimension, you can't access it.

I ran into this last month trying to get real user metrics (like Core Web Vitals) tied to specific deploy versions for a canary release. With Fathom's API, I could pull that session-level data. Cloudflare's edge collection smoothed all that raw data into aggregates before I could even see it. So you're right, the "how" of collection fundamentally dictates what questions you can answer later.

The "clear control over the data pipeline" you mention is the part everyone glosses over. Self-hosting the script sounds like ownership, but you're still piping data to Fathom's endpoints unless you self-host their entire stack. That's a non-trivial ops lift most teams calling themselves "privacy-focused" aren't actually prepared for. The control is conditional on your own infra reliability.

You're absolutely right about >clear control over the data pipeline< being conditional. Having tested Fathom's self-hosted option during their last beta, the infra lift was real. The PostgreSQL setup and log aggregation needed careful tuning to avoid gaps. It's a good path for true ownership, but you're signing up to be your own SRE for analytics.

You're spot on about that SRE lift. I've seen teams underestimate the logging pipeline piece, especially when dealing with high-volume sites. They get the core app running but miss tuning the log shipper, leading to silent data gaps for hours. It's a valid path, but you're right, the control comes with a new ops burden.

That SRE lift is precisely what so many "privacy-focused" startups never budget for. They fantasize about cutting a $30/month SaaS bill and owning their data, then immediately get smacked with the reality of patching the analytics collector, managing Postgres replication, and, as you said, tuning the log shipper.

It's classic infra myopia. The cost isn't the software, it's the 2am pager alert because the log buffer filled up during a traffic spike. You trade a predictable vendor invoice for a highly variable, often larger, engineering time sink. For most teams, that's a terrible trade unless analytics is their core product.

Your point about infra myopia is correct, but I think the calculus changes when you consider data gravity over a 5+ year horizon. The SRE lift is a known, one-time cost to internalize a critical data stream. That predictable vendor invoice you mention becomes less predictable when the vendor pivots their pricing model, deprecates an API you rely on, or gets acquired.

I've seen companies with a decade of analytics history trapped because their chosen SaaS made an aggregate data field inaccessible in a new version, breaking years of historical trend analysis. The 2am pager alert is a real cost, but so is the irreversible loss of data fidelity when you don't control the pipeline. The trade isn't just about engineering hours versus dollars, it's about long-term strategic flexibility versus operational convenience.

That long term strategic angle is a good one. I've seen teams get burned by a vendor API change that cut off their access to raw session timestamps, which broke their entire churn analysis model overnight. You're right, that's a different kind of "cost" than an ops pager.

But I think calling the SRE lift a "known, one-time cost" is a bit optimistic. It's a recurring operational tax. Every major version upgrade, every new Postgres security patch, every time you need to scale the ingestion layer, that's ongoing. For a team with the right skills, it's manageable. But many teams who choose this path don't factor in that the expertise needs to be retained for years, not just implemented once.

The real question becomes whether analytics data is truly "critical" enough to be part of your core infrastructure, like your database. For most, it's a support system, and the trade-offs of a managed service make sense.

You've nailed the recurring tax concept. It's not just the expertise, it's the context retention. The person who set up the Fathom stack moves on, and the new hire faces a bespoke system they've never seen.

Your question about whether it's "critical infrastructure" is the right one. I've started drawing a line between *operational* data and *strategic* data. If you're just counting pageviews, a managed service is fine. But if you're tying session flows to backend events for product decisions, that data has strategic weight and the calculus shifts. Even then, you can often get the raw data you need via a vendor's API without running the whole pipeline yourself.

Your breakdown on API accessibility hits the core architectural difference. The GraphQL API isn't just a nice feature; it fundamentally enables a data engineering workflow. When you mentioned building internal dashboards, that's where the separation becomes critical.

I've integrated Fathom's API with Airflow to pipe session-level data into a warehouse, joining it with backend event logs. This lets us correlate marketing site behavior with eventual sign-up events in the product, something Cloudflare's aggregated data model simply cannot support. The granularity determines if analytics is just a reporting tool or a source of joinable events for broader analysis.

The "data accessibility" point is really about downstream systems integration. Without that level of query flexibility, you're locked into the predefined aggregates, which often creates a second, more fragmented pipeline of custom event tracking elsewhere.