Why Subscription Revenue Should Be Your Primary Onboarding Metric

Conversion rate measures the percentage of users who complete a purchase event, but this binary metric obscures crucial differences in user quality. A user who converts to an annual plan at premium pricing contributes far more business value than one who selects a discounted monthly trial, yet both count equally toward your conversion percentage. This creates optimization pressure toward maximizing volume rather than value.

The problem compounds when different onboarding variants attract users with different retention profiles. An aggressive discount might boost conversions by 40% while attracting primarily deal-seekers who cancel immediately after trial. Your conversion metric shows success while your actual revenue declines. Revenue as the primary metric prevents this mismatch between what you measure and what actually matters to your business.

Different subscription plans generate vastly different revenue outcomes, and your onboarding experience directly influences which plans users select. An onboarding flow that emphasizes annual savings might shift users toward yearly subscriptions, while one focused on low commitment could drive monthly sign-ups. These behavioral differences only become visible when you track actual revenue rather than conversion events.

Revenue measurement also captures the impact of pricing experiments within your onboarding. If you test showing different price points to different user segments, conversion rate alone cannot tell you whether a lower price that converts better actually generates more money. Revenue automatically calculates this tradeoff, showing whether the volume increase from a lower price compensates for the reduced per-user income.

To use revenue as your primary metric, your experimentation system must connect each purchase event back to the onboarding variant the user experienced. This requires persistent user identification that links the experiment assignment through to the purchase platform. Many teams struggle because their analytics tool assigns variants separately from their subscription infrastructure.

The technical solution involves using a consistent user identifier across both systems. When your experimentation platform records which variant a user saw, it should use the same ID that your subscription system will report when that user makes a purchase. This matching allows revenue attribution to flow back to the correct experimental condition, making revenue measurement practical for daily optimization decisions.

Initial purchase revenue only tells part of the story for subscription businesses. Users who convert but request refunds within days generate zero actual revenue despite showing as conversions. Similarly, users who start a subscription but cancel before the first renewal represent far less value than the initial transaction suggests. Your revenue metric should eventually reflect these outcomes.

Most teams start by measuring revenue at the point of initial purchase, then layer in longer-term tracking as their data infrastructure matures. A practical approach tracks first-purchase revenue for weekly experiment decisions, while monitoring 30-day and 90-day cohort revenue to catch retention problems. This multi-timeframe approach balances the need for fast iteration with the reality that subscription value reveals itself over months.

Switching to revenue as your primary metric requires coordination between your product, data, and growth teams. Your experimentation platform needs access to purchase events with revenue amounts, user identifiers that match between systems, and aggregation logic that calculates revenue per variant. Many teams find that existing analytics tools track these elements separately but lack the integration layer to connect them.

Tools like Spinosis specifically address this challenge for mobile subscription apps by directly attributing RevenueCat purchases when the App User ID matches the experiment user identifier. This architecture eliminates the manual data joining that otherwise makes revenue-based experimentation technically complex. Once revenue tracking works reliably, you can make it the default metric for paywall and onboarding experiments, with other metrics serving as supporting context rather than primary decision factors.