Clicky

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me web analytics that replaces Clicky: real-time, with the session trail of each visitor, on my own machine and without a cookie.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- A tracking script under 3KB gzipped, from my own domain
- Server-rendered dashboard, charts as inline SVG drawn by hand
- Caddy in front

THE DATA MODEL
- sites: id, domain, name, timezone, salt, is_public
- events: id, site_id, session_id, kind, path, query, title, referrer_host, referrer_url, utm_json, country, region, lang, device, browser, os, screen_bucket, duration_ms, status, bot, visitor_hash, created_at
- sessions: id, site_id, visitor_hash, started_at, last_seen_at, entry_path, exit_path, event_count, is_bounce, country, device, referrer_host
- goals: id, site_id, name, kind, config_json — a path, an event name, or a value threshold
- conversions: id, goal_id, session_id, value_num, created_at
- Everything is an event. A page view, a click, a form submission and a goal are one table with a kind, because a new signal must be a new value and never a migration

IDENTITY WITHOUT A COOKIE
- visitor_hash is HMAC-SHA256 of address, user agent and a per-site salt that rotates daily. Nothing is written to the visitor's browser
- The daily rotation means a visitor cannot be followed across days, which is the honest trade: 'unique visitors today' is exact, 'unique visitors this month' is an estimate and the dashboard says so where the number is shown
- A session is the same visitor hash with under thirty minutes between events
- No cookie, no localStorage, no fingerprint beyond that hash, nothing sent anywhere else. Write this on a page the site's own visitors can read

THE REAL-TIME PART, WHICH IS THE PRODUCT
- A live view: sessions active in the last five minutes, each with its trail — the pages in order, with the time on each
- Updated by polling a small endpoint every few seconds with an ETag, on a backoff when the tab is hidden. Not a socket per dashboard viewer
- The live set is kept in memory and rebuilt from the database on boot, so the hot path is not a query over the archive
- Clicking a session opens its trail: entry, every page, referrer, country, device, and the goals it hit

BOTS, WHICH DECIDE WHETHER THE NUMBERS MEAN ANYTHING
- Flag, never drop. A bot row is recorded with bot = 1, and every published figure excludes it through a view rather than through a filter repeated in fifteen places
- Detection: a user agent list, plus the stronger signal that the tracking script runs at all, plus behavioural marks — no referrer, one page, zero time, and a request pattern too regular to be a person
- The dashboard can show bot traffic deliberately, because 'how much of that spike was a crawler' is a real question
- Prefetches and prerenders are marked from the request headers and kept out of page views. Two refreshes must not produce six views

WHAT IT REPORTS
- Views, visitors, sessions, bounce rate, time on page, pages per session — each with its definition written next to it, because everybody computes these differently and a number without a definition is decoration
- Top pages, referrers with the full URL kept so 'which thread on which forum' is answerable, countries, devices, browsers, operating systems, screen sizes, languages
- Entry and exit pages, and the paths people take between them
- Goals with conversion rate and value
- Any figure segmentable by any dimension: this is a WHERE clause, and it should never be a second query written by hand
- Comparison against the previous period, always

BEYOND PAGE VIEWS
- Outbound link clicks, file downloads and form submissions tracked automatically by the script
- Custom events with a name and an optional number
- Optional heatmap: click coordinates bucketed by a grid at a normalised width, per page. Store buckets, not coordinates
- Uptime checking of the site itself from the same box, since the schedule and the alerting are already there

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, HASH_SALT, GEOIP_DB_PATH, SESSION_SECRET
- Migrations on boot, each once
- Country from a local database file. Never an external geolocation API
- The collect endpoint answers 204 immediately and writes after responding
- Nightly backup off the machine, restore script
- Health endpoint

WHAT MATTERS MOST
The bot flag and the definitions. Build the collect endpoint, the flagging and the excluding view before the dashboard, then compare a week against the server's own access log. Analytics you cannot defend a number from are worse than none — and if these numbers are ever quoted to anyone, they have to be numbers you can explain in a sentence.

Give me the repository, the tracking script, migrations, .env.example, a seed of a week of shaped traffic, and a README with deploy steps behind Caddy.