posthog-onboarding-conversion

name

posthog-onboarding-conversion

description

Rank the onboarding and activation steps that best predict a trial becomes a paying customer: build the onboarding funnel, flag who reached a first Stripe payment, and compare payers versus non-payers, saved as a reusable PostHog insight. Use this whenever someone asks which onboarding or activation steps lead to paid conversion, what converting trials do differently, which signup steps predict revenue, or where trials stall before paying. Triggers on phrasings like 'what makes trials convert', 'onboarding steps that lead to payment', 'activation actions that predict conversion', 'compare payers vs non-payers by onboarding', or 'where do trials stall'. Boundary: this analyzes the onboarding PATH to first payment in aggregate. For scoring and prioritizing which individual LEADS sales should contact, use posthog-lead-scoring. It sets up the Stripe source if needed and builds the insight end-to-end.

Which onboarding steps turn trials into paying customers?

Question: Which onboarding actions best predict that a trial becomes a paying customer? For: Growth · Difficulty: Beginner · Shape: a funnel + a join Data sources: PostHog funnels (onboarding steps) + Stripe (first successful payment)

What this produces

A saved PostHog insight comparing onboarding actions completed by users who reached a first Stripe payment against those who never paid, ranked by how strongly each step predicts conversion — so the user knows which steps to push everyone toward.

Workflow

First read references/posthog-workflow.md for the shared setup: confirm the PostHog MCP is connected, ensure the Stripe source exists (set it up via the secure connect-link flow if not), and learn this project's real schema. Then do the question-specific part below.

1. Identify the pieces in this project

• Onboarding steps. Use event-definitions-list to find signup → activation events. Confirm the intended step order with the user; onboarding funnels are product-specific.
• First payment. Identify each user's first successful payment from Stripe — typically the earliest paid stripe_invoice or successful stripe_charge per customer. Join to PostHog people on lower(email) (see the join gotchas in the shared reference).
• Conversion label. For each user, a boolean: did they ever reach a first Stripe payment?

2. Build and validate the query

Two good approaches — use whichever the user prefers:

• Funnel insight split by converted vs not (most native): build the onboarding funnel and break it down by a "paid" cohort. This shows step-by-step drop-off for payers vs non-payers directly.
• Comparison query (ranks predictive steps): compute, per onboarding action, the completion rate among payers vs non-payers and the lift. Start from this shape and adapt names, then validate with query-run:

-- Completion rate of each onboarding action among payers vs non-payers, with lift.
-- Adapt: onboarding event names, the payment definition, and the email join key.
WITH payers AS (
    SELECT DISTINCT lower(email) AS email
    FROM stripe_invoice
    WHERE status = 'paid'
),
user_actions AS (
    SELECT
        e.person.id AS person_id,
        lower(e.person.properties.email) AS email,
        e.event AS action,
        min(e.timestamp) AS first_did
    FROM events AS e
    WHERE e.event IN ('signed_up', 'completed_profile', 'created_project', 'invited_teammate', 'activated')
    GROUP BY e.person.id, lower(e.person.properties.email), e.event
)
SELECT
    ua.action,
    countIf(p.email != '') AS payers_who_did,
    countIf(p.email = '') AS nonpayers_who_did,
    round(countIf(p.email != '') / nullif(count(), 0), 3) AS share_of_doers_who_paid
FROM user_actions  ua
  payers  p  ua.email  p.email
  ua.action
  share_of_doers_who_paid 

Note the caveat honestly when you report: this is correlation, not proof of causation — steps that correlate with paying aren't guaranteed to cause it.

3. Save the insight

Save as a funnel insight (if you went the funnel route) or a SQL/HogQL table insight named "Onboarding steps that predict conversion", described with the payment definition and window. Return the URL and tell the user which steps most separate payers from non-payers.

Self-driving development (offer this)

With the steps that predict conversion, the user can spot trials stalling before them. Offer to help set up in-product prompts, a lifecycle email trigger, or an experiment that moves stalled users forward — turning more trials into customers.