Posthog Feature Revenue Impact

Did the feature we shipped move revenue?

Question: Do users exposed to the new-feature flag show higher downstream revenue/retention than control? For: Product & PMM · Difficulty: Advanced · Shape: a cohort join Data sources: PostHog experiments (flag-exposure cohorts) + Stripe (revenue & retention)

What this produces

A saved PostHog insight comparing Stripe revenue and retention between the flag-exposed cohort and the control cohort — so the user can tell whether a rollout actually moved money, not just usage.

Workflow

First read references/posthog-workflow.md for the shared setup: confirm the PostHog MCP is connected, ensure the Stripe source exists (secure connect-link flow if not), and learn the real schema. Then:

1. Identify the pieces in this project

• Exposure cohorts. Find the feature flag / experiment and each person's variant from exposure events — typically $feature_flag_called with $feature_flag = the flag key and $feature_flag_response = the variant (test/control or true/false). Confirm the flag key and variant values with the user; also confirm the exposure date so revenue is measured after it.
• Revenue & retention. From Stripe: revenue per person after exposure, and whether they retained (still active after N days). See the money/time gotchas in the shared reference.
• Join key. Person → Stripe by lower(email).

2. Build and validate the query

Adapt names and validate with query-run. Compare cohorts on average post-exposure revenue and retention.

-- Post-exposure revenue & retention: flag-exposed vs control.
-- Adapt: the flag key, variant values, the exposure/measurement window, and the email join key.
WITH exposure AS (
    SELECT
        person.id AS person_id,
        lower(person.properties.email) AS email,
        argMin(properties.$feature_flag_response, timestamp) AS variant,
        min(timestamp) AS exposed_at
    FROM events
    WHERE event = '$feature_flag_called'
      AND properties.$feature_flag = 'my_new_feature'      -- the flag key
    GROUP BY person.id, lower(person.properties.email)
),
revenue AS (
    SELECT lower(email) AS email, created, amount / 100.0 AS amount, status
    FROM stripe_invoice
)
SELECT
    ex.variant,
    count(DISTINCT ex.person_id) AS users,
    round(sum(if(r.status = 'paid' AND r.created >= ex.exposed_at, r.amount, 0))
          / nullif(count(DISTINCT ex.person_id), 0), 2) AS revenue_per_user_post_exposure,
    round(countIf(r.status = 'paid' AND r.created >= ex.exposed_at + INTERVAL 30 DAY)
          / nullif(count(DISTINCT ex.person_id), 0), 3) AS retained_share_30d
FROM exposure AS ex
LEFT JOIN revenue AS r ON ex.email = r.email
GROUP BY ex.variant
ORDER BY revenue_per_user_post_exposure DESC

Be careful and honest: only measure revenue after each user's exposure timestamp; report cohort sizes; and note that unless this came from a proper randomized experiment, differences may reflect who was exposed rather than the feature itself. If it was a PostHog experiment, PostHog's experiment results with a revenue/Stripe metric may be the cleaner tool — mention that option.

3. Save the insight

Save as a SQL/HogQL insight named "Feature revenue impact: exposed vs control", documenting the flag key, variants, and measurement window. Return the URL and give the plain read: which cohort earned more per user, and whether the gap is big enough to matter given the cohort sizes.

Self-driving development (offer this)

With revenue tied to each rollout, the user can tell which changes pay off. Offer to help wire this up so winners can be ramped and laggards rolled back — and to set up the same measurement as a reusable template for the next feature — shipping what moves money, hands-off.