Product analytics, built on every verified stack.
Product-analytics schema: tracked apps with unique ingest keys, an append-only event stream, session windows, and saved funnels, all hung off Better Auth's user table.
40 verified stacks
Showing 12 across 1 app types. Every stack page links its neighbours along each axis, so any combination is a click or two from here.
What Product analytics gives you
Ingest is the constraint everything else bends around. A write arrives carrying an api_key, and that column on tracked_apps is UNIQUE so the lookup is a single index probe returning an app_id — no join to identity on the write path, even though tracked_apps.owner_id foreign-keys Better Auth's user table for the dashboard side. Every other table hangs off that app id: events, sessions and funnels all reference tracked_apps.id with ON DELETE cascade, which makes an app registration the unit of scoping and the unit of deletion at once. events.occurred_at is notNull with no default, and that is the schema's most consequential line. The caller stamps the event; the database does not.
An SDK buffering through a dead network replays honestly because the backlog keeps its real instants — and there is no received-at column anywhere, so nothing records how late a batch showed up. Properties travel in a JSON column with no declared shape and no index, so a filter on a property value runs inside whatever slice idx_event_app_time (app_id, occurred_at) has already narrowed. sessions is not the parent of events. Nothing foreign-keys the two together; the correlation is anonymous_id, which is notNull on sessions, nullable on events, and indexed on neither, while idx_session_app covers app_id alone. Per-app, per-window questions are therefore cheap and stitching one visitor's path is not: bound by app and time first, then match ids inside that slice.
If visitor-level replay is the product rather than a report, add an index on (app_id, anonymous_id, occurred_at) before the event table gets large, because the schema will not do it for you. funnels stores definitions, not results — a name and a JSON steps array per app, with no index declared beyond the primary key. Evaluating a three-step funnel is three bounded scans of idx_event_app_time with a name filter applied inside each, and nothing caches the answer. That keeps funnel maintenance off the write path entirely and puts the whole cost on read, which is the right trade while an app's volume still fits a range scan and the wrong one once it does not.
Built for
idx_event_app_time on (app_id, occurred_at), with app_id as the leading column so the window is a straight index range. Event name and the JSON properties are filtered inside that range — neither carries an index of its own.
tracked_apps.api_key is UNIQUE, so the ingest handler turns a key on the wire into an app_id in one probe and writes the events row against that foreign key without ever reading the user table.
idx_app_owner on tracked_apps.owner_id, the foreign key into Better Auth's user. It is the only path from identity down to data: events, sessions and funnels carry no user id of their own, only app_id.
idx_session_app on sessions.app_id narrows to the app, then ended_at IS NULL picks the windows that never closed. started_at supplies the ordering; there is no duration column to keep in sync.
Read the funnel's JSON steps row by app_id, then one bounded idx_event_app_time scan per step name. Nothing is precomputed — a funnels row is a definition, and the entire cost lands on read.
Why Product analytics, specifically
api_key on tracked_apps carries a unique constraint: each app gets exactly one ingest key, and the key is the authentication surface for the event ingestion endpoint.
events is append-only (no update path, no status column) — the composite index on (app_id, occurred_at) is the only query handle; roll-up queries must scan that index, not mutate rows.