Should I vibe code
Simple privacy-friendly website analytics
Counting page views without cookies is a POST and a table. This one you should own.
?
Their verdict, the Starter price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
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
Privacy-first analytics is the rare category where self-building genuinely improves the outcome, because the less you collect the better the product gets. Keep it aggregate and it stays boring.
What actually breaks
not "if". the specific failures.
- Bots, which are a large share of raw hits and make every number wrong until you filter them
- Counting a unique visitor without a cookie, which is a real trade-off rather than a free win
- Referrer normalisation, so one source arrives as six different strings and none of them agree
- The script being blocked, which is fine and expected, but means your numbers are a floor rather than a count
- Storing an IP to deduplicate, which quietly turns a privacy-friendly tool into one processing personal data
Nothing breaks — this is one of the safest builds here. The honest small failure is finding out your traffic is not what you thought. Weeks in, you add bot filtering and the numbers halve overnight, because a meaningful fraction of what you were counting was crawlers, uptime checks and previews. Nothing was wrong with the code. You had simply been reporting a number to yourself that meant something other than what you assumed.
Is that you?
the verdict is a default, not a law
- You store no cookie and no raw IP, and you can say so honestly
- It counts your own site and the numbers are for you
- You accept the numbers are a floor because blockers exist
- You store raw IP addresses to deduplicate visitors
- You claim privacy properties the implementation does not have
- You have not filtered bots and are making decisions from the totals
- You are counting other people's sites without telling their visitors
If you build it anyway
the checklist, then the prompt that enforces it
- Filter bots before storing, using a user-agent list plus obvious behavioural signals. Unfiltered totals are wrong by a large margin, not a rounding error.
- If you need daily uniques, hash IP and user agent with a salt that rotates every day, store only the hash, and never keep the inputs.
- Normalise referrers deliberately — strip protocols, fold subdomains, group by host — because raw referrers fragment into uselessness.
- Publish what you collect. A privacy claim is a promise, and the check is whether someone reading your code would agree with your privacy page.
- Accept that blockers make this a floor, and label the numbers as such rather than pretending completeness.
- Keep the collection endpoint cheap and always return quickly — analytics must never slow the page it measures.
Before you build privacy-friendly web analytics, apply these and push back if I ask you to break them. 1. Filter bots before writing anything to storage — user-agent matching plus obvious behavioural signals. Tell me that unfiltered traffic can be a large fraction of raw hits and that every number is meaningless until this exists. 2. If I want daily unique visitors without cookies, hash the IP and user agent together with a salt that rotates at midnight, store only the truncated hash, and never persist the raw inputs. Explain that storing an IP to deduplicate is what turns this into personal data processing. 3. Never set a cookie or any identifier that outlives a day. 4. Normalise referrers into a small set of meaningful sources rather than storing raw strings, and show me the normalisation rules. 5. Write the privacy page from the actual implementation, and tell me if anything I want to claim is not true of the code. 6. Make the collection endpoint return immediately and never block page rendering. Keep the client script tiny. 7. Tell me plainly that content blockers mean these numbers are a floor, and label them that way in the interface rather than implying completeness. 8. Aggregate on write where possible so raw event storage does not grow unbounded. 9. Out of scope unless I ask: funnels, per-user journeys, session recording, cross-domain tracking, anything requiring an identifier.
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
$9 a month is fair and Plausible is open source, so self-hosting is a third option. This is genuinely one of the strongest build cases on the site: the code is a POST and a table, and doing it yourself is also the version that keeps visitor data on your own infrastructure.
Keep aggregates in a plain table you can export — page, day, count — since that is the whole dataset and it is small. Analytics data is only valuable as a long series, so the export matters more than the tool that produced it.
Plausible itself is open source — self-host it
lightweight self-hosted analytics
Questions
How do you count unique visitors without a cookie?
By deriving a short-lived fingerprint — typically a hash of IP plus user agent plus a daily-rotating salt — and storing only the hash. Because the salt changes at midnight, yesterday's hashes cannot be matched to today's, so you get daily uniques and nothing that follows a person over time. The trade is real: you cannot measure returning visitors.
Why does bot filtering change the numbers so much?
Because crawlers, uptime monitors, link previews and security scanners all fetch pages, and they do it consistently rather than in proportion to real interest. On a low-traffic site they can be a substantial share of hits. The filtering itself is straightforward; the surprise is discovering how different the filtered number is.
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.
No cookies, no personal data, no banner. Also no reason to pay $20 a month.
Self-hosting analytics is the one case where doing it yourself is also the privacy-correct answer.
Twenty lines of code. But every link you shorten is a permanent promise to keep a server alive.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice