posthog-feature-revenue-impact

name

posthog-feature-revenue-impact

description

Measure whether a specific feature rollout moved revenue: split users on feature-flag or experiment exposure and compare downstream Stripe revenue and retention between the exposed cohort and control, saved as a reusable PostHog insight. Use this whenever someone wants the revenue impact of an experiment or a feature they shipped, wants to tie a feature flag or A/B test to revenue and retention, or asks whether a rollout paid off. Triggers on phrasings like 'did the feature we shipped move revenue', 'revenue impact of our experiment', 'did the rollout pay off', 'compare exposed vs control on revenue', 'feature flag revenue lift', or 'A/B test revenue'. Boundary: this is a before/after causal test tied to a specific flag or experiment. For ranking which EXISTING features high-revenue customers already use, use posthog-features-drive-revenue. It sets up the Stripe source if needed and builds the insight end-to-end.

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)  revenue_per_user_post_exposure,
    round(countIf(r.status    r.created  ex.exposed_at    )
           (( ex.person_id), ), )  retained_share_30d
 exposure  ex
  revenue  r  ex.email  r.email
  ex.variant
  revenue_per_user_post_exposure 

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.