How to Attribute RevenueCat Purchases to Onboarding Variants
·RevenueCat
To attribute RevenueCat purchases to onboarding variants, you need to match the App User ID from RevenueCat with the user identifier in your experiment system. This matching enables you to connect every subscription event—trial starts, conversions, renewals, and cancellations—back to the specific onboarding experience each user saw.
The technical implementation requires capturing the same user identifier in both systems at the moment of assignment. When a user enters your experiment, record their variant alongside their App User ID, then configure your analytics pipeline to join RevenueCat webhook events or API data with your experiment data using this shared identifier as the key.
Why App User ID is the Bridge Between Systems
RevenueCat uses the App User ID as the primary identifier for tracking all subscription activity. This identifier persists across app sessions and device changes when properly configured, making it the most reliable anchor point for attribution. Unlike device IDs or advertising identifiers, the App User ID remains consistent even when users reinstall your app or switch devices, ensuring long-term tracking accuracy.
Your experiment platform needs access to this same identifier to create the connection. At the point of variant assignment—typically during app launch or first session—capture both the experiment variant and the App User ID together in your data warehouse or analytics system. This pairing creates the foundation for all downstream attribution, allowing you to segment revenue metrics by the onboarding experience each cohort received.
Setting Up the Technical Integration
The integration starts with ensuring your App User ID is set before you assign experiment variants. In your app code, initialize RevenueCat and retrieve or set the App User ID, then immediately pass this identifier to your experiment assignment logic. This sequencing guarantees that the same user identity exists in both systems from the first moment of the user journey.
Configure RevenueCat webhooks to send subscription events to your data pipeline, or set up scheduled pulls from the RevenueCat API if you prefer batch processing. Your data warehouse should store both the experiment assignment table (user ID, variant, timestamp) and the RevenueCat events table (user ID, event type, revenue, product ID, timestamp). Join these tables on the App User ID field to create your attribution dataset.
Handling Anonymous Users and Identity Changes
Many apps start users with an anonymous ID before account creation, which creates an attribution challenge if users later sign in or create an account. RevenueCat supports aliasing to merge anonymous and identified user profiles, and your experiment system needs to respect these same aliases. When a user transitions from anonymous to identified, ensure both systems receive the alias mapping so historical experiment assignments remain connected to future purchase events.
Document your identity resolution strategy clearly because edge cases will emerge. Some users will reinstall the app, some will restore purchases on new devices, and some will contact support to resolve account issues. Each scenario requires careful handling to maintain attribution accuracy. Build logging around identity transitions so you can audit attribution paths when revenue numbers don't match expectations.
Calculating Variant-Level Revenue Metrics
Once your attribution pipeline is flowing, you can calculate the metrics that matter for onboarding experiments: conversion rate from trial start to paid, average revenue per user by variant, time to first purchase, and lifetime value projections. Group all RevenueCat events by the experiment variant field, then aggregate using standard SQL or your analytics tool's segmentation features. Be sure to filter by experiment start date so you only include users who were actually exposed to the test.
Pay special attention to the time windows you analyze. Subscription revenue accrues over weeks and months, so declaring a winner based on three days of data will mislead you. Set appropriate evaluation periods based on your typical trial length and renewal cycles—usually at least 30 days for monthly subscriptions, and longer for annual plans. Track early indicators like trial starts and conversion rates while waiting for revenue data to mature.
Using Experiment Platforms That Handle Attribution
Building this attribution infrastructure yourself requires significant engineering time and ongoing maintenance as both your app and the RevenueCat API evolve. Experiment platforms designed for subscription apps handle the integration complexity for you, automatically matching App User IDs between systems and calculating variant-level revenue metrics without custom data pipelines. These platforms typically offer real-time dashboards showing how each onboarding variant performs on subscription metrics.
Spinosis provides this attribution capability as part of its experimentation API for mobile subscription apps. When you assign variants through Spinosis, it automatically tracks the App User ID and attributes RevenueCat purchase events when the identifiers match, eliminating the need for custom data warehouse joins. This approach lets product teams focus on designing better onboarding experiences rather than building attribution infrastructure.
Questions
What happens if the App User ID changes during the experiment?
If a user's App User ID changes mid-experiment due to account linking or device transfer, you need aliasing to maintain attribution. RevenueCat supports alias calls that merge user histories, and your experiment platform should respect these same aliases. Without proper aliasing, you'll lose the connection between the original variant assignment and subsequent purchases, understating your variant's performance. Always log identity transitions to debug attribution gaps.
Can I attribute purchases that happen weeks after the experiment ends?
Yes, attribution should work indefinitely because users retain their assigned variant as long as you keep the assignment record. A user assigned to variant B on day one of your experiment should still be counted in variant B's metrics if they convert 60 days later, even if the experiment has concluded. This persistent attribution is crucial for measuring long-term effects and lifetime value differences between onboarding approaches.
Should I attribute refunds and cancellations to variants?
Absolutely. Complete attribution includes negative events like refunds, cancellations, and subscription downgrades, not just positive revenue events. These metrics reveal whether a variant attracts users who stick around or whether it drives short-term conversions that don't retain. Pull all RevenueCat event types into your attribution logic—renewals, cancellations, billing issues, refunds, and plan changes—to get an honest picture of each variant's impact on subscription health.
Turn on auto-optimize for one test.
Create a project, install the SDK, connect RevenueCat. Traffic starts shifting on its own.