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. ```sql -- 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.