posthog-features-drive-revenue

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