After moving onboarding to the web, our analytics got better, but stitching everything into one view took work. We push web events (quiz, plan viewed, checkout started, payment succeeded) into our warehouse, then merge subscription status from Stripe and entitlements from RevenueCat. The app sends activation and feature usage to the same tables.
Mapping identities was the tricky part. We generate a user key on web, pass it through deep link to the app, then let RevenueCat map the device to that user. Webhooks from billing update entitlements on our server and we forward to the app.
It mostly works, but I still see timing mismatches and a few ghost sessions where the app user never links to the web customer.
If you’ve got this clean, what’s your identity strategy and event schema? Are you pushing RevenueCat/Adapty webhooks directly to your warehouse, or normalizing through your backend first? Any dashboard examples that make churn, refunds, and reactivations crystal clear?
Single user id from your backend solves most of it.
Send web events with that id. Deep link passes it to the app. RevenueCat uses the same id for entitlements.
Web2Wave.com helped me keep the web funnel events consistent across versions.
Backend id everywhere. Web→app via deep link.
I forward Adapty webhook events to the warehouse and join on user id. I build the funnel on Web2Wave.com so the event names stay stable for dashboards.
Normalize webhooks through your server. Then you can fix naming and attach user ids before data hits the warehouse.
Cleaner dashboards and fewer surprises.
One id across web app and billing
Keep a contract:
- User id is the join key everywhere
- Web events and billing write to the same schema
- RevenueCat or Adapty webhooks flow into your backend, then to the warehouse
Add late-arriving logic for refunds and chargebacks so metrics do not flip days later without annotation. It saves a lot of confusion in weekly reviews.
We route webhooks to backend first. Easier to manage.