One snippet, served first-party

Last week I said Tracely is "first-party by default." Today I want to unpack what that actually means mechanically, because delivery is one of those details that quietly decides whether an analytics tool works at all.

How the script is delivered

When you add a site to Tracely, you get a snippet that loads a hosted script from a per-site URL:

/js/tracely/{bundle_major}/{tracking_id}.js

The bundle_major in the path pins a major version of the tracker core, so I can ship a breaking change someday without silently altering what existing pages load. (A legacy URL without the major segment still works and resolves to the current default.)

That script isn't a static file. The controller compiles it per site: a small boot payload — your tracking ID, the ingest API base, and the on/off state of every tracking toggle from your site settings — gets prepended to the minified tracker core and served as one JavaScript body. Flip a toggle in settings and the script you're serving changes with it; no snippet edits, no redeploys of your site. The response is cached and gzipped so this stays cheap.

Once loaded, the tracker posts events back to the same origin's /api ingest endpoints. Your analytics traffic is a request from your visitor to the analytics origin you chose — not a beacon to a third-party domain a filter list has opinions about.

Why first-party delivery matters

Two practical reasons.

Ad blockers treat third-party analytics differently. Most content blockers work from domain lists, and the well-known analytics hostnames are on all of them. A script served from an origin you control, posting to that same origin, doesn't pattern-match to "known tracker domain." I don't think of this as evading anything — Tracely is cookieless and aggregate-first, which is precisely the kind of measurement that shouldn't need a third-party domain in the first place. First-party delivery just means your counts reflect your readers instead of the market share of filter lists.

Trust follows DNS. When your pages pull JavaScript from someone else's CDN, you've extended your security perimeter to include their infrastructure, their DNS, and their deploy process. With Tracely, the script comes from the deployment serving your dashboard. One origin to reason about, one TLS story, one place where the bytes live.

Pinning the exact bytes with SRI

There's an honest tension in dynamic delivery: the same URL can serve new bytes after a deploy or a settings change. Usually that's the feature. But if your security review wants to pin exactly what runs on your pages, Tracely supports subresource integrity.

In Site → Settings → Tracking there's an SRI panel below the default snippet. It gives you a <script> tag with integrity="sha384-…" and crossorigin="anonymous", where the hash is computed from the same body the script controller serves. If the served bytes ever differ from the hash — a deploy, a settings change, a compromise — the browser refuses to run the script. It fails closed.

The same hash is available from the CLI:

php artisan tracely:tracker-integrity {site-ulid}

which prints one line: the full sha384-… token, ready to paste into an integrity attribute. And because trust-but-verify is the whole point, the settings panel also gives you a curl … | openssl dgst -sha384 one-liner so you can compute the digest yourself and compare.

One caveat worth knowing: the hash reflects your saved settings, and it changes whenever settings or the tracker core change. Pinning means re-copying the snippet after those changes — that's the trade. Most sites should use the plain snippet and let the script update itself; SRI is there for the sites that need it.

The shape of the thing

I like that the whole delivery story fits in a few sentences: one URL per site, compiled from your settings, served from your origin, posting to your origin, with an opt-in hash if you want the bytes pinned. There's more to say about what happens after the POST lands — the queue-backed ingest pipeline deserves its own writeup, and it'll be the first proper deep dive here later this week.

Details on what the tracker can capture (and what it deliberately can't) are on /features and /privacy.