What revenue analytics is actually joining
PostHog's revenue-analytics layer connects a billing or payments source (commonly Stripe, or another supported provider) to PostHog's person/account model, so revenue events sit alongside product usage in the same interface. The point is answering questions like "which usage pattern correlates with expansion revenue" without exporting data into a spreadsheet or a separate BI tool to join it by hand.
Connecting customers correctly
The join between a billing-system customer and a PostHog person or group depends entirely on a reliable shared identifier - an email, a customer ID, or an account ID present in both systems. If that identifier is inconsistent (different casing, a customer merged or split in the billing system without updating PostHog, a person identified differently pre- and post-signup), the join silently drops or misattributes revenue rather than erroring loudly.
Defining revenue metrics deliberately
| Metric decision | Why it needs to be explicit |
|---|---|
| Recognition timing | Whether revenue is attributed at invoice date, payment date, or a recognized-revenue schedule changes every downstream number - pick one and document it |
| Refunds and credits | Whether they net against the period they occurred in or the original revenue period affects trend accuracy |
| Currency handling | Multi-currency billing needs a consistent conversion approach if revenue is being summed across currencies |
| Expansion vs. new vs. churned | A single "revenue" number hides whether growth is coming from new accounts or expansion of existing ones - break it out explicitly |
Exact source connectors and metric-configuration options are still an evolving part of PostHog's product - verify current source support and metric definitions against PostHog's own revenue-analytics docs rather than assuming feature parity with a mature dedicated billing-analytics tool.
How to verify it worked
- Reconcile PostHog's revenue-analytics total for a recent, closed period against the actual number from your billing system for the same period - any discrepancy needs to be explained, not rounded away.
- Spot-check five accounts individually: does the revenue PostHog attributes to each match what you know from the billing system directly?
- Confirm refunds and credits show up in the metric the way you decided they should (netted against original period or the period they occurred), not however the default happened to land.
- If segmenting revenue by a product-usage cohort, confirm the cohort membership and the revenue figures are drawn from the same time window - a common quiet bug is comparing usage from one period against revenue attributed to a different one.