One visit. A whole journey.
From your visitor’s browser to your analytics dashboard. Scroll to follow a pageview through Fathom.
Jump to the full technical explanation ↓Follow one pageview
First stop: your website.
A visitor in France.
Let’s follow someone browsing from France, as an example of an EU visitor. Their first stop is your website.
A visitor opens your website.
Someone opens a page on your website. The Fathom script on that page sends a pageview request to Fathom. Follow that request through the next steps.
The pageview reaches Fathom in the EU.
The pageview reaches Fathom’s EU infrastructure and is anonymized before it’s sent to the US. A quick change of clothes, and we’re ready to travel.
Next stop: Fathom in the US.
Already anonymized in the EU, the pageview goes through a second layer of anonymization on Fathom’s US infrastructure. Apparently one disguise wasn’t enough.
The anonymized visit is stored.
We store the anonymized visitor hash alongside the pageview details in our analytics database. These records power the reports you see in your dashboard.
The picture comes together.
You see which pages people visit and where traffic comes from. Duration and bounce information complete the picture, without cookie banners.
The full data journey
The walkthrough is an overview. Here’s the detail of what we process, how we protect it, and what we store.
Fathom turns requests from your website into useful analytics without setting analytics cookies or building a visitor profile across unrelated sites. Here’s how an ordinary pageview becomes a report on your dashboard.
1 Loading the script and sending a pageview
Our script is delivered through a content delivery network. When someone visits a tracked page, it sends the site identifier, hostname, path, referrer, and relevant query parameters. The incoming HTTP request also carries an IP address and user-agent information.
The script supports ordinary page loads and single-page application navigation. A configured event sends a separate request.
2 Regional routing
EU isolation provides a separate route for EU visitor traffic. The collector recognizes requests forwarded by the isolation proxy and uses the country information supplied by that proxy instead of performing its normal IP geolocation lookup.
Regional processing and international transfers are explained further in our data isolation documentation and EU–US data transfer information.
3 Checking incoming traffic
Incoming requests are subject to security checks and the site’s configured firewall rules. These rules can cover pages, IP addresses, referrers, countries, and domains. Traffic classification also separates detected bots from ordinary analytics traffic.
Security processing has different needs from ordinary analytics. IP-based rate limiting and temporary blocking help protect the collection service against abuse.
4 Counting visitors without analytics cookies
The collector creates a SHA-256 visitor signature using the incoming IP value, user-agent information, the site identifier, and a daily salt. The salt rotates at midnight UTC. Hostname is also included when the site’s multi-domain settings require separate unique visitors for each domain.
The site identifier keeps signatures scoped to a site. Changing the daily salt changes the signature, rather than creating an identifier intended to follow someone indefinitely. A local reporting day can span two UTC salts, so that boundary can affect unique-visitor counts.
Salt rotation is not the same as deleting stored analytics records. Visitor signatures are stored with event records; those records are not automatically erased when the salt changes at midnight.
5 Storing analytics and building reports
Ordinary pageviews are written to our analytics database. Their fields include a timestamp, site identifier, visitor signature, page and referrer details, browser and device information, geographic information where available, and campaign parameters.
The ordinary analytics event record does not include dedicated raw-IP or raw-user-agent fields. Browser, device, and location fields are derived during request processing. Page URLs, referrers, and campaign parameters can contain information supplied by your website, so avoid putting personal information in URLs or tracking values.
Event timestamps retain seconds; they are not all rounded to the nearest hour. Reporting aggregates are built from the events, and a separate realtime store supports the current-visitors view.
6 Bot traffic
Detected bot traffic is stored separately from ordinary analytics. These records include an IP address and a limited set of classification information, rather than the full ordinary pageview record.
7 Measuring time and bounces
The browser attempts to send a departure ping when a page becomes hidden, is left, or is replaced by another tracked page. That ping reports elapsed time, capped at 30 minutes. Delivery is best-effort: a browser closing or losing its connection can prevent it from arriving.
The collector stores a separate departure event with the reported duration. It does not simply overwrite the original pageview or mark it as a non-bounce because a departure ping arrived. Bounce calculations use pageview counts in the reporting logic; a duration ping alone is not another pageview.
8 Explore the result
Your dashboard brings together pageviews, visitors, referrers, campaigns, and other reports. The animated walkthrough above simplifies the ordinary pageview path. Detected bot traffic is handled separately.
For questions about processing or privacy, contact us or read our privacy information.