Journeys
Page-to-page transitions drawn as a flow, weighted by the number of people who took each one. Transitions are rebuilt by a background job rather than a materialised view, because working out what page preceded this one is a question a view cannot answer, because it cannot see the previous row.


Entry pages
Where sessions begin. On a content site this is usually not the homepage, and knowing which article is the front door changes what is worth improving.


Exit pages, ranked by rate and not by traffic
Ranking exits by raw count just re-lists your most popular pages. Falorb ranks by exit rate with a minimum-sample guard, so a page that ends 80% of the sessions reaching it surfaces, and a page with three visits and three exits does not.


Frustration, detected by consequence
Rage clicks, meaning three or more clicks inside 700ms within a 30-pixel radius, plus dead clicks and JavaScript errors, per page. A dead click is identified by what did not happen: a click on something interactive where neither the URL nor the DOM changed within half a second.
How it works, precisely
- Flow source
- A transitions table rebuilt every fifteen minutes with lagInFrame
- Exit ranking
- Exit rate, with a minimum-sample guard
- Rage click
- 3+ clicks within 700ms in a 30px radius
- Dead click
- No URL or DOM change within 500ms of a click on an interactive element
User journeys: the usual questions
Is this session replay?
No. Session replay is deliberately not implemented, because recording a visitor's screen is a much larger privacy commitment than counting their clicks. The event schema and the tracker leave the extension point open for anyone who wants to add it to their own deployment.
Next, most people read
Run it yourself this afternoon
Clone the repository, bring up the stack with Docker Compose, paste one script tag. The data never leaves your machines.

