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

# Which features drive 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.md)[](/pocket-guides/data-stack/onboarding-conversion.md)

# Which features drive revenue? – Data Stack pocket guide

Feature usage and feature *value* aren't the same thing. This skill joins Stripe revenue to feature-usage events and ranks your features by the revenue of the accounts that use them. Don't mistake the loudest feature in your analytics for the most valuable one.

## Example data and how to read it

The Skill looks for patterns like Fig. 1: `exported_data` isn't the most-used feature, but the accounts that use it are worth nearly eight times as much per account as the ones using the most popular feature `viewed_onboarding_tips`.

| Feature | Accounts using | Revenue of users | Revenue/account |
| --- | --- | --- | --- |
| `invited_teammate` | 812 | $612,400 | $754 |
| `created_dashboard` | 1,204 | $580,900 | $482 |
| `exported_data` | 340 | $301,200 | $886 |
| `viewed_onboarding_tips` | 2,890 | $410,000 | $142 |

Fig. 1 – Example data: features ranked by the revenue of the accounts that use them.

## Get an agent to do the work

Copy the Skill below and add it to your agent. The Skill enables your agent to find your feature-usage events, confirming with you which ones count as "features" since every product defines this differently. It works out how a PostHog person or group maps to a Stripe customer, and approximates MRR from active subscriptions or recent invoices. It joins the two, ranks features by the revenue of their users, and saves the result as a table insight instead of a one-off answer in chat.

This ranks *existing* features by adopter revenue rather than testing a before/after change. For a specific rollout's revenue impact, see [Feature revenue impact](/pocket-guides/data-stack/feature-revenue-impact.md) instead.

posthog-features-drive-revenue/SKILL.md

```markdown
---
name: posthog-features-drive-revenue
description: >
  Rank a PostHog user's product features by the revenue of the customers who use them (joins Stripe MRR/invoices to
  feature-usage events) and save it as a reusable PostHog insight. Use this whenever someone asks which features
  their highest-revenue or best customers use most, wants revenue-weighted feature adoption, wants to tie existing
  feature usage to MRR/ARR, or wants to decide which features to invest in based on paying customers. Triggers on
  phrasings like 'which features drive revenue', 'what do our best customers use', 'revenue by feature', 'connect
  Stripe revenue to feature usage', or 'which features should we double down on'. Boundary: this ranks EXISTING
  features by adopter revenue, it is not a before/after test. For whether a specific rollout, experiment, or feature
  flag moved revenue use posthog-feature-revenue-impact; for revenue by acquisition channel or ad spend use
  posthog-acquisition-channels-retention. It sets up the Stripe warehouse source if needed and builds the insight
  end-to-end.
---

# Which features drive revenue?

**Question:** Which product features do our highest-revenue customers use most?
**For:** Product & PMM · **Difficulty:** Beginner · **Shape:** one SQL/HogQL query
**Data sources:** PostHog events (feature usage per account) + Stripe (MRR & invoices per customer)

## What this produces

A saved PostHog insight — a table of features ranked by the revenue of the accounts that use them — so the user can
see which features their paying customers actually rely on, and spot high-revenue accounts that haven't adopted a
top feature yet.

## Workflow

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

### 1. Identify the pieces in this project

- **Feature usage events.** Use `event-definitions-list` to find the events that represent meaningful feature use
  (not pageviews). Confirm with the user which events count as "features" — every product defines this differently.
- **The account/customer key.** Work out how a PostHog person or group maps to a Stripe customer. Usually
  `person.properties.email` ↔ `stripe_customer.email`, or a stored `stripe_customer_id`. If the product is
  account-centric, the key may live on a group.
- **Revenue per customer.** Approximate MRR from active `stripe_subscription` items, or use recent `stripe_invoice`
  totals. See the money/time gotchas in the shared reference (amounts are in cents; state your MRR method).

### 2. Build and validate the query

Start from this shape and adapt the event/property/column names to what actually exists. Validate with `query-run`
and iterate until it returns sensible rows.

```sql
-- Features ranked by the revenue of the accounts that use them.
-- Adapt: event names, the email/customer join key, and the MRR source for your project.
WITH customer_revenue AS (
    SELECT
        lower(email) AS email,
        -- Approximate account MRR; swap for your real revenue logic.
        sum(amount) / 100.0 AS revenue
    FROM stripe_invoice
    WHERE status = 'paid'
      AND created >= now() - INTERVAL 90 DAY
    GROUP BY lower(email)
)
SELECT
    e.event AS feature,
    count(DISTINCT e.person.id) AS accounts_using,
    round(sum(cr.revenue), 2) AS revenue_of_users,
    round(sum(cr.revenue) / nullif(count(DISTINCT e.person.id), 0), 2) AS revenue_per_account
FROM events AS e
INNER JOIN customer_revenue AS cr
    ON lower(e.person.properties.email) = cr.email
WHERE e.timestamp >= now() - INTERVAL 90 DAY
  -- Optional: restrict to the events you consider "features".
  -- AND e.event IN ('created_dashboard', 'ran_query', 'invited_teammate')
GROUP BY e.event
ORDER BY revenue_of_users DESC
LIMIT 50
```

Tips: exclude noise events; if the natural key is a group, join on the group property instead of person email;
consider weighting by distinct accounts rather than raw event counts so a few heavy users don't dominate.

### 3. Save the insight

Create a SQL/HogQL insight (per the shared reference) named "Features ranked by customer revenue", described with
the MRR method and date window you used, shown as a table. Return the URL and give the user the plain-English read:
which features skew toward high-revenue accounts.

## Self-driving development (offer this)

With a revenue-weighted feature ranking, the user can spot high-revenue accounts that haven't adopted a top feature
and nudge them there. Offer to help set up an in-product prompt, a survey, or an experiment targeting those
accounts — improving activation automatically.
```

Show full example

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

## Doing this by hand

1.  **Connect [Stripe](/docs/cdp/sources/stripe.md).** In PostHog, go to [Data pipeline > Sources](/docs/data-warehouse/sources.md) and connect Stripe if it isn't already connected; you'll need a restricted API key with read access to Billing.
2.  **Find your feature [events](/docs/data/events.md).** Check Data management > Events for the events that represent feature use.
3.  **Write the join.** Open the [SQL editor](/docs/data-warehouse/sql.md) and join `events` to `stripe_invoice` or `stripe_customer` on email. The schema tab on the left shows your project's real column names. You can also ask PostHog AI to do this part for you.
4.  **Save it as an insight** so you don't have to re-run the query by hand next time.

See also: [Feature revenue impact](/pocket-guides/data-stack/feature-revenue-impact.md) · [Channels & retention](/pocket-guides/data-stack/acquisition-channels-retention.md)

[‹ Introduction](/pocket-guides/data-stack.md)[All guides](/pocket-guides.md)p. 1 of 15[Onboarding conversion ›](/pocket-guides/data-stack/onboarding-conversion.md)