Introducing Tracely

This week I started building Tracely in earnest, and this blog is where I'll write about it as it happens: short notes twice a week, and longer deep dives when something under the hood deserves a proper writeup.

What Tracely is

Tracely is web analytics with a simple contract: add one script tag, get a dashboard that answers the questions you actually have — what's being read, where people come from, what's converting — without cookies, without fingerprinting, and without shipping your visitors' behavior to an ad network.

A few principles are already baked in:

First-party by default. The tracking script is served from the app itself at a per-site URL, and events post back to the same origin's ingest endpoints. Your analytics traffic looks like your traffic, because it is.

Aggregate-first. Tracely stores paths, referrers, funnels, and journeys as aggregates. There is no session replay, and there won't be. Watching an individual person's cursor move around a page is a line I don't want this product to cross — and as it turns out, you rarely need it to make good decisions.

Composable, not a walled garden. Full data export, a Bearer-token read API for pulling aggregates into your own tools, and optional data sources (like an existing GA4 property) that sit beside Tracely instead of fighting it. If you ever want to leave, your data comes with you.

What works today

The core loop is already alive: create a site, get a tracking ID, paste the snippet, and pageviews flow into an overview dashboard with sources, pages, technology, entry and exit pages, and a live view. Goals, funnels, campaigns, and custom events are in various states of polish. Ingest is queue-backed so traffic spikes don't take the dashboard down with them.

There's more scaffolding than paint right now — that's what the next several months are for.

Why another analytics tool

Fair question, given Plausible and Fathom exist and are good. Two reasons. First, I want analytics that treats the content workflow as a first-class citizen — publication-desk views for editorial teams, content decay detection, coverage checks for the URLs you expect to get traffic. Second, I want the operational story — self-hosting, exports, APIs, edge ingest — to be genuinely boring and dependable, not an afterthought.

Follow along

I'll publish product notes on Tuesdays and Fridays, plus occasional deep dives into the engineering: the ingest pipeline, the rollup architecture, anomaly detection, and whatever else turns out to be interesting to build. If any of that sounds useful, the feed is here.