+2
Product Analytics

Find our activation moment

Discover the aha moment: which early in-product action, taken in the first session or first week, most separates users who stay from users who vanish, how to score candidate first actions by retention lift, and what share of new signups ever reach it. Covers activation metric definition, activation rate and time to value.

  • +3
    Which action in the first week predicts whether someone sticks around?
  • +3
    What percentage of last month's signups reached activation?
  • +3
    Compare users who connected a data source in their first 3 days to users who didn't

The playbook

The activation metric is discovered, not declared. Every candidate event you score is a predictor of retention, not a cause of it, so the output of this analysis is a ranked hypothesis list that a holdout still has to confirm.

Steps

  1. Enumerate the event namespace and check when each event started firing. posthog.list_events, mixpanel.list_events or amplitude.list_events for the full list. Then query min(timestamp) and max(timestamp) per event name with posthog.query (HogQL) or mixpanel.segmentation. Discard pageview-only and system-fired events, and discard any event whose first occurrence is after the cohort start date: its reach is mechanically near zero and its lift is garbage. Never assume an event exists because the product has the feature.

  2. Pick the retention yardstick before scoring anything. Choose one key action that best represents delivered value, and its natural frequency: weekly for most B2B SaaS, monthly for infrequent transactional products. Use posthog.list_properties or mixpanel.list_event_properties to find the signup-date property and the segmentation properties (plan, acquisition channel, platform, company size). Call posthog.list_cohorts to see whether the team already has a saved activation or power-user cohort, so the answer uses their definition rather than a new one.

  3. Build the retained versus churned split for one signup cohort. Take all users whose first signup event falls in one month. Label a user retained if they performed the key action during a fixed later window, for example week 4 through week 6 after signup, else churned. Both groups must have had the same elapsed time since signup. Build the cohort from the event stream at signup time, not from the current users table, or GDPR deletions and removed accounts bias the retained share upward.

  4. Score every candidate event by reach and lift inside a fixed early window. One posthog.query does the whole table: a CTE for the cohort, a CTE for events where timestamp < signup_ts + INTERVAL N DAY, a CTE for the retained label, then GROUP BY event. For each event compute reach = doers / cohort size and lift = P(retained | did it) / P(retained | did not do it). Run N at 1, 7 and 14 days. A 6x lift at 2% reach is a power-user marker, not an activation metric; the candidate you want is the highest-lift event a meaningful share of the cohort can plausibly be driven to.

  5. Add the count dimension and find the knee. Re-score the top candidates at thresholds of at least 1, 2, 3 and 5 occurrences within the window. Activation metrics are almost always "X actions in Y days", and the right X is the point where additional occurrences stop adding lift. Report that knee explicitly.

  6. Validate the winner and test for Simpson's paradox. amplitude.retention_report with the candidate activation cohort versus everyone else: the two curves must visibly separate and the activated curve must flatten. Then re-run the lift holding plan, acquisition channel and platform fixed, and only promote a candidate whose sign is stable across all three. Optionally join to stripe.list_subscriptions on email or customer id to check whether the candidate also predicts paid conversion.

  7. Report. One table ranked by lift: candidate event, window in days, threshold count, reach %, retained share among doers, retained share among non-doers, lift, implied activation rate, and sign-stable across segments (yes or no). Then one sentence naming the recommended activation definition, the activation rate it implies for the latest cohort, and the explicit statement that this is a correlational finding to be confirmed with a feature flag holdout.

Gotchas

  • Exposure bias makes downstream events look magical. A user can only fire invited_teammate if they got through onboarding, so part of the lift is just "survived long enough to be able to do it". Report lift conditional on reaching the preceding funnel step, or at minimum flag which candidates sit downstream of each other.
  • Correlation is not causation, and this analysis cannot produce causation. High lift makes an event a good predictor, which is all an activation metric needs to be. It does not license "if we push users to do X, retention rises". State this in the output every time.
  • Hold both windows to days since signup, never to calendar dates. Comparing "did X in the first 7 days" against a retained set measured over a variable calendar window silently rewards older users and invents lift.
  • Account versus user activation in B2B. In seat-based products the activating actor is often an admin while the retained actor is an end user. If group analytics is configured, run the whole analysis at group level. If not, say the user-level answer may be an artefact of who holds the admin seat.
  • Identity stitching splits the first day in two. Pre-signup anonymous events and post-signup identified events are different actors until the identify call fires, and PostHog excludes anonymous events from lifecycle status. A first-day window that straddles identification drops real activity.
  • Connector degradation is real and you must declare it. PostHog only is the best case, since HogQL makes the lift table one query. Mixpanel only has no arbitrary SQL: approximate with mixpanel.funnel_report placing the candidate as step 2 and the key action as step 3, or mixpanel.export_events for the cohort and compute locally, warning that export is slow and volume-capped. Amplitude only cannot scan the whole namespace cheaply, so ask the PM to nominate 5 to 10 candidates and use amplitude.event_segmentation for reach plus amplitude.retention_report with a behavioural cohort for lift.
  • Do not attempt this on GA4 alone. google_analytics.run_report has no user-level event export and cannot express user-scoped behavioural cohorts. Degrade to signup-to-first-key-event conversion rate by channel, say explicitly that it is not an activation analysis, and do not compare the result to any activation benchmark.

Sequel CLI

Install Sequel skills into your agent

One command connects your agent to Sequel and installs the Sequel skill, so it knows this playbook exists and reads it when a question matches. The CLI signs you in, provisions a scoped API key and writes the config for you.

Already have an MCP client?

https://api.sequel.sh/mcp

Point it at this URL and sign in when prompted, or send an API key from Settings as a Bearer token. Skills come with it; nothing else to install. Manual setup per client

  1. 1

    Install the Sequel CLI

    One line installs the latest CLI with whatever package manager you have.

    curl -fsSL https://sequel.sh/install | sh
  2. 2

    Sign in

    Authenticate in your browser and pick an organization.

    sequel login
  3. 3

    Install into your agent

    Writes the MCP config and installs the Sequel skill file for agents that support skills. Pick an agent from the list, or target one directly by its slug.

    sequel install
    • Claude Code
      sequel install claude-code
    • Claude
      sequel install claude
    • Cursor
      sequel install cursor
    • VS Code
      sequel install vscode
    • Windsurf
      sequel install windsurf
    • Zed
      sequel install zed
    • Codex
      sequel install codex
    • OpenClaw
      sequel install openclaw
    • Hermes
      sequel install hermes

More like this

Other Product Analytics skills

Can we trust our product metrics

Two tools show different numbers for the same metric and nobody knows which to trust. Reconciles the disputed figure against a system of record such as Stripe or the application database, then finds the instrumentation defect behind it: duplicate and near-duplicate event names, events that silently stopped firing, missing properties and system-fired events counted as user actions.

Feature launch impact readout

Measure whether a feature we just shipped actually landed: adoption against an eligible denominator of users who could even reach it, breadth, depth and sustained use after the release, a pre and post impact estimate with or without a control group, and a keep, iterate or sunset call.

Is our retention curve flattening

Do users keep coming back, or do they drift away after the first week or month? Builds the cohort retention curve for your key action at its natural frequency and judges whether it flattens to a plateau or decays to zero, covering N-day versus unbounded retention, repeat usage, leaky bucket diagnosis and how the plateau compares to published benchmarks.

Read out an A/B test honestly

Is this A/B test result real, or statistically significant only by accident? Runs the validity gates before reporting anything (sample ratio mismatch, peeking, power and minimum detectable effect, novelty), then gives absolute and relative lift with a confidence interval, a ship or kill call, and the winning variant extended through to revenue instead of stopping at the proxy metric.

Signup funnel drop-off analysis

Find the step where the most users abandon signup or onboarding, and how that varies by segment.

FAQ

Frequently asked questions

What is an activation metric?
The single early in-product behaviour that best separates retained users from churned users, usually expressed as a count in a window, for example two projects created in the first seven days. It is not the feature you are proudest of, and it is not signup completion. It sits between setup work and habit, and it is the only one of the three you should call activation.
How do I find my product's aha moment from event data?
Label one signup cohort retained or churned using your key action in a fixed later window, then for every candidate event in the first N days compute reach, meaning the share of the cohort that did it, and lift, meaning P(retained given they did it) divided by P(retained given they did not). Rank on lift and reach together. Run N at 1, 7 and 14 days, because the best window is an output of the analysis, not an input.
What is a good activation rate for SaaS?
Lenny's Newsletter activation benchmark data from a survey of more than 500 products reports a mean of 34% and a median of 25% across all products, and a mean of 36% with a median of 30% for SaaS specifically. The same source frames the 60th percentile as good and the 80th as great. Your own trend across cohorts is more informative than the benchmark.
Does a high-lift event mean pushing users to do it will improve retention?
No. Lift is a predictive relationship, so the output of this analysis is a hypothesis, not a proven cause. Engaged users do more of everything, and many candidate events are only reachable by users who already got through onboarding. The only way to claim causation is a feature flag holdout or an experiment.
Can an AI agent find our activation moment?
Yes. With PostHog, Mixpanel or Amplitude connected, the agent enumerates the event namespace, builds the retained versus churned split for one signup cohort, scores every early event by reach and lift, and returns a ranked candidate list with the activation rate implied by each. Sequel provides the product analytics and warehouse connections over MCP and the activation-moment-analysis playbook.

Put this playbook to work

Connect a source, ask the question, and the agent follows these steps. Free to start.