Almost all web analytics works the same way. A page loads, a script runs, the script sends a request describing what happened. Everything about the product follows from that arrangement, including its two permanent blind spots.
Edge analytics moves the measurement to a different place: the request for the HTML, handled by code running at a CDN point of presence in front of your site. The page has not rendered. No script exists yet. The count happens because a request arrived.
What changes
Blocked scripts stop mattering
A browser extension can block a script. It cannot block the request for the page itself — that request is the page, and blocking it would mean the visitor does not see the site.
So a pageview counted at the edge is counted regardless of extensions, script errors, JavaScript being disabled, or the page being abandoned before scripts run. Your measurement gap becomes a number you measured rather than an industry estimate.
Crawlers become visible
This is the bigger one, and it is qualitative rather than quantitative.
A crawler does not execute JavaScript. It requests HTML and reads it. To a script-based analytics tool a crawler is nothing at all — not undercounted, absent. There is no configuration that changes this.
At the edge, a crawler request is a request like any other. You can see which AI crawlers read which pages, how often, and whether those pages send anyone back. This is not a better version of something scripts do badly; it is a category of information they cannot access.
Bot filtering gets better inputs
At the edge, a request arrives with network-level context — the address it came from, whether the claimed user agent matches a verified range, a reputation signal from the CDN. A page-side script sees none of that and can only guess from the user agent string, which is a string anyone can set to anything.
What does not change, and what gets worse
Being honest about the limits matters more than the advantages, because the advantages are easy to oversell.
Engagement time, scroll depth, rage clicks and Core Web Vitals still need the script. They are facts about what happened in the browser, and the edge never sees the browser. Edge mode does not replace the script; the two measure different things and a serious setup runs both.
Caching complicates things. If a page is served from cache without reaching your Worker, it is not counted. This is solvable but it is a real configuration concern.
You have to be in the request path. Which means your DNS on a CDN you control, and a Worker or equivalent in front of the site. If you cannot put code there, none of this is available to you.
It is genuinely more responsibility. Code in front of your website is code that can take your website down. Anything running there must fail open — if the analytics breaks, the page must still be served. That is a real engineering constraint, and it is the reason the pass-through has to forward to the origin first and count afterwards, never the other way round.
Why hosted analytics cannot offer this
Not because they have not got round to it. Because of where they run.
A hosted analytics product is somebody else's servers. For it to count your HTML requests, your traffic would have to pass through that vendor's infrastructure on its way to your visitors — which means they become a dependency of your website being reachable at all, not just of your reporting. Almost no vendor will take that liability, and almost no customer should accept it.
The arrangement only works when the analytics runs in your own infrastructure account, in front of your own site. Then the extra dependency is one you already had, and the blast radius is yours.
That is the actual reason this is a self-hosted capability rather than a feature list item, and it is the one structural advantage self-hosting has that is not about price or data ownership.
Running both at once
The useful configuration is both collectors, feeding one system, deduplicating a pageview seen twice.
The edge collector guarantees the pageview is counted. The script adds everything that can only be observed in the browser. And the difference between the two counts is itself a metric — the share of your traffic that the script alone would have missed, which is the number that tells you how wrong your old analytics was.
Common questions
What is the difference between edge analytics and server-side analytics?
Both count the request rather than the page, so both see blocked scripts and crawlers. The difference is where the code runs: server-side means your origin, edge means a CDN point of presence near the visitor. The edge version adds network-level bot signals your origin never sees and costs no origin CPU, but requires your DNS to be on a CDN you can run code in.
Does edge analytics replace the tracking script?
No, and any product claiming it does is overselling. Engagement time, scroll depth, rage clicks, custom events and Core Web Vitals are facts about what happened inside the browser, and the edge never sees the browser. The right configuration runs both collectors into one system and deduplicates a pageview seen by both.
Why can't Plausible or Fathom offer edge mode?
Because for a hosted vendor to count your HTML requests, your visitors' traffic would have to pass through that vendor's infrastructure — making them a dependency of your site being reachable, not just of your reporting. Almost no vendor will accept that liability and almost no customer should. It only works when the analytics runs inside infrastructure you already own.