> AI agents: this is one page from PostHog's docs. Full index of Markdown docs for LLMs: https://posthog.com/llms.txt

# Did the feature we shipped move revenue? – Data Stack pocket guide

[](/pocket-guides.md)

AA

Contents

-   [Introduction](/pocket-guides/data-stack.md)
-   Ask a quick question

    [Features & revenue01](/pocket-guides/data-stack/features-drive-revenue.md)
-   [Onboarding conversion02](/pocket-guides/data-stack/onboarding-conversion.md)
-   [Upsell-ready accounts03](/pocket-guides/data-stack/upsell-ready-accounts.md)
-   [Pre-cancellation behavior04](/pocket-guides/data-stack/pre-cancellation-behavior.md)
-   [Tickets & churn05](/pocket-guides/data-stack/support-tickets-churn.md)
-   [ARR vs engagement06](/pocket-guides/data-stack/value-vs-engagement.md)
-   [Channels & retention07](/pocket-guides/data-stack/acquisition-channels-retention.md)
-   [Lead scoring08](/pocket-guides/data-stack/lead-scoring.md)
-   [Feature revenue impact09](/pocket-guides/data-stack/feature-revenue-impact.md)
-   Data modeling

    [Foundations10](/pocket-guides/data-stack/warehouse-foundations.md)
-   [Revenue11](/pocket-guides/data-stack/revenue-metrics.md)
-   [Conversion12](/pocket-guides/data-stack/conversion-metrics.md)
-   [Activation13](/pocket-guides/data-stack/activation-metrics.md)
-   [Usage14](/pocket-guides/data-stack/product-usage-metrics.md)
-   [Dimensions15](/pocket-guides/data-stack/dimension-tables.md)

[](/pocket-guides.md)Aa

[](/pocket-guides/data-stack/lead-scoring.md)[](/pocket-guides/data-stack/warehouse-foundations.md)

# Did the feature we shipped move revenue? – Data Stack pocket guide

Usage went up after launch. But did revenue? This Skill splits users by feature-flag or experiment exposure and compares downstream Stripe revenue and retention between the exposed cohort and control, so a rollout's impact is measured in money as well as clicks.

## Example data and how to read it

The Skill looks for patterns like Fig. 1: the exposed cohort earned $6.40 more per user after exposure and retained six points better. This shows the experiment was successful, and reporting both cohort sizes makes clear the gap reflects a large sample, not noise from a handful of accounts.

| Variant | Users | Revenue/user (post-exposure) | Retained (30d) |
| --- | --- | --- | --- |
| test | 1,240 | $61.20 | 71% |
| control | 1,180 | $54.80 | 65% |

Fig. 1 – Example data: revenue and retention, flag-exposed vs control.

## Get an agent to do the work

Copy the Skill below and add it to your agent. The agent finds each person's variant from `$feature_flag_called` exposure events and their exposure timestamp, then compares Stripe revenue and a retention share earned *after* that timestamp between variants. It reports cohort sizes alongside the numbers, and is explicit that unless this came from a proper randomized experiment, the gap may reflect who was exposed rather than the feature itself, flagging PostHog's own experiment-results view as the cleaner tool when that applies.

This is a before/after test tied to a specific flag or experiment. For ranking which *existing* features high-revenue customers already use, with no rollout involved, that's [Features & revenue](/pocket-guides/data-stack/features-drive-revenue.md) instead.

posthog-feature-revenue-impact/SKILL.md

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

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

Show full example

Fig. 2 – The Skill itself, copy and paste this into your agent to answer the question.

## Doing this by hand

1.  **If this was a formal [PostHog Experiment](/docs/experiments.md)**, open its [results page](/docs/experiments/analyzing-results.md) directly and add a Stripe revenue metric there. PostHog computes exposed-vs-control for you natively, no SQL needed.
2.  **If it was a plain feature flag** instead, connect [Stripe](/docs/cdp/sources/stripe.md) via [Data pipeline > Sources](/docs/data-warehouse/sources.md), then build a [Trends](/docs/product-analytics/trends/overview.md) insight of `$feature_flag_called` broken down by `$feature_flag_response` to see the exposure split.
3.  **Join to revenue** using the [SQL editor](/docs/data-warehouse/sql.md) or asking PostHog AI to compare post-exposure revenue and retention between variants in one query.

See also: [Features & revenue](/pocket-guides/data-stack/features-drive-revenue.md) · [Channels & retention](/pocket-guides/data-stack/acquisition-channels-retention.md)

[‹ Lead scoring](/pocket-guides/data-stack/lead-scoring.md)[All guides](/pocket-guides.md)p. 9 of 15[Foundations ›](/pocket-guides/data-stack/warehouse-foundations.md)