> 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? – Context Warehouse pocket guide

[](/pocket-guides.md)Aa

[](/pocket-guides/context-warehouse.md)[](/pocket-guides/context-warehouse/onboarding-conversion.md)

# Which features drive revenue? – Context Warehouse 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.

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

## 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/context-warehouse/feature-revenue-impact.md) instead.

posthog-features-drive-revenue/SKILL.md

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

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

[‹ Start here](/pocket-guides/context-warehouse.md)[All guides](/pocket-guides.md)p. 1 of 15[Which onboarding steps turn trials into paying customers? ›](/pocket-guides/context-warehouse/onboarding-conversion.md)