Alright, let's talk about something the Fathom sales deck doesn't highlight: its uncanny ability to completely trash your lead scoring by vacuuming up your own team's internal pageviews.
I was all-in on their "AI-powered conversation intelligence" for sales calls. Great. But then I noticed our "top engaged leads" were suddenly populated by... our own devs and product managers. Turns out, every time someone logged into our admin panel, staging site, or internal tooling with the Fathom snippet installed, it was counting as a high-intent visit. Our sales team was getting alerts about "hot" leads that were literally employees in another department.
So, here's the quick and dirty fix I had to implement to stop poisoning our own data. Fathom's docs have a section on this, but it's buried.
First, I added a custom JavaScript variable to our internal environments. On our staging and internal tool subdomains, we set a cookie or a data attribute like `window.isInternalUser = true`.
Then, in the Fathom snippet, I wrapped the tracking logic. The basic idea:
```javascript
if (!window.isInternalUser) {
// Your standard Fathom snippet load logic goes here
}
```
Alternatively, you can use Fathom's built-in `excludedDomains` config if your internal tools live on separate subdomains (e.g., `tools.yourcompany.com`). Just add them to the exclusion list in your site settings.
But here's the kicker—this isn't just about subdomains. If your team accesses your *public* site for testing or content updates (like your marketing team previewing a blog post), you'll need that JS logic to block tracking based on their login status or a specific tag. Otherwise, you're still inflating your own metrics.
The bottom line? Fathom, like most of these tools, is dumb. It tracks everything unless you explicitly tell it not to. If you're using it for sales intelligence, setting up these filters isn't a nice-to-have, it's step zero. Otherwise, you're paying for insights that are, frankly, fictional.
Just my 2 cents.
Trust but verify.
That's a solid client-side approach for immediate relief. I've had to implement similar filters at the network layer for larger teams where script modifications can slip through the cracks. Consider adding a Cloudflare Worker or a similar edge function that injects a custom header for all traffic coming from your office IP ranges or your VPN's CIDR blocks. You can then extend your conditional logic to check for that header. It provides a secondary enforcement mechanism that doesn't rely on every internal app being correctly configured.
Your method is excellent for known subdomains, but the edge approach catches shadow IT or temporary staging URLs your team might spin up without the proper snippet guard. It also neatly handles the scenario where an internal user has locally disabled cookies, which would bypass your `window.isInternalUser` check.
Mike