The next piece in the Junkdrawer/Labbox series is about analytics, but not analytics in the “please install this surveillance chandelier over your website” sense.
The itch was simple: I wanted a little bit of Google Analytics energy without the Google Analytics baggage. I wanted to know whether my little pages were being used, which pages were getting attention, what tools people were opening, and whether a prototype was quietly useful or quietly dead. But I did not want to leak data to the man, pull in a giant third-party tracking script, build an enterprise analytics pipeline, or turn every tiny web page into a privacy negotiation.
That is the recurring theme with this whole project: if the problem is small, the solution should be allowed to stay small. A Junkdrawer page does not need the same analytics stack as a billion-dollar ad platform. It needs enough signal to answer practical questions. Did anyone open the page? What route or page did they hit? Roughly when? From what referrer, if any? Maybe screen size, user agent, or a lightweight event name. Enough to understand usage. Not enough to build a creepy behavioral dossier.
So instead of bolting on a third-party analytics provider, the obvious move was to make Labbox do it.
Labbox already exists as the shared persistence layer for projects that outgrow pure browser-local storage. It handles the kind of boring backend work that should not be rebuilt for every little prototype: project scoping, data capture, image/file handling, tokens, and persistence. Analytics fits that same shape nicely. It is just another kind of project-scoped event stream.
The implementation idea is straightforward: add a new analytics endpoint and controller to Labbox. A Junkdrawer page sends a small event payload. Labbox receives it, validates it, attaches project context, timestamps it, and stores it. That is it. No grand analytics religion. No ten-service architecture. No Kafka cluster sobbing quietly in the corner because three people clicked a feral cat page.
A simple event might say: this project, this page, this event type, this timestamp, this path, this referrer, this user agent, this screen size, and maybe a small metadata object. That is more than enough for early-stage prototypes. The goal is not to know everything about the visitor. The goal is to know whether the tool is alive.
The JavaScript client is the other half of the pattern. Each page can include a small analytics helper that knows how to send events to Labbox. On page load, it can send a basic pageview. When useful, it can send explicit events such as “AI summary clicked,” “new sighting started,” “image uploaded,” “settings opened,” “export downloaded,” or “OpenRouter key saved locally.” The page decides what matters. The client just makes it easy to report.
That is important because not all pages need the same events. Weather Nerd might care about location changes, alert checks, and AI briefing runs. Wildlife Field Recorder might care about sighting submissions, photo attachments, and trip-log sessions. Top Hat Ferals might care about public page views, profile views, image uploads, and admin capture activity. The OpenRouter helper page might care about whether people read the instructions or click through to create a key. A one-size-fits-all analytics product would either over-collect or under-explain. A tiny project-aware client can stay focused.
The dashboard then becomes the payoff. Once Labbox is receiving events, it can show a simple analytics view: page views, event counts, recent activity, project breakdowns, top pages, event types, maybe day-by-day usage, and enough filtering to answer “what is happening?” without pretending to be Adobe Omniture’s deranged cousin. The dashboard does not have to be fancy to be useful. It just has to make the invisible visible.
The access model also follows the same Labbox philosophy: use a shared secret where that is enough. Not every internal dashboard needs a full user system, OAuth dance, invite flow, password reset page, and compliance cosplay. If this is a small private dashboard for a small set of pages, a shared secret can be the right level of security. The secret gates write access or dashboard access. It is not perfect. It is not meant to be perfect. It is meant to be appropriate for the scale and risk of the project.
That is the line I keep coming back to: if it does not have to scale, it does not need to be complex.
People say “it won’t scale” like it is always an insult. But most things do not need to scale yet. Some things will never need to scale. And that is fine. A tiny analytics system for a cluster of personal prototypes does not need to handle a Super Bowl ad campaign. It needs to help me understand whether anyone is using the thing I built and which parts are worth improving.
That does not mean being sloppy. It means being proportionate. The events should be minimal. Sensitive data should not be collected. The endpoint should validate inputs. The dashboard should be protected. The client should be small. The data should be scoped by project. The whole thing should be understandable by one person who comes back to it three months later and does not want to excavate a microservice burial mound.
This is also where owning the analytics feels different. When the data stays in Labbox, the event stream belongs to the project. It is not being sprayed into a giant advertising ecosystem. It is not being fed to a third-party profile machine. It is not there to retarget someone because they looked at a raccoon-adjacent cat profile. It is there to answer product questions: what is being used, what is ignored, and where the workflow is interesting enough to keep developing.
That fits the spirit of Junkdrawer perfectly. The pages are experiments, but they are not blind experiments. Lightweight analytics gives them a feedback loop. A prototype without feedback is just a guess with a URL. A prototype with simple analytics becomes something you can learn from.
It also fits Labbox perfectly. Labbox is not just “the backend.” It is the place where useful small tools get persistence, structure, and continuity. Analytics is another form of continuity. It tells you what happened after you shipped the page. It helps separate “I love this idea” from “people actually use this part.” It can show which pages deserve more work, which workflows are confusing, and which experiments are probably just decorative debris in the drawer.
The best part is that the architecture stays boring. A controller. An endpoint. A table or collection of events. A small JavaScript client. A shared secret. A dashboard. That is enough. If usage grows and the requirements change, the design can grow. Maybe later it needs rollups, retention policies, per-project tokens, rate limits, dashboards by date range, or a cleaner admin role model. Great. Add those when the pain is real.
But do not start there.
Start with the itch.
I want useful analytics.
I do not want surveillance sludge.
I do not want third-party leakage.
I do not want infrastructure theater.
I want to know if the pages are being used.
That is a perfect Labbox problem: small, practical, project-scoped, and useful across multiple tools.
The browser sends the signal. Labbox stores it. The dashboard makes it visible. The shared secret keeps it simple. And the whole thing stays honest about what it is: not Google Analytics, not an ad-tech tentacle, not a platform pitch.
Just enough analytics to help the Junkdrawer get smarter without selling its soul.
Junkdrawer repo: https://github.com/hmarquardt/junkdrawer
Labbox repo: https://github.com/hmarquardt/AISmallBizGuru-lab