Should I vibe code
Collect cookieless page views and custom events with compact dashboards
Cookieless analytics is one salt away from a permanent visitor ID. Rotate it at midnight and never write it down.
?
Their verdict, the Standard price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Pirsch is small on purpose and that is what makes it a good build: a collection endpoint, a rollup table, a handful of charts. Its own engine is published as an open-source Go package, so the part everyone gets wrong is available to read rather than guess at. The thing to understand before you start is that "cookieless" is not a feature you turn on, it is a constraint you have to keep. There is no cookie because there is no stored identifier — instead a visitor is a truncated hash of address, user agent and a secret salt that is thrown away at midnight. That salt is the entire boundary between an aggregate statistics table and a re-identifiable record of who read what. Keep it in an environment variable that never changes, or let it into a backup, and you have quietly built the persistent identifier your privacy page says you do not have. Everything else here is ordinary engineering, and the ordinary engineering is worth doing.
What actually breaks
not "if". the specific failures.
- The salt, the first time it lands in a config file, an env var that never rotates, or a database dump — at which point every hash in the table is linkable across months
- The raw IP address, which in Pirsch's server-side integration model passes through your own request handler and therefore through your access logs and your error reporter
- The unique-visitor number, which under a daily-rotating hash cannot be summed across days and will be summed across days by whoever builds the monthly chart
- The series, the first time a schema change makes migrating two years of rows look more expensive than starting fresh
- The collection endpoint, which is a public POST that writes to your database and takes exactly one curl loop to fill with invented traffic
- A tracking call that stops firing after a routing change, so the flat fortnight in the chart is a deploy rather than a quiet fortnight
- The privacy page, which is a set of claims about code that keeps changing after the page was written
Is that you?
the verdict is a default, not a law
- The salt rotates on a schedule and exists nowhere but memory — no config file, no backup, no log line
- It counts your own sites, and the numbers are for you
- Daily rollups are backed up somewhere you have actually restored from
- No raw IP address is written to any store, including the ones you did not think of as stores
- You want month-over-month unique visitors, which needs an identifier that outlives a day and takes the consent exemption with it
- The events table and the application logs live on the same box under the same retention
- There is one copy of the aggregate table and nobody has tried restoring it
- You are counting visitors to sites that are not yours without those visitors being told
If you build it anyway
the checklist, then the prompt that enforces it
- Rotate the salt at midnight and discard the old value. It should be impossible to recover yesterday's salt from anywhere in your infrastructure, including backups.
- Hash and drop the IP address in the first few lines of the request handler, before any logging middleware sees it. Server-side tracking means your application is the collector, and your application already logs a lot.
- Aggregate into daily rollups on write, and apply retention only to the raw events. The rollups are the asset that cannot be recreated.
- Refuse to build any metric that requires identity across days. If the product needs it, it needs consent, and that is a different product.
- Rate-limit the collection endpoint per address and cap the size of custom event payloads. Nothing stops a stranger writing to it.
- Strip query strings from stored paths or allowlist parameters explicitly — password reset tokens and email addresses live in URLs.
- Alert on zero events for an interval that would be abnormal for your traffic, because a broken tracker and a quiet week are the same picture.
- Write down which country the data sits in. Pirsch sells German hosting as part of the product, and if you self-host, your answer is whichever region you clicked.
I am building cookieless web analytics for my own sites. The product claim is
"no cookie banner", and that claim is a property of the code rather than the
README. Build in this order, and push back when I ask for something that breaks
it.
1. Settle the visitor-identification scheme before anything else: hash address
plus user agent plus a secret salt, truncate, store only the truncation.
2. Rotate the salt at midnight and discard the previous value. Never persist a
salt, never log one, never let one into a backup — a salt that survives the
day turns the dataset into a re-identifiable record of individuals.
3. If I ask for cross-day uniques, monthly cohorts or per-visitor journeys,
refuse and explain that all three need a durable identifier, which is the
thing the whole no-banner position depends on not existing.
4. Write no raw IP address anywhere: not the events table, not the access log,
not the error reporter. Hash at the top of the request handler and drop the
address before any middleware runs.
5. Roll up into daily aggregates on write and keep them separate from raw
events. Retention deletes raw events; the rollups are permanent.
6. Build the backup and the restore script before the dashboard, and tell me to
run the restore into a scratch database before I trust any number.
7. Version the schema and migrate history forward with every change. Refuse to
solve a schema problem by truncating.
8. Strip query strings from stored paths, or allowlist parameters explicitly.
9. Rate-limit and size-cap the collection endpoint, and treat every field in a
custom event as hostile input. It is a public POST into my database.
10. Alert me when no events arrive for an interval I choose. A tracker broken
by a deploy renders identically to a quiet week.
11. Generate the privacy page from the implementation, and tell me whenever a
change I ask for makes a sentence on it untrue.
12. Out of scope unless I ask for it: funnels, A/B testing, the link shortener,
and any identifier that outlives a day.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Six dollars a month is the cheapest entry price in this category, and what it buys is somebody else being responsible for the salt rotation, the German hosting claim and the fact that your five-year graph still exists. If you would rather spend the weekend on your actual product, this is a genuinely easy subscription to justify. Build it if the exercise interests you or if the data needs to stay on your own infrastructure for reasons you can articulate.
Keep daily rollups — date, path, referrer group, country, count — in a plain table, and a cron that writes them to CSV. That file is the whole dataset, it is small enough to keep forever, and it is the only thing you cannot regenerate. The tracker itself is twenty lines you can rewrite in an afternoon on top of any store, so the migration you should be planning for is the data one, not the code one.
Pirsch's own server-side, no-cookie analytics engine, published as an open-source Go library — the hard part of this build is readable rather than guessable.
Popular open-source privacy-focused web analytics platform, and the most practical thing to self-host instead.
Open source and self-hostable, with the rollup and retention design already worked out.
Questions
Why is the salt such a big deal?
Because it is the only difference between two very different products. With a salt that changes every night, a returning visitor is a new row and the table is genuinely aggregate. With a salt that never changes, the same person hashes to the same value forever and you are holding a pseudonymous log of individual browsing history — which is the thing cookie banners exist for. The code looks identical either way. The difference is one cron job and a rule about backups.
Pirsch's engine is open source. Doesn't that make this trivial?
It makes the collection and aggregation trivial, which is most of the risk. What it does not give you is the dashboard, the multi-site management or the operational habit of keeping a database alive for five years. Vendoring the library is the smart move; the remaining work is boring and that is exactly why it gets skipped.
Server-side tracking sounds more private. Is it?
It dodges ad blockers, which is why people want it, and it moves the address into your own process, which is the part people forget. A JavaScript pixel posts to a vendor who has thought about IP handling. A server-side integration means your request handler, your logging middleware and your error reporter all see the full address by default. That is fixable in about four lines, but only if you write them.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
The dashboard is a weekend. The five-year graph is the product, and you get it only by never losing the table.
Counting page views without cookies is a POST and a table. This one you should own.
Self-hosting analytics is the one case where doing it yourself is also the privacy-correct answer.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice