Pirsch Analytics

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 analytics that replace Pirsch: cookie-free, collected from my own backend so no blocker can interrupt it, with numbers I can defend.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- A tiny browser script for the client-side signals, and a server-side path that does not need it
- Server-rendered dashboard, charts as inline SVG drawn by hand
- Caddy in front

WHY SERVER-SIDE COLLECTION
- A browser script is blocked for a substantial share of visitors, and the share is highest among exactly the audience most technical products care about
- Recording the request on the server means the page view is counted whether or not any script runs. Nothing to block, nothing to load, no effect on page speed
- The cost is that you lose what only the browser knows: screen size, whether the page was actually rendered, engagement, and clicks. So collect both and be explicit about which number came from where

THE DATA MODEL
- sites: id, domain, name, timezone, salt, is_public
- pageviews: id, site_id, path, query, referrer_host, referrer_url, utm_json, country, lang, device, browser, os, screen_bucket, status, duration_ms, source, bot, prefetch, visitor_hash, session_id, is_entry, is_exit, created_at — source is 'server' or 'browser'
- events: id, site_id, name, path, value_num, meta_json, visitor_hash, bot, created_at
- goals, conversions
- Every row keeps how it was collected. A total that mixes two collection methods without saying so is a total nobody can reconcile

IDENTITY WITHOUT A COOKIE
- visitor_hash is HMAC-SHA256 of the address, the user agent and a per-site salt that rotates daily
- The address and the raw user agent are discarded immediately. Nothing is written to the visitor's browser
- The rotation means a visitor cannot be followed across days: 'visitors today' is exact, 'visitors this month' is an estimate, and the dashboard says so where the number appears
- A session is the same hash within thirty minutes
- The rotation is the fiddly part. Rotating at midnight in which zone, and what happens to a session that spans it? Decide, document it, and make sure a session is not split in half by the rotation — carry the previous salt for a grace period and match against both

THE SERVER-SIDE PATH
- A small library for your backend: called with the request, it extracts what it needs and records it after the response has been sent
- It must never delay a response and never fail a request. Fire and forget, with a bounded queue that drops rather than blocks
- Middleware for the common frameworks, plus a plain function for everything else
- Static assets excluded; API calls recorded with kind rather than dropped, because a vote or a signup is the most consequential thing a visitor does
- Or, with no code at all: parse the reverse proxy's access log. Slower to arrive, but it needs nothing in the application

BOTS, WHICH DECIDE WHETHER ANY OF THIS MEANS ANYTHING
- Server-side collection sees far more bot traffic than a script does, because a crawler that never runs JavaScript still made the request. This is the main thing to get right
- Flag, never drop, and exclude through a SQL view so the filtering lives in one place
- Signals: the user agent list, whether the browser script ever fired for that request, no referrer with one page and zero time, and arrival intervals too regular to be a person
- The script firing is the strongest humanity signal you have. Record it as a distinct field and use it deliberately
- The dashboard can show bot traffic on purpose, because 'how much of that spike was a crawler' is a real question
- Prefetches identified from request headers and kept out of the view count; redirects not counted; only a GET can be a page view

WHAT IT REPORTS
- Views, visitors, sessions, bounce rate, time on page, pages per session — each with its definition written beside it
- Top pages, referrers with the full URL kept, countries, devices, browsers, operating systems, languages
- Entry and exit pages, UTM parameters parsed out, and referrers grouped into sources with the grouping rules visible and editable
- Goals with conversion rates and values
- Everything segmentable by everything, always, with a comparison against the previous period

THE HONEST PART
- Say on the dashboard which figures come from the server alone and which need the browser
- If these numbers are ever shown to anybody else — a sponsor, an advertiser, a client — every one of them must be explainable in a sentence. A number you cannot defend is worse than no number

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
- Nightly backup off the machine, restore script
- Health endpoint

WHAT MATTERS MOST
Bot flagging and the salt rotation. Build server-side collection, the flag and the excluding view first, then compare a week against the raw access log and account for every difference. That reconciliation is the whole exercise.

Give me the repository, the backend library, the browser script, migrations, .env.example, and a README with deploy steps behind Caddy and the definitions written out.