I've been evaluating Fathom Analytics for the past several weeks, specifically to assess its capabilities for conversion funnel analysis on a mid-sized e-commerce platform. While it's excellent for its core purpose of privacy-focused, simple traffic analytics, using it for funnel analysis requires a significant shift in approach compared to dedicated product analytics tools like Amplitude or Mixpanel.
The primary challenge is that Fathom does not track individual users or sessions natively in a way that can be stitched into a funnel sequence. Its data model is centered around aggregated pageviews and events. To construct a funnel, you must rely entirely on custom, defined events and use their "Goal" feature creatively. A funnel step must be modeled as a Goal, and the conversion rate is then calculated from one Goal to another.
Here is a simplified example of the event structure required to track a three-step checkout funnel:
```javascript
// Step 1: 'Add to Cart' - Triggered on button click
fathom.trackGoal('H2CK5MSJ', 0); // Cart Addition
// Step 2: 'Initiate Checkout' - Triggered on reaching checkout page
fathom.trackGoal('LKJB9SAQ', 0); // Checkout Start
// Step 3: 'Purchase Complete' - Triggered on order confirmation
fathom.trackGoal('XCVB8NHT', 0); // Purchase
```
Once these Goals are established, you must manually analyze the funnel by:
* Creating a dashboard for each Goal to see its total conversions.
* Using the "Goal Conversions" report to see the pages where conversions happened.
* Manually correlating the drop-off between steps by comparing the conversion counts across different reports, as there is no single funnel visualization that shows step-by-step attrition in real-time.
**Key Trade-offs and Considerations:**
* **Data Granularity:** You lose the ability to analyze the *path* a user took between funnel steps. You only know that a certain number of people triggered Goal A and a subset later triggered Goal B, but not the sequence or time elapsed for individuals.
* **Attribution Complexity:** Analyzing funnel performance by referrer, campaign, or entry page becomes a multi-report exercise, requiring you to filter each Goal's report individually and cross-reference.
* **Positive Aspects:** For teams prioritizing privacy and simplicity, this approach avoids collecting personal data. The performance impact is negligible, and the data is in your own dashboard immediately, without sampling.
* **Workflow Impact:** This method is manageable for stable, well-defined funnels (e.g., a core checkout flow). It is not suited for exploratory, ad-hoc funnel creation or for analyzing highly branched user journeys.
My conclusion is that Fathom can be used for basic, high-level funnel conversion tracking if you are willing to invest in precise event instrumentation and accept a manual, report-based analysis workflow. It is not a turnkey funnel analysis tool. The suitability hinges on your need for depth versus your constraints on privacy, performance, and infrastructure simplicity.
I'm interested to hear if others have attempted this and what patterns you've developed for querying or visualizing this data more effectively, perhaps by leveraging Fathom's API to build external reports.
brianh
Your point about stitching sessions is the core issue. Fathom's aggregated model means you can't track drop-offs between steps for the same user, only total volume differences between your custom goals.
That makes it useless for analyzing the actual path a user takes. You'll see "100 people added to cart" and "50 people started checkout," but you have no idea if they're the same 50 people. For any serious funnel debugging, you need that session continuity.
If you're already committed to Fathom for its privacy stance, you're basically building the funnel logic yourself outside the tool. You'd have to push all those events to your own data store and rebuild the session there. At that point, you're paying for Fathom but doing the heavy lifting yourself.
Build once, deploy everywhere
Exactly right, and that's why the privacy-first architecture necessitates a fundamentally different data layer. The critique that you're "paying for Fathom but doing the heavy lifting yourself" is valid, but it's worth framing this as a conscious architectural choice rather than a shortcoming.
If you're committed to this model, the logical step is to treat Fathom as a collector and aggregator of anonymized *signals*, not as your system of record. The "heavy lifting" then moves to a pipeline: Fathom's webhook pushes events to a serverless function which enriches and stitches sessions in a privacy-compliant data store (like a partitioned BigQuery table or ClickHouse), using only a temporary, server-side session ID.
The real cost isn't the labor to build this, it's the ongoing operational complexity versus a unified tool. You're trading off a monolithic analytics service for a modular system you now have to monitor, secure, and maintain.
infrastructure is code