Usermaven

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me product analytics that replace Usermaven: funnels and cohorts somebody can read without writing SQL, from events I capture automatically.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode — and read the note on scale at the end
- A tracking script under 6KB gzipped, from my own domain
- Server-rendered dashboard, charts as inline SVG drawn by hand
- Caddy in front

THE DATA MODEL
- users: id, external_id, email_hash, first_seen_at, last_seen_at, traits_json, company_id
- companies: id, external_id, name, traits_json — because business products are bought by an account, not a person, and every question is really about the account
- events: id, name, user_id, anonymous_id, session_id, path, referrer_host, utm_json, props_json, country, device, browser, os, bot, created_at
- sessions: id, user_id, anonymous_id, started_at, ended_at, entry_path, exit_path, event_count
- identities: anonymous_id, user_id, at — the stitch, so a visitor's events before signup belong to them afterwards
- funnels, cohorts, saved_reports: definitions only, computed at query time. Never stored results
- Everything is an event with a name and properties. A new signal is a new name, never a migration

AUTOMATIC CAPTURE, WHICH IS THE SELLING POINT
- The script records page views, clicks on interactive elements, form submissions, and outbound links without anybody instrumenting anything
- Each captured click carries a stable selector, the element's text and its position, so a button added on Tuesday is analysable on Wednesday without a deployment
- The stable selector is the hard part: prefer an explicit attribute, then an id, then a structural path that ignores generated class names. A selector that changes on every build makes the history worthless
- Autocapture is a starting point, not the whole story. Named events with properties are still better for anything that matters, so make defining one a single line and encourage it in the documentation
- Never capture the contents of an input. Ever. Autocapture that reads form values is how a password ends up in an analytics database

IDENTITY AND STITCHING
- An anonymous identifier per browser until the person is identified, then a stitch row that binds the two
- After stitching, the anonymous events belong to the user, and every report must honour that retroactively — which is why events keep both identifiers rather than being rewritten
- Traits set at identification and updated over time, with the value at the time of the event available to reports. 'Which plan were they on when they did this' is a question people ask constantly
- Company traits alongside user traits, and every report groupable by either

FUNNELS WITHOUT SQL
- Pick steps in order, choose a window, and see the count and the conversion at each
- Strict or loose ordering, chosen explicitly: loose allows other events in between, strict does not, and the difference changes the number a great deal
- Break the funnel down by any property — plan, country, device, source — with the segments compared side by side
- Show where people go instead of the next step, which is usually the most useful thing on the screen
- Time between steps, as a distribution rather than an average

COHORTS AND RETENTION
- A cohort is a saved definition: people who did this, with these traits, in this period. Computed at query time, never stored, so it is never stale
- Retention as a triangle: of the people who first did X in a given week, how many did Y in each following week
- Say plainly which retention definition is in use, because there are several and they give very different answers
- Cohorts usable as a filter anywhere else

ATTRIBUTION, CAREFULLY
- Capture the first and last touch per user, with the campaign parameters and the referrer
- Report both, and say which is which. Multi-touch attribution models are mostly a way of turning an unanswerable question into a confident number, so if you build one, label it as a model rather than a measurement

BOTS AND HONESTY
- Flag, never drop, and exclude through a SQL view
- The script executing is the strongest humanity signal available; record it
- Definitions written beside every number, because a metric without a definition is decoration and these numbers get shown to people who will act on them

PRIVACY
- No cookie beyond a first-party identifier you control, no third-party requests, and nothing sent anywhere else
- Email stored as a salted hash unless there is a reason to hold it
- Deletion by user identifier in one command

SCALE, HONESTLY
- Product analytics is high-volume, and SQLite will take you further than expected but not forever. Keep the event table narrow, index deliberately, and pre-aggregate nothing
- Write down the threshold at which you would move to a columnar store, and the fact that the event schema is the thing that would carry across

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, HASH_SALT, GEOIP_DB_PATH, SESSION_SECRET
- Migrations on boot, each once
- Nightly backup off the machine, restore script
- Health endpoint

WHAT MATTERS MOST
Identity stitching and stable selectors. Get the anonymous-to-known join right before any report exists, because every funnel and every cohort is wrong without it, and make autocapture's selectors survive a rebuild or the history means nothing.

Give me the repository, the tracking script, migrations, .env.example, a seed of shaped events, and a README with deploy steps behind Caddy and every definition written out.