SMF·PIRSCH
Can a prompt replace Pirsch?
Analytics — web and product analytics
Exhibit tracking slip
Verdict
Pirsch's real trick is that tracking does not have to happen in the browser. Count the request in your own backend middleware and there is no script to block, no cookie to consent to, and no third-party request at all. Implementing that is a middleware, a hashing scheme for sessions, and a dashboard, which is a solid weekend. What takes longer is doing the identification honestly — deciding who counts as a returning visitor without a cookie, and filtering bots from server logs that have no JavaScript check to lean on.
Exhibit A — The prompt
Received on31.07.2026Build a server-side web analytics system. No browser script by default.
Collection: a middleware for the user's own application framework that records a page view on every HTML response — not on assets, not on API routes, not on 3xx or 4xx. Ship it as a small library with an adapter for one framework and a documented interface for writing another. Record: path, referrer, user agent, accept-language, response status, and server timestamp.
Session identification without cookies: hash the visitor's IP address, the user agent, the site id and a salt that rotates every 24 hours. Store only the hash, never the IP. A visitor is the same across a day and unlinkable across days, which is what makes this work without consent in most regimes — and the rotation must be genuinely enforced, with the old salt destroyed rather than archived.
Bot filtering, which is the hard part without a browser to test. Layer three checks, and report how many hits each removed so the user can see what is being discarded:
- A user-agent list, loaded from a file the user can update, matched case-insensitively.
- A behavioural check: a session hash making more than a configurable number of requests per minute, or requesting only non-HTML paths, is reclassified as automated.
- A declared-crawler check for the well-known verified crawlers via reverse DNS, cached.
Dashboard: visitors, page views, sessions, bounce rate and average duration, by day; top pages, referrers, countries derived from a local IP-to-country database (loaded locally, never a lookup service), languages, and device class from the user agent. Date range comparison against the previous period. Everything filterable.
Custom events: a server-side function the application calls with an event name and optional properties — a signup completed, an order placed. These are more reliable than browser events precisely because they fire where the thing actually happened.
Optional browser script: a small script for the cases the server genuinely cannot see — outbound link clicks and scroll depth. Off by default, and the dashboard must show which metrics depend on it so the user knows what they lose by leaving it off.
Retention and export: a configurable retention period with a deletion job, raw event export as CSV, and a documented backup procedure.
Out of scope: session replay, heatmaps, funnels across sessions, cross-site identity, and any hosted multi-tenant deployment.Opening prefills the prompt — press enter to run it.
Exhibit B — What you lose
- B.1 hosted uptime and the guarantee that collection never stops
- B.2 the email reports and the public dashboard link
- B.3 bot filtering maintained against a constantly changing list
- B.4 scroll depth and click events, which genuinely do need a browser
Prior art
Exhibit C — Why people still pay: data pipeline reliability and analytical depth
Because six dollars is less than the hosting, and a vendor keeps the bot list current — which is the difference between traffic numbers you can act on and numbers inflated by crawlers.
Questions
Can I import my Pirsch data?
Pirsch exports statistics through its API, and aggregate daily figures can be loaded as historical rows so the charts have a past. Raw per-hit data is not exportable, so anything requiring re-aggregation stays where it is.
Do I still need a cookie banner?
This entry is not legal advice, and the answer depends on where your visitors are. What the design does is avoid the things that usually trigger the requirement: no cookie, no persistent identifier, no raw IP stored, and a salt that rotates daily so yesterday's visitors cannot be linked to today's. That is the same basis the privacy-first analytics products rely on.
What does it cost to run?
It runs inside an application you already host, so the marginal cost is the database. A million page views a month is a modest table. Against six dollars for the hosted plan, the saving is small and the control is the actual reason to do it.
What is the one thing that does not survive the rebuild?
The bot list. Server-side counting sees every crawler, and without a maintained filter your traffic numbers include a great deal of automation. A vendor updates that list constantly; your file goes stale the week after you write it, and the numbers drift upward without ever looking wrong.
Related tools
Receipt