Modules
Web analytics for PhoenixKit sites, recorded by the server — who comes, where from, what they do, and when they leave.
Every change an operator can make to the module — settings, the tracking
switch, a manual retention pass, a salt rotation — in one place, each logged
to PhoenixKit.Activity with the acting user.
Tells the site's staff when something happens on the site — a visitor arriving, someone signing up, an event you care about — through PhoenixKit's notification system, so it reaches the in-app inbox, email, or Telegram with no per-project code.
Spotting automated visitors by what they do, not only by what they call themselves.
The write path: takes a raw hit, enriches it, and stores one
PhoenixKitWebAnalytics.Schemas.Event.
Settings-backed configuration for the Web Analytics module.
Optional behaviour for resolving a request IP to a coarse location.
Gettext backend for phoenix_kit_web_analytics — every string the module shows: admin pages, tab labels, notification text.
Everything a visitor does on a LiveView page, recorded server-side from the socket — no client-side script.
Who is on the site right now, and when they leave — from the LiveView processes themselves, with no client-side script.
Versioned migration coordinator for phoenix_kit_web_analytics — the module
returned from PhoenixKitWebAnalytics.migration_module/0.
Centralized path helpers for the Web Analytics module.
Records one page view per HTML response — the whole tracker, server-side.
Session recordings: how a visitor moved the pointer, what they clicked and hovered, how the page scrolled — enough to replay a visit over the page it happened on.
Turns a raw Referer header into a {source, medium} pair for reporting.
A short-lived cache for report results, so a busy site's admin pages don't re-run the same aggregates for every viewer and every refresh.
Read-side aggregation — every number the admin pages show.
Keeps the events table from growing without bound.
Route macros for the module's admin pages and two public collection
endpoints. Returned from PhoenixKitWebAnalytics.route_module/0; PhoenixKit
splices the admin routes inside its own live_session :phoenix_kit_admin
(auth + admin layout applied automatically) and the public ones near the top
of the host router.
One day of one breakdown value per site — "/pricing had 812 views from
640 visitors on 2026-09-30", "Google sent 212 views".
One day of pre-aggregated totals per site — what survives after raw events are pruned.
One analytics hit — a page view or a custom event.
One chunk of a session recording — a few seconds of one page view: where the pointer went, what was clicked and hovered, how the page scrolled.
A deliberately small User-Agent classifier: browser, OS, device class, and "does this look automated".
Cookieless visitor identification.
The optional client-side snippet — around 300 bytes, inline, no file to load.
Turns an untrusted beacon payload into a hit map for
PhoenixKitWebAnalytics.Collector.
The shared building blocks of the six report pages: the filter bar, stat tiles, the trend chart, and the ranked breakdown card.
Overview — the page you land on: headline numbers with period-over-period change, the traffic trend, and the breakdowns worth seeing first.
What visitors do — interactions (LiveView events, and the client script's clicks), custom events, and the live hit feed.
Shared period/site filter handling for the report LiveViews.
Right now — who is on the site this moment, and what they're looking at.
Pages report — every path that received traffic, with how long visitors stayed on it and how often they left the site from it, plus the response-time table that comes free with server-side tracking.
One visit, replayed — every page view, interaction, custom event and exit, in order, with the time since the visit began. The summary on top says who (a signed-in user's name, otherwise anonymous), where from, on what, and for how long.
Sessions — every visit in the period, newest first: who (a signed-in user's name, otherwise anonymous), where they landed and where they left, how many pages, how many actions, how long, and where they came from. Each opens the visit's full timeline.
Settings — what is collected, how long it's kept, which alerts go out, and the installation checklist.
Acquisition — where traffic came from: channels, referring sites, and UTM campaigns.
Technology — browsers, operating systems, device classes, languages, and (when available) countries.
Two optional client-side entry points, for the cases the plug can't see.