Docs

Subscription Revenue and Product Usage Data Tracking

RevenueCat's GA integration into data warehouses makes it easy to join subscription revenue with product usage — here's what to track to make it useful.

Revenue

RevenueCat’s connector into PostHog’s data warehouse layer moved from beta to general availability this month, following a broader pattern across the analytics tooling space of subscription revenue data becoming a first-class join target alongside product usage events, rather than something that lives in a separate billing dashboard. The technical barrier to joining “what a user did in the app” with “what a user paid for the app” has effectively disappeared. What hasn’t disappeared is the modelling work needed to make that join actually answer a useful question, and most teams that flip the integration on don’t do that work — they get a wider table, not a better answer.

The failure mode is specific: teams join subscription and usage tables, build a single LTV-by-feature chart, and treat it as settled. But raw joined data conflates correlation with causation constantly — power users who already intended to pay show heavy feature usage before conversion, and that looks identical in the data to a feature that drives conversion. Without deliberate cohorting on the time axis relative to conversion, the join produces a plausible-looking chart that leads teams to invest in the wrong feature because it happened to be popular among people who were going to subscribe anyway.

Data Points to Track

  • Every usage event tagged with a stable user ID that matches the subscription platform’s customer ID, so the join doesn’t silently drop rows on ID mismatches between the two systems
  • Subscription state transitions (trial_started, trial_converted, renewed, cancelled, refunded) with timestamps precise enough to sequence against usage events, not just daily aggregates
  • Feature usage timestamped relative to conversion event, not just in absolute calendar time, so pre-conversion and post-conversion usage can be separated cleanly
  • Plan/price tier at time of each usage event, since usage patterns on a discounted trial tier often don’t hold once someone converts to full price
  • Refund and cancellation reason codes, joined back to the usage data from the days immediately preceding the cancellation, to distinguish “never used it” churn from “used it and it didn’t work” churn

Setup Steps

  1. Standardise the user identifier across your product analytics tool and your subscription platform before enabling any data warehouse join, since a mismatched ID scheme (anonymous ID vs. authenticated ID vs. platform customer ID) will quietly drop or duplicate rows.
  2. Backfill subscription state history, not just current state, so trend analysis isn’t limited to the window since the integration went live.
  3. Build the join as a dbt model or equivalent versioned transformation rather than an ad hoc dashboard query, so the logic for how usage and revenue tables relate is documented and reusable.
  4. Separate pre-conversion and post-conversion usage explicitly in the model, using the conversion timestamp as an anchor rather than comparing usage across arbitrary calendar periods.
  5. Validate the joined data against known-good numbers from each source system independently — total revenue from the subscription platform, total active users from product analytics — before trusting any derived metric.

Actionable Insights

A feature that’s heavily used before conversion but drops off sharply after is very likely correlated with intent-to-pay, not causing it — treat it as a signal of purchase-ready users to target, not a feature to invest more engineering time into. A feature that’s rarely used before conversion but grows steadily afterward is a stronger candidate for actually driving retention and expansion revenue, and deserves the investment the pre-conversion feature was getting by default. And if refund reasons cluster around a specific feature or a specific point in the usage timeline, that’s a fixable product gap sitting directly in the revenue data — one that’s invisible if usage and subscription data stay in separate tools.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert