We track no users. Here is what we track instead.
The analytics page for this site has six numbers on it. We built them from server logs and a single beacon ping per session. There is no cookie. There is no IP retention beyond seven days. No third party sees the visitor.
What we actually need to know
For a studio site like this, the questions worth answering are: are people landing on the homepage and reading more than the hero, which case studies hold attention, where do the contact-form clicks come from, and how often does the search box get used.
None of those questions require knowing who anyone is.
What the beacon sends
One POST per session, fired ~3s after page load: { path, referrer_origin, lang, screen_w, ts }. No user agent, no IP, no fingerprint, no UUID. The session is the page-view itself.
The data lands in a JSON-lines file (one append per request, no DB). Rotated monthly. Inaccessible from the web — the storage folder is Require all denied in .htaccess.
The analytics dashboard
A PHP script reads the JSONL, aggregates by day, and renders six numbers + a small bar chart. Auth is HTTP basic. The script never leaves the server.
The trade-off
We can't answer questions like "did this user come back?" or "what's the conversion path for visitor X?". We can answer questions like "is the homepage doing its job?" and "is the press kit reaching anyone?". For a studio site, the second set matters and the first set doesn't.
If we ever sell a B2C product where customer-level analytics matter, we'll add a consent-gated proper analytics platform. Until then: less is more, especially when "more" means "more of someone else's data".
FAQ
What does the analytics setup track if not users?
It tracks six numbers built from server logs and a single beacon ping per session, covering whether people read past the hero, which case studies hold attention, where contact-form clicks come from, and how often the search box is used. None of these require knowing who anyone is.
What data does the beacon actually send?
The beacon sends one POST per session roughly 3 seconds after load, containing path, referrer origin, language, screen width, and timestamp. It sends no user agent, no IP, no fingerprint, and no UUID.
How is the data stored and kept private?
Data is appended to a JSON-lines file with one entry per request, no database, rotated monthly, and made inaccessible from the web via Require all denied in .htaccess. A PHP dashboard reads the file, aggregates by day, and renders six numbers plus a bar chart behind HTTP basic auth, never leaving the server.
What can't this approach answer?
It cannot answer whether a specific user came back or trace per-visitor conversion paths, because there is no cookie and no identifier tying sessions together. It can answer whether the homepage is doing its job.
Would you ever use a different analytics approach?
Yes — if the studio ever sells a B2C product where customer-level analytics matter, a consent-gated platform would be added. Until then, the position is that less is more.