Docs

RevenueCat + PostHog Warehouse: What to Track

RevenueCat's PostHog Data Warehouse integration is now generally available — track identity mapping so revenue and behaviour events actually join.

Revenue

RevenueCat’s integration with PostHog Data Warehouse moved out of its beta rollout gate and into general availability in 2026, which removes a real barrier for subscription apps: revenue data (trial starts, renewals, refunds, entitlement changes) can now sit alongside product usage events in the same queryable warehouse, without a team building and maintaining a custom ETL pipeline just to ask “what did users who churned actually do in the days before they cancelled.” Before this, most teams either exported RevenueCat data manually on a schedule or paid for a separate reverse-ETL tool to stitch the two datasets together — both options that introduce lag and a second place for the join logic to quietly break.

The part worth being careful about is identity. RevenueCat identifies users by its own app_user_id, while PostHog tracks behaviour against a distinct_id that may or may not have been explicitly aliased to the same value at signup. If those two identifiers aren’t reliably linked before the warehouse sync runs, revenue events and behavioural events end up sitting in the same warehouse without actually joining — cohorts built on “trial starters” silently exclude or duplicate users, and nobody notices until a revenue-behaviour analysis returns numbers that don’t reconcile with RevenueCat’s own dashboard. A generally-available integration makes it easy to start querying immediately; it does nothing to guarantee the identity mapping underneath was set up correctly first.

Data Points to Track

  • app_user_id-to-distinct_id mapping coverage, measured as the percentage of RevenueCat users whose identifier successfully resolves to a matching PostHog identity, not assumed to be 100%
  • Sync latency between RevenueCat and the PostHog warehouse, since a lag of hours or a day changes whether a same-day churn investigation has complete data to work from
  • Revenue event completeness post-sync — trial starts, conversions, renewals, and refunds counted in the warehouse compared against RevenueCat’s own dashboard totals for the same period
  • Behavioural cohorts built on revenue events, such as “active users in the 7 days before a refund,” tracked as a standing query rather than a one-off analysis
  • Duplicate or orphaned identity records, where a revenue event has no matching behavioural history or vice versa, flagged as a data-quality signal rather than silently dropped from analysis

Setup Steps

  1. Audit how app_user_id is set relative to PostHog’s distinct_id at the point a user first authenticates, and add an explicit alias call if the two aren’t already linked at signup.
  2. Enable the RevenueCat Data Warehouse integration in PostHog and run an initial reconciliation between synced revenue totals and RevenueCat’s own dashboard for a known date range.
  3. Build one identity-mapping-coverage query as a standing check, run on a recurring schedule, rather than assuming the join stays healthy after the first successful sync.
  4. Construct the specific behavioural cohorts your team actually needs — pre-churn activity, pre-refund activity, feature usage before upgrade — as saved queries rather than one-off exports.
  5. Set an alert on sync latency or a sudden drop in matched identities, since either is usually the first visible symptom of an upstream change in how user IDs are assigned.

Actionable Insights

Once the join is verified, the highest-value query is almost always behavioural: what did users do in their last active session before a refund or non-renewal, compared against the same window for users who renewed. That comparison was previously locked behind a manual export-and-join process most teams didn’t run often enough to catch a pattern early. If identity-mapping coverage is below expectations after enabling the integration, treat that as a blocker to fix before trusting any cohort built on top of it — a revenue-behaviour join with a coverage gap doesn’t fail loudly, it just quietly under-represents the users you most need visibility into.

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