Counting visits again: self-analytics ping restored

Today I put back into service a piece the redesign had quietly taken with it: the self-analytics ping for the panel. The script that notifies the server of every visit — the one pointing to /api/collect — was left out when we ported the previous website's design into this repo (bb4f9d8). Since then, the page_views table in the core had not stored a single visit.

A loss you can't see

It's the kind of failure that annoys me the most: there isn't a single error anywhere. The site looks perfect, posts publish, styles respond... and the analytics simply never arrive. The damage doesn't show up in the browser but on the server, in the form of data that stops existing. You can look at the homepage a thousand times and everything will seem fine.

The same mechanism, in the new place

The restoration was literal: the same mechanism from the original template, now inside the new BaseLayout.astro. An inline script picks up the gateway URL and sends a single ping per page view: route and query, referrer, and screen size. Nothing more, no cookies. The dirty work doesn't go through the browser: the server is the one filtering bots and admin routes.

To send it, sendBeacon as the first option — that's exactly what it's for, pings that mustn't get in the way of page exit — with a fetch using keepalive as a fallback for browsers that don't support it. The call goes to a same-origin relative URL against the gateway, so there are no third parties or cross-domain concerns to manage.

What I take away

When you carry over a new design, what you can't see doesn't move itself: an analytics script doesn't throw errors, it simply falls silent. It's worth every deployment carrying a smoke check that looks at whether page_views starts growing again. Today I fixed it by hand; next time I'd like the deployment itself to detect it.