Docs

PostHog RevenueCat Warehouse Sync: What to Track

PostHog's RevenueCat Data Warehouse sync is now GA — the subscription and revenue data checks worth running before you trust it.

Revenue

PostHog has taken its RevenueCat integration out of beta, making it generally available inside Data Warehouse without the earlier rollout gate. For product teams, that means subscription and revenue events — trials, renewals, cancellations, entitlement changes — now land directly alongside behavioural analytics, with no separate ETL pipeline to stitch the two together. That’s a genuine win for anyone building retention cohorts or LTV models that need both “what a user did” and “what a user paid” in one place.

The risk is trusting the join before you’ve checked it. A warehouse sync moves subscription state on its own schedule, not the moment an event happens, and RevenueCat’s own webhook delivery can lag or retry. If your product events say a user is active but the revenue side hasn’t caught up yet, a cohort report built the same day will misclassify paying users as free, or double-count a renewal that arrived as both a webhook and a backfilled sync row. Nobody notices until a revenue number disagrees with the RevenueCat dashboard everyone already trusts.

Data Points to Track

  • Sync latency between a RevenueCat event firing and the corresponding row appearing in PostHog’s warehouse tables
  • Row counts per sync run, compared against RevenueCat’s own event log for the same window, to catch silent drops
  • Customer ID mapping accuracy — whether RevenueCat’s app_user_id consistently joins to the same PostHog distinct ID
  • Entitlement status per user at time of query, checked against RevenueCat’s live entitlement state rather than a cached snapshot
  • Trial-to-paid conversion flag completeness, since a missed transition event silently misclassifies revenue cohorts
  • Duplicate event rate where webhook delivery and warehouse backfill both write the same transaction

Setup Steps

  1. Enable the RevenueCat Data Warehouse source in PostHog and confirm it’s running on GA, not the earlier beta connector.
  2. Map customer IDs explicitly rather than relying on default identity matching, and spot-check a sample of users against RevenueCat’s dashboard.
  3. Run a parity query comparing daily active subscriber counts from the synced warehouse tables against RevenueCat’s own reporting for the same date range.
  4. Set a sync freshness alert so a stalled or delayed sync run is caught before a revenue cohort report is built on stale data.
  5. Document the dedup key used to collapse webhook and backfill duplicates, and verify it’s applied consistently in any downstream query or dashboard.

Actionable Insights

Once the parity check is running, the gap between your synced subscriber count and RevenueCat’s own total becomes the single number worth watching: a small, stable gap means the join is trustworthy enough to build LTV and retention cohorts on top of it, while a growing or inconsistent gap means the identity mapping or sync timing needs fixing before any revenue-weighted analysis is safe to ship. Treat every cohort report that blends behavioural and subscription data as provisional until that parity number has held steady for at least one full billing cycle.

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