Track waitlist to activation

See which waitlist cohorts convert after invite, where they stall, and whether invite timing changes activation quality.

Updated · published

markdown for agents →

difficulty beginner · time to value 4 minutes · execution on demand
#analytics #waitlist #activation #onboarding #acquisition #product

Start from this 

Analyze waitlist conversion: joined waitlist, invited, accepted invite, signed up, activated, and retained by cohort and acquisition source.

Why this matters

Waitlists create demand, but delayed access can cool intent. This workflow shows whether your invite cadence turns demand into activation.

What you get

  • Waitlist cohort conversion
  • Invite acceptance and signup rate
  • Activation after invite
  • Source quality and timing effects

Walk through it

You

How well does our waitlist convert after invites?

Agent

I’ll build a waitlist-to-activation funnel by cohort and source.

Endpoint: POST /v1/projects/:project_id/analytics/query
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fanalytics%2Fquery&method=post
Custom HogQL goes in the OpenAPI-defined `query` field.
Concept fields:
  query: "SELECT properties.cohort AS cohort, properties.source AS source, countIf(event = 'waitlist_joined') AS joined, countIf(event = 'invite_accepted') AS accepted, countIf(event = 'activated') AS activated FROM events WHERE event IN ('waitlist_joined','invite_accepted','activated') GROUP BY cohort, source ORDER BY joined DESC"

The output

The agent returns cohort conversion and recommends whether to invite faster, change messaging, or segment by source.

Setting it up

Emit waitlist and invite lifecycle events. Preserve source and cohort through signup and activation.

Variations

  • “Compare invites sent within 7 days vs after 30 days.”
  • “Find sources with high waitlist joins but low activation.”
  • “Publish this for launch planning.”

Related workflows

growth 5 minutes

Measure a verified three-step signup funnel

Map three ordered lifecycle events to live project signals, run the canonical funnel blueprint, and explain drop-offs without inventing causes or benchmarks.

growth 5 minutes

Measure landing-page source quality

Compare acquisition sources by activation, retention, and paid conversion instead of only measuring clicks or signups.

growth 15 minutes

Identify early behaviors associated with retention

Compare predefined first-window product behaviors with later retained activity, quantify associations, and design a validation step without declaring a magic cause.

Adapt this workflow in your own agent.

Ask your agent to map the starter prompt to your saved signal map, live events, and the current HTTP API before answering.

Agentry gives coding agents production context from errors, product analytics, and deploys through one HTTP API. Fetch and read https://agentry.sh/install.md completely, then install Agentry's full first-time telemetry baseline in this repository. I authorize device-code login, saving the owner key only to ~/.agentry/credentials.json, creating one Agentry project for this repository, and read-only inspection of shipped source plus hidden CI/provider configuration. Deeply analyze the product's business logic and complete value flow before choosing telemetry. Save the complete source-backed plan and show me its exact contents and hash. Until I explicitly approve that plan or request a replacement, do not edit app/CI source, place runtime/CI credentials, commit, exercise product traffic, start proof, push, or deploy. After approval, I authorize only the reviewed targets: place the required scoped browser/server/CI credentials through the established environment or secret mechanism, preserve existing telemetry, implement and test the baseline, commit it, push that reviewed commit when the shipped CI/provider path requires it, exercise safe proof paths with test/non-customer data, and perform one deployment through the reviewed shipped CI/provider path. Ask first if proof would charge money, contact a third party, change real customer data, or require new external access. After the plan is saved, immediately before every onboarding state-changing POST, GET current onboarding state, perform only its single returned next_action, then read state again; do not batch or infer later stages. Continue until status is verified, installation_complete is true, and next_action is null. Keep all secrets, source snapshots, proof markers, and scratch files outside the repository.

+ Full access
5.5 Extra High
  1. 1. Open your repo in Codex, Claude Code, Cursor etc.
  2. 2. Paste the install prompt.
  3. 3. Your agent reads the install doc and shows you an implementation plan for approval.
← all workflows