Overview
Per site or across a workspace: visitors, page views, events, bounce rate, a chart per day, top pages, referrers, UTM tags, countries, devices, browsers, systems, and web vitals if you send them.
Features
What’s there today, and what isn’t.
Everything on this page exists in the repo and runs on a test instance. It hasn’t met real traffic yet. What’s still missing is listed at the end.
The library
packages/trailic, about 1.5 KB gzipped, with React as its only peer. Events wait up to 5 seconds, or until there are 10, and go in one request. A collector that’s down changes nothing on the page: every failure is swallowed, and nothing is retried.
- <Trailic />
- Counts the page it starts on and every move through the history API. Renders nothing.
- track(name, props)
- A custom event. Strings, numbers and booleans, 16 at most.
- identify(userId, traits)
- Who this is from here on. Only when your project calls it, typically after sign-in.
- reset()
- Forgets them, typically at sign-out.
- setConsent(granted)
- Holds everything in memory until it turns true.
- trackServer(name, props, options)
- From trailic/server, for route handlers. Says whether the event was taken, and never throws.
- <TrailicVitals />
- From trailic/vitals, optional: LCP, CLS and INP.
- trailicRelay()
- From trailic/next, to collect through your project’s own domain.
The package isn’t on npm yet: for now it’s built from the repo.
The screens
Funnels
Two to eight steps, each a page (a trailing * matches anything under it) or an event, and how long people have from the first step.
Retention
Cohorts by the Monday of the week someone was first identified, and what share came back each week after, by any activity or by a chosen event.
Journeys
From a page: each visitor’s first time on it that day, and the next three pages within half an hour, most common first.
A real screen from the app. Acme and its figures are made up, on a throwaway database.
- Custom events
- Each with its count, visitors and days.
- People
- Whoever a site identified, their recent activity and traits, and a button to erase one person’s data when they ask.
- Sites
- Each with its key, setup snippet, relay key, domains and retention, from 14 to 730 days of raw events.
- Workspaces
- Several companies on one instance, kept apart by row-level security, with a switcher, a team and invitations.
Reading it from elsewhere
An MCP server
At /api/mcp, over streamable HTTP. An assistant registers itself, a member signs in and approves it, and every tool runs as that member. They only read, apart from create_site and create_workspace.
A figures API
GET /api/v1/figures with a key holding the figures:read scope: per site and per day, counts only, no pages and no people.
Collecting and storing
A collector that doesn’t wake the database
POST /api/e checks the size, a signed key, the site’s domains, known bots and rate limits, then hands the batch to the buffer. Only what the buffer has kept is answered 202.
Written once, however often it’s delivered
Each workspace’s batches go in one transaction: the ledger of batch ids, the events, the people, the day’s rollups. A batch written but not acknowledged is delivered again, finds its id, and adds nothing.
Plain Postgres
No extension. Raw events are partitioned by month and rollups stay until the site is deleted. Every table and partition carries row-level security, and a test fails on any that doesn’t.
What isn’t built
None of this exists yet: session replay, automatic capture of every click, heatmaps, feature flags and A/B tests, surveys, account health. If you need one of these today, a more mature tool will serve you better. Section 9 of the spec