Skip to content

We cannot tell how many visitors finish a site #421

Closed

Description

@singhharsh1708

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.

Activity

  1. singhharsh1708 commented on Oct 3, 2026

    @singhharsh1708
    OwnerAuthor

    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.

  2. singhharsh1708 commented on Oct 3, 2026

    @singhharsh1708
    OwnerAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions