Tally

Changelog

2026-05-09T00:00:00Z

v1.0.0 — 2026-05-09

The first stable release. We’ve been running this in production for the last six months across ~40 sites; the feature set hasn’t moved in three. Time to drop the beta tag.

Stable API. No more breaking changes between minor versions. The tally() function signature, the data-site attribute, the dashboard REST API — all locked.
Self-hosted parity. The Docker image, the SQLite default, the optional Postgres mode, the migration story — fully exercised by the cloud product. Same image, same code path.
Single-page-app autopilot. History API navigations are detected without configuration in React Router, SvelteKit, Next.js App Router, Vue Router, and Astro view transitions.
CSV export. Raw-events export is now available from the dashboard on every plan.

v0.9.4 — 2026-04-22

Fixed a regression where the daily salt rotation could fire twice on servers with a clock that jittered backward at midnight UTC.
Added a --dry-run flag to the migration CLI.
Documentation for the first-party-hosting proxy setup.

v0.9.3 — 2026-04-08

Real-time dashboard now updates via SSE instead of long-polling. Dropped the upstream NGINX timeout requirement.
Funnel definitions can now reference custom-event properties.

v0.9.0 — 2026-03-15

Custom events API. tally('signup', { plan: 'pro' }) is now a thing.
Funnels (closed beta).
Breaking: the t.js script is now under /t.js instead of /track.js. Old path serves a 301 redirect; will be removed in v1.1.

v0.8.0 — 2026-02-04

New, smaller tracker script (was 1.4 KB, now 0.9 KB gzipped).
Initial Postgres backend support.
Breaking: dashboard moved from /admin to /dashboard.

Privacy policy

2026-04-01T00:00:00Z

This is the version of the privacy policy written for humans. The formal document lives at /privacy/full/ and governs in case of conflict.

What Tally collects

For each page view on a site that uses Tally, we receive:

The URL path of the page (without query strings, unless the site owner explicitly opts in).
The referrer (the page the visitor came from, if any), normalised to the domain.
A coarse country code derived from the visitor’s IP address. The IP itself is not stored.
The device class (desktop / tablet / mobile) and the browser family, derived from the User-Agent string. The full UA string is not stored.
A daily visitor ID that is the SHA-256 of (IP, UA, today's rotating salt). The salt is regenerated every 24 hours and the previous salt is discarded. This means we cannot link a visitor’s activity across calendar days.

That’s everything. We do not set cookies. We do not fingerprint. We do not retain anything that could be used to re-identify a specific person.

What we do with it

We aggregate it into the dashboard the site owner sees. That’s the entire purpose of the product.

We do not:

Sell data to third parties.
Share data with advertisers.
Use the data to train any model, ours or anyone else’s.
Combine data across sites in any way that would let us build a profile of an individual.

Where the data lives

For Cloud customers: in our database in Frankfurt (Hetzner). Daily backups go to a second region; both regions are inside the EU.

For Agency customers: same, with optional region selection at checkout.

For Self-hosted: on your server. We never see it.

Your rights

If you are an end user of a site that uses Tally:

We don’t have any data that could let us find your activity in our database, because we explicitly designed it that way.
The site owner who runs Tally on their own infrastructure may have data subject to their privacy policy. Contact them.

If you are a Tally customer:

Export, delete, or modify your account data at any time from the dashboard.
Email privacy@tally.dev for anything the dashboard doesn’t cover.

About Tally

2026-04-01T00:00:00Z

Tally is built by a two-person team out of Lisbon. We started it in late 2024 because we wanted analytics for our own side projects without re-litigating GDPR every time we shipped a new one.

What we believe

Privacy is a default, not a feature. A consent banner that asks permission to track is a worse experience than not tracking that data in the first place. We aggregated everything we actually use — page views, top sources, referrers, conversion funnels — and built a tool around that subset, then stopped.

Open source is the substrate. The product is MIT licensed; the self-hosted version is the same code as the cloud version. If we go away tomorrow, you have the source, the database schema, and a migration path. We make it easy to leave because we want you to stay.

Less product is more product. We’ve turned down feature requests for cohort analysis, A/B testing, session replay, and revenue attribution. There are good tools for all of those things. None of them belong in a tool whose job is “tell me what’s happening on my site at a glance.”

Who’s working on it

Two people, full-time. Both founders. We answer support email, write the code, ship the releases. There is no sales team because there is no sales process — pick a tier, click the button, you’re billed.

Where we’re going

The roadmap is short on purpose:

More integrations. First-class Cloudflare Worker / Vercel Edge setup. A Caddy module for first-party proxying. A Hugo theme.
Better self-hosted onboarding. A one-command installer for common VPS providers.
A CLI. For the people (us, mostly) who’d rather curl the API than open a dashboard.

That’s it. We will keep this short.