Subscription analytics is often split between tools that do not share a user story. Product analytics sees feature use. Billing sees invoices and subscription states. Payment systems see attempts and declines. Support sees the customer after those systems disagree.
A subscription funnel should connect the states that create and preserve access:
eligible → activated → upgrade intent → checkout → paid subscription → entitled use → renewal → continuationThe funnel is not finished when the first payment succeeds. Recurring revenue depends on the product delivering the promised access and making renewal understandable and reliable.
Model business states explicitly
Start with states the backend can verify: trial or plan eligibility; trial started; first value reached; upgrade or subscribe intent; and plan selected.
Also examine payment submitted; payment authorized or invoice paid; subscription created and active; entitlement granted; and first paid value received.
Include renewal attempted and paid and subscription continued, changed, paused, or canceled.
Client events help explain the experience but should not define financial truth. A subscription_started event emitted before server confirmation can create false conversion. A paid invoice without entitlement can hide a serious post-payment leak.
Use several funnels for different decisions
One long funnel becomes difficult to interpret because not every subscriber starts the same way. Keep related views:
Trial-to-paid funnel
Measures whether trial users reach value, show upgrade intent, and complete a healthy paid transition.
Direct subscription funnel
Measures plan selection, checkout, payment, subscription creation, entitlement, and first paid use for users who buy without a trial.
Renewal funnel
Measures eligible renewals, attempted charges, paid invoices, continued entitlement, and return to product value.
Plan-change funnel
Measures upgrade or downgrade intent, proration communication, payment if required, new entitlement, and adoption of the changed plan.
The same event name can carry different meaning across these paths. Keep the entry condition and commercial motion visible.
Separate subscription conversion from payment success
Payment is one transition. The user expects a usable subscription.
Track:
| Measure | Healthy end state |
|---|---|
| Checkout completion | Valid commercial request completed |
| Payment success | Authorized or paid according to billing truth |
| Subscription creation | Correct plan and status exist |
| Entitlement success | Product access matches the subscription |
| First paid value | User receives the upgraded capability |
A decline affects payment success. A webhook or application bug may affect entitlement success after payment. A confusing plan may reduce checkout starts without causing a technical error.
Attach product context to commercial events
When a user starts a trial, selects a plan, or cancels, preserve safe context about the product experience: session and account identifiers; plan and trial model; role and workspace state; activation state and time to value; recent issue or failure signals; platform, device, release, and route; and last meaningful product action.
Avoid sending sensitive billing data into replay or general analytics. The join should work through safe internal identifiers and controlled systems.
Product context helps distinguish a plan problem from a broken experience. Subscribers who cancel after repeated errors need a different response from inactive accounts that never configured the product.
Inspect the path before upgrade intent
The upgrade screen is not always where subscription conversion is won or lost. Users arrive with a history of value, uncertainty, and friction.
Compare sessions for users who: viewed pricing but did not start checkout; started checkout but did not submit payment; submitted payment but did not reach active entitlement; reached active entitlement but did not use the paid capability; and successfully adopted the paid capability.
The comparison shows whether the leak belongs to value communication, plan selection, checkout, billing consistency, or paid onboarding.
Treat cancellation as a journey, not one event
Cancellation can express voluntary churn, temporary budget pressure, a failed experience, or a plan mismatch. Capture the explicit reason when the user provides it, but do not rely on the form alone.
Review the preceding product evidence: Did usage decline gradually or stop after an issue? Was the account activated? Did key users or teammates disappear? Did errors, crashes, or slow requests increase? Did the user visit limits, billing, support, or export surfaces? Was the final high-intent session successful?
Behavior does not replace the user’s stated reason. It adds the operational context needed to decide whether the fix is product, reliability, packaging, support, or billing.
Analyze renewals by outcome and recovery
For renewal cohorts, keep voluntary and involuntary outcomes separate.
Relevant evidence includes renewal paid on first attempt; renewal paid after retry or method update; renewal pending within grace period; renewal failed and entitlement changed; user canceled before renewal; and subscription state and entitlement disagree.
Measure time to recovery and continued product use after recovery. A saved payment without restored access is not a complete recovery.
Find leaks caused by state disagreement
Recurring systems are asynchronous. Webhooks arrive late, retries overlap, plan changes prorate, and users return from external billing portals.
Monitor contradictions such as: paid invoice with inactive subscription; active subscription with missing entitlement; canceled subscription with continued billing; upgraded plan with old limits; successful method update followed by repeated dunning; and client showing stale plan after server change.
These are revenue and trust issues. Reconcile automatically where safe and attach the affected user sessions for engineering investigation.
Connect releases to subscription movement
A release can change upgrade visibility, checkout state, entitlement logic, or the value users receive before renewal. Keep release markers beside subscription conversion and failure metrics.
When a metric changes, compare the affected transition by version and platform. Then open successful and failed sessions from the same commercial motion. This avoids blaming pricing for a release-specific defect.
A monthly subscription review with product evidence
Begin with the current subscription stock: active, trialing, past-due, paused, and canceled accounts. Then review movement through trial-to-paid conversion, direct purchase, renewal, recovery, and cancellation. Payment, subscription creation, and entitlement should have separate success rates. Finish with first paid value and the repeated product or technical friction that preceded failed outcomes.
The final line is what turns a subscription report into product work.
Follow the full subscriber state
Rejourney follows the subscriber through product use, the offer, payment, entitlement, renewal, and cancellation while retaining the sessions around each transition. This makes it possible to distinguish a commercial choice from a broken or confusing product path.
The in-app subscription analytics guide covers store-based apps; payment failure analytics covers recovery and reconciliation.