Capturing revenue data with PostHog

Last updated:

|Edit this page
Tip: Get this intro to PostHog as a private repo you can share with your team. Learn the basics while documenting the specifics of your integration.

While the analytics tasks so far have been full of subtlety, revenue is easy.

It's binary.

Either someone has given us money or they have not.

Basic revenue capture

Gathering data about revenue can be straightforward: we know exactly when the event happens, and hopefully we can back out from that event to imagine the precursor events we should also measure.

Start with the place in the product where money changes hands. Put an event there. In addition, capture metadata using event properties: how much money the customer paid and what they paid for. If we're selling subscriptions, record the subscription timeframe. If we're selling products, include the products they purchased. For example:

subscription_purchased
months: 12
price: 19.99

Try to keep property values strictly numeric – months: 12 instead of term: 12_months – to preserve flexibility in building reports later on.

Even if we don't have a lot of variation in what we're selling at first, record the details now so that later expansions, experiments or sales compare easily with historical data.

Now let's think about the critical path before payment happens. What are the stages or actions that are impossible to bypass to make a purchase?

These should have events tracked as well. Again, adding metadata to the event properties can help build better reporting and answer questions in the future.

If we've got an upsell or call to action that lists a specific price, that's a great property to include in the event properties

Automating revenue capture with data warehouse

Even at the earliest stages of a business, data can be scattered between multiple services, forcing you to constantly open multiple browser tabs just to keep up, which means your events might not give you all the data you need. Instead of setting up complex event-sending pipelines, you can bring the data directly into PostHog's data warehouse and analyze it all from there.

PostHog's data warehouse solves this problem by aggregating multiple data sources. Your dashboards can then report everything captured from data warehouse and analytics events in a single view. You can even build insights that traverse both.

You can query anything from your app database with data warehouse. Data warehouse also provides quick setup for ongoing capture of revenue events from Stripe and Chargebee.

Just don't forget to capture the actions leading to revenue.

Our revenue capture plan

pencil

We will report revenue via: [data warehouse or manual events?]

Our revenue-generating events are:

  • [add events here]

Revenue reporting

With revenue logged this way, we can build reports to understand how much revenue is captured over time. This is a great way to understand the health of a business.

A trends insight is a great start for your revenue reporting:

  • Create a new trends insight
  • Edit the series to choose your revenue-bearing event
  • In the aggregation menu to the right of the selected event, choose property value > sum
  • In the rightmost menu, choose the property that captures the revenue from your event

It will look like something like this:

Screenshot 2025-02-04 at 6 13 41 PM

From here we can choose the timespan for the report, grouping anywhere from hourly to monthly, with comparisons to the previous period if helpful.

Questions? Ask Max AI.

It's easier than reading through 585 docs articles.

Community questions

Was this page useful?

Next article

Understanding PostHog

PostHog is a lot of power, but to get the most from it, we should review the key ideas about how it all works. Properties Properties show up on many PostHog data types. They're a great way to sift through large volumes of user activity, segment behavior and users, and otherwise make sense of your data. Events Events are the breadcrumbs of user activity. They show you what happened, when it happened, and who it happened to. Events have properties, and you can use these to filter and query them…

Read next article