You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
We cannot tell how many visitors finish a site #421
We cannot tell how many people who arrive actually finish a site, so every roadmap decision after this one is guesswork.
What we know: 399 visitors in 30 days, 313 on the home page, 87 on /templates, 55 on /create. What we do not know: how many opened the editor, how many pressed Export, how many got a ZIP. The gap between 55 and zero is the only number that says whether this product works for people who are not us.
@vercel/analytics is already installed and wired in layout.tsx, so this is four track() calls, not a new dependency:
editor opened, with the template slug
first edit made
export started
export finished, with how long it took
Counts only. No copy, no instruction text, no file contents, nothing that identifies a person. The privacy page has to say so in the same breath, since it currently promises that what you type stays on your device, and that promise must stay true.
Done when: the four events are live, the privacy page names them, and we can state plainly what share of visitors who open the editor come out with a site.
Shipped in #423 and #424, with one thing to set before the numbers exist.
Vercel custom events turned out to be Pro and Enterprise only, and this project is Hobby, so #423 writes events nothing can read. #424 keeps the same four counts in the Upstash Redis already used for rate limiting, scoped so previews and local runs cannot inflate them.
Live checks just now: POST /api/count answers 204, an unknown event name answers 400, and GET without a token answers 404.
Two variables decide whether any of it records anything:
UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN. Without them the route answers 204 and writes nothing, which is indistinguishable from working.
FUNNEL_TOKEN, 16 characters or more. Without it GET /api/count answers 404 and the counts can only be read from the Upstash console.
Then GET /api/count?days=7 with "Authorization: Bearer " gives the four totals, the share of people who opened the editor and came out with a site, the mean export time, and a breakdown by template.
One count in today's production numbers is mine, a single first_edit from testing the live route.
Two days: 13 editor opens, 12 on kept, 2 first edits, 2 exports. Nearly all of that is headless verification from this work, not visitors.
#432 fixes the cause: the counts now return early when navigator.webdriver is set, which Chrome's remote debugging and every automation framework set. Verified by running the same scripted session against production, which sent all four events, and against a build with the guard, which sent none.
Counts are per day, so from tomorrow they are visitors only.
Activity
singhharsh1708 commentedon Oct 3, 2026
Shipped in #423 and #424, with one thing to set before the numbers exist.
Vercel custom events turned out to be Pro and Enterprise only, and this project is Hobby, so #423 writes events nothing can read. #424 keeps the same four counts in the Upstash Redis already used for rate limiting, scoped so previews and local runs cannot inflate them.
Live checks just now: POST /api/count answers 204, an unknown event name answers 400, and GET without a token answers 404.
Two variables decide whether any of it records anything:
Then GET /api/count?days=7 with "Authorization: Bearer " gives the four totals, the share of people who opened the editor and came out with a site, the mean export time, and a breakdown by template.
One count in today's production numbers is mine, a single first_edit from testing the live route.
singhharsh1708 commentedon Oct 3, 2026
First numbers, and a caveat: they were mostly me.
Two days: 13 editor opens, 12 on kept, 2 first edits, 2 exports. Nearly all of that is headless verification from this work, not visitors.
#432 fixes the cause: the counts now return early when navigator.webdriver is set, which Chrome's remote debugging and every automation framework set. Verified by running the same scripted session against production, which sent all four events, and against a build with the guard, which sent none.
Counts are per day, so from tomorrow they are visitors only.