App subscription analytics: the complete guide

What is app subscription analytics? The short answer

App subscription analytics is the practice of measuring how a paid app earns and keeps recurring revenue, and connecting those revenue outcomes to the product behaviour that caused them. The revenue side is a well-defined set of metrics: monthly recurring revenue (MRR), trial-to-paid conversion, subscriber and revenue churn, retention, net revenue retention (NRR), and lifetime value (LTV). The behaviour side is ordinary product telemetry: which screens users see, which features they use, how far they get in onboarding. Subscription analytics is the discipline of holding both in the same view so you can explain one with the other.

What separates it from generic product analytics is a single requirement: it has to be joined to verified revenue. A tool that only sees taps and screens can tell you a user opened the export feature; it cannot tell you that users who opened export in their first week renewed at a noticeably higher rate, because it has no idea who renewed. The moment you want to connect a product decision to money — which is the only reason a paid app measures anything — you need behaviour and revenue in the same timeline. That connection is the entire subject of this guide, and the place most analytics setups quietly fail.

The rest of this piece is the long version: why the join matters so much (we call it the cross-match), the exact metrics worth tracking and how each is calculated, how to instrument an iOS or SwiftUI app and a Next.js or web app to capture them, how to do all of it privacy-first, when to build versus buy, an honest comparison with single-purpose analytics tools that cannot see revenue, and a decision framework you can apply to your own stack. We build a platform that does the cross-match, and we open-source parts of it, so the examples are first-hand rather than theoretical — and where a number is illustrative, it is labelled as such.

Why app analytics must connect to revenue events

A product event on its own cannot tell you whether it made money. This is the load-bearing idea of the whole field, so it is worth stating plainly. Behavioural analytics records that something happened — a screen was viewed, a button was tapped, a feature was used. Revenue lives in a different system entirely: the App Store, Google Play, and Stripe emit purchases, renewals, refunds, upgrades, and cancellations. If those two streams never meet, you are left with two half-answers. Product analytics shows engagement with no idea whether it converts. Billing dashboards show money with no idea what earned it. Neither can answer a question that spans them.

And every important question spans them. Which feature drives paid conversion? Does finishing onboarding actually change retention? What were users doing in the week before they churned? Which cohort has the best lifetime value, and what did that cohort do differently? Each of these needs a single record where a person's behaviour and their revenue sit side by side. We wrote a dedicated piece on this exact failure mode — why your app analytics should connect to revenue events — because it is the most common and most expensive gap we see in paid-app stacks.

We call the join the cross-match: telemetry, verified subscriptions, entitlements, and errors resolved to one identity, so a product action and the money it produced live in the same timeline. The word "verified" is doing real work there. It is not enough to guess at subscription state from a client flag or a locally cached receipt; the state has to be confirmed against the rail, because a client can be wrong, offline, tampered with, or simply stale. Analytics built on unverified revenue produces confident charts of the wrong numbers.

What the split stack costs you

The default setup for a paid app is two tools bolted together: a product-analytics SDK for behaviour and a billing tool or store dashboard for revenue. It feels reasonable and it is where almost everyone starts. The cost shows up later, as three recurring taxes.

• Every cross-system question becomes a manual export. To ask "did users who used feature X renew?", someone pulls a user list from the analytics tool, pulls a renewal list from billing, and joins them in a spreadsheet by hand — if the two systems even share an ID. It is slow, it is error-prone, and it means the question usually just does not get asked.
• Identity drifts. The analytics tool keys on a device or anonymous ID; the billing system keys on a store transaction and an account. Reconciling them is its own project, and it breaks whenever a user reinstalls, switches devices, or upgrades on a different rail than they signed up on.
• The numbers disagree. The store dashboard, the billing tool, and the analytics tool each count "active subscribers" slightly differently — one includes billing-retry, one excludes refunds late, one counts by device. When your dashboards disagree, you stop trusting all of them.

None of this is a knock on any single tool. Each is good at its job. The problem is architectural: the join was never designed in, so it has to be recreated by hand every time a real question comes up. The alternative is to make the joined timeline the foundation and read behaviour and revenue off the same record. That is the difference between analytics that looks impressive in a demo and analytics you actually make decisions from.

The subscription metrics that actually matter

There is a long list of things you can measure and a short list that changes decisions. For a subscription app, the short list is the recurring-revenue metrics below, plus the product signals that move them. Track the headline number and the behaviour behind it together — a churn number with no idea what preceded the cancel is a thermometer with no thermostat.

Here is the core set at a glance, with what each answers and the trap that most often distorts it. Every one is covered in depth in the sections that follow.

Two organising ideas run through all of them. First, cohorts beat running totals. Almost every one of these metrics lies to you when measured as a single moving number and tells the truth when grouped by the period a customer joined. Second, revenue beats headcount. When a metric can be measured in customers or in dollars, the dollar version is the one you act on, because your customers do not all pay the same amount. Keep those two rules in mind and most subscription-metric mistakes disappear. If you want a hands-on companion to this section, our guide to building an app analytics dashboard walks through assembling these into a working view.

MRR and ARR: the recurring-revenue baseline

Monthly recurring revenue (MRR) is the total predictable subscription revenue normalised to a single month. Annual recurring revenue (ARR) is simply MRR times twelve. MRR is the heartbeat of a subscription business: it is the number that should trend up and to the right, and the number every other metric ultimately explains. To calculate it, take every active subscription, convert its price to a monthly figure (an annual plan at, say, $60 contributes $5 to MRR, not $60), and sum them.

The discipline is in what you include. MRR is recurring revenue only — a one-off unlock, a consumable, or a lifetime purchase is not MRR, even though it is real money, because it does not repeat. Mixing one-off sales into MRR inflates it and destroys its predictive value. Read your revenue by rail and by type — recurring versus one-off — and keep the recurring bucket clean.

The more subtle discipline is list price versus collected amount. A plan's sticker price is not what lands. Trials, introductory offers, promotional discounts, region pricing, and the store's commission all sit between the price tag and the money you keep. Two apps with identical "MRR by list price" can have very different real revenue. This is why we insist that revenue metrics read from the ledger — the record of amounts actually collected — rather than from the price you advertise.

The MRR movements that explain the trend

A single MRR number tells you the level; the movements tell you the story. Decompose the change month over month into its components, because a flat MRR can hide a lot of churn masked by a lot of new sales.

• New MRR — revenue from brand-new customers this period.
• Expansion MRR — upgrades and add-ons from existing customers.
• Contraction MRR — downgrades from existing customers (negative).
• Churned MRR — revenue from customers who cancelled (negative).
• Reactivation MRR — revenue from previously churned customers who came back.

Net new MRR is the sum of those five. When you can see them separately, a worrying pattern that a headline number hides — say, healthy new sales quietly offset by rising churn — becomes obvious months earlier. And when your MRR movements are joined to behaviour, you can go one step further and ask what the expanding customers did that the contracting ones did not.

Trial-to-paid conversion: the metric your paywall lives or dies by

Trial-to-paid conversion is the share of trials that become paying customers. For most freemium and free-trial apps it is the single highest-leverage metric, because a small improvement compounds through every downstream number — more conversions means more MRR, a larger retained base, and higher LTV, all at once. To calculate it, take a cohort of trials that started in a defined window, count how many converted to a first paid renewal within the trial length plus a short grace period, and divide.

The word cohort is essential. Trial-to-paid measured as a running total is one of the most misleading numbers in all of analytics, because it moves for the wrong reasons. Launch a campaign that brings in a flood of new trials and your running conversion rate drops the next day — not because your paywall got worse, but because the denominator filled with trials that have not had time to convert yet. Group by the day or week the trial started, wait for each cohort to mature, and the number becomes honest. We cover the mechanics end to end in how to track trial-to-paid conversion in a mobile app.

Why the trial only makes sense joined to behaviour

Knowing your conversion rate is 32% (illustrative) tells you where you stand. It tells you nothing about how to move it. That requires the cross-match: joining each trial to what the user actually did during it. When you do, a pattern almost always emerges — users who completed a specific activation step, or used a particular feature, or reached a certain screen before the paywall convert at a much higher rate than those who did not. That step is your real onboarding goal, and it is invisible to any tool that sees the trial outcome but not the trial behaviour, or the behaviour but not the outcome.

This is the clearest example of why revenue and behaviour have to live together. A billing tool knows the trial converted. A product-analytics tool knows the user used feature X. Only a joined timeline knows that this user used feature X and then converted — which is the sentence you can actually act on. Instrument the activation steps, join them to the conversion event, and you have a map from product decisions to revenue.

Churn and retention: subscriber churn is not revenue churn

Churn is the rate at which customers or revenue leave; retention is its mirror — the rate at which they stay. The most important thing to get right here is that there are two different churns and they are not the same number. Subscriber churn counts customers who cancelled. Revenue churn counts the recurring revenue that left with them. They diverge the instant your customers pay different amounts, which is always.

Consider two months with identical subscriber churn (illustrative). In the first, ten trialists on a cheap monthly plan cancelled. In the second, one power user on an annual team plan cancelled. Headcount churn calls these equal; revenue churn — correctly — calls the second one much worse. If you optimise against subscriber churn alone, you will happily fight to save low-value cancellations while a handful of high-value ones walk out unnoticed. Track both, and weight your attention by revenue churn.

Voluntary vs involuntary churn

Not all churn is a decision. Voluntary churn is a customer choosing to cancel. Involuntary churn is a payment that failed — an expired card, an insufficient balance, a billing-retry that ran out — and the customer never meant to leave. The two need completely different responses. Voluntary churn is a product and value problem; involuntary churn is a recovery problem solved with retries, grace periods, and dunning. Lumping them together hides an easily recoverable chunk of lost revenue. A subscription analytics view worth its name separates them, so you can see how much of your churn is a customer walking away versus a card you could win back.

Retention read by cohort

Retention is churn's positive twin, and like every metric here it should be read by cohort. A retention curve for a cohort — the share of a given month's new subscribers still active after 1, 2, 3… months — tells you whether the product keeps people. Watching successive cohorts' curves tells you whether it is getting better or worse. An app can post steady blended retention while every recent cohort quietly retains worse than the last, because the healthy old cohorts dominate the average. Cohorts expose that; blended numbers bury it. To make retention actionable, join it to behaviour — the difference between a cohort that stayed and one that left is usually a difference in what they did in the first week.

Net revenue retention: does the base grow on its own?

Net revenue retention (NRR) measures how much recurring revenue a cohort of existing customers keeps over a period, including their upgrades and downgrades, but excluding any brand-new customers. It is the metric that reveals whether your existing base is an asset that grows by itself or a leaking bucket that new sales have to keep refilling. To calculate it: take a cohort's recurring revenue at the start of the period, add expansion (upgrades, add-ons), subtract contraction (downgrades) and churn, and divide the result by the starting revenue.

The interpretation is simple and powerful. NRR above 100% means the customers you already had are worth more now than they were at the start — expansion outran churn, and the business would grow even if you never signed another customer. NRR below 100% means the existing base is shrinking, and every new sale is partly just replacing lost revenue rather than adding to it. It is one of the truest measures of durable product value, which is why investors ask for it first. We wrote a full method for it in how to calculate and improve net revenue retention for app subscriptions.

The most common error is contaminating NRR with new customers — that turns it into ordinary growth and defeats the point, which is to isolate how the existing base behaves. The second most common error is forgetting downgrades, which flatters the number. For a consumer subscription app with few upgrade paths, NRR is dominated by churn and reactivation; for an app with tiers and seats, expansion can push it above 100%. Either way, tracking it forces you to look at the base you already won, not just the funnel bringing in new people — and improving it almost always comes back to the same lever as retention: join revenue to behaviour and act on what the expanding cohorts did.

Lifetime value: calculate LTV from the ledger, not list price

Lifetime value (LTV) is the total revenue a customer generates across their entire relationship with your app — and it must be calculated from the money you actually collected, not the price you advertise. This is the metric most often computed wrong, and the error always runs in the same direction: list-price LTV overstates reality, sometimes badly, because almost no cohort pays full sticker across its whole life.

There are two honest ways to compute it. The historical method sums the real amounts collected per customer from the ledger — every renewal actually paid, net of refunds and chargebacks and the store commission. This is exact but backward-looking. The predictive method estimates forward: divide average net revenue per user by your revenue churn rate to approximate the revenue a customer will generate over their expected lifetime. Use historical to know what happened; use predictive to plan acquisition spend.

Every row is a reason the number on the price tag overstates what a customer is worth. A subscription analytics system that reads from verified revenue — the amounts that actually settled, by rail — computes LTV correctly by construction, because it never sees the sticker in the first place; it sees the ledger. That is also why LTV is one of the clearest arguments for joining analytics to revenue: you cannot compute it at all from behavioural events, and you compute it wrong from list price. It requires the money.

LTV earns its keep when you pair it with acquisition cost. The LTV-to-CAC ratio — lifetime value divided by what it costs to acquire a customer — is the number that tells you whether growth is profitable or a treadmill. But the ratio is only as trustworthy as the LTV inside it, and a list-price LTV can make a losing acquisition channel look like a winner. Get the ledger-based number right first.

Cohort behaviour: the lens that makes every other metric honest

A cohort is a group of customers bucketed by something they share — most often the period they signed up — and cohort analysis tracks how that group behaves over time. Nearly every metric in this guide improves when read by cohort and misleads when read as a blended average, so cohorts are less a separate metric than a lens you apply to all of them.

The reason is that a subscription business is a stack of cohorts at different ages, and a single blended number smears them together. Blended retention, blended conversion, and blended LTV are all dominated by whichever cohorts are largest and oldest, which means a decline in your newest cohorts — exactly the signal you most need — can be completely hidden until it is too big to fix quietly. Cohorts separate the ages so each tells its own story.

• Acquisition cohorts (by signup month) reveal whether the product is getting better or worse at retaining and converting new customers over time.
• Behavioural cohorts (by an action taken — completed onboarding, used a key feature) reveal which behaviours predict revenue outcomes.
• Plan or rail cohorts (annual vs monthly, iOS vs web) reveal how economics differ by how and where customers bought.

Behavioural cohorts are where the cross-match pays off most directly. "Customers who used feature X in week one" is a cohort defined by behaviour, and comparing its retention and LTV against everyone else's is how you prove a feature drives revenue rather than just engagement. You cannot build that cohort in a tool that sees behaviour but not revenue, nor in one that sees revenue but not behaviour. It needs both on one timeline — which is the recurring theme of this entire guide.

Onboarding impact: connecting activation to revenue

Onboarding impact is the measurable effect of a user's first-run experience on whether they convert, retain, and pay over their lifetime. It is one of the most valuable things a paid app can measure, and one of the hardest, because it lives entirely at the intersection of behaviour and revenue: the onboarding steps are pure product telemetry, and their impact is pure revenue, so measuring the link requires both in one place.

The method is to define your activation milestones — the specific first-run steps you believe set a user up to get value — instrument each as an event, and then compare downstream revenue outcomes between users who reached each milestone and users who did not. When completing a milestone is associated with a large lift in trial-to-paid conversion or long-term retention, you have found an activation goal worth optimising the whole onboarding around. We go deep on the technique in how to measure onboarding impact on subscription revenue.

Two cautions keep this honest. First, correlation is not causation — users who complete onboarding may simply be more motivated to begin with, so the milestone predicts conversion without necessarily causing it. The way to move from correlation toward causation is an experiment: change the onboarding for a slice of users and measure whether the revenue outcome moves, not just the completion rate. Second, optimise for the revenue outcome, not the completion rate itself. It is easy to lift "onboarding completed" by making onboarding shorter, and easy to fool yourself that you improved something if you were not watching the renewals it was supposed to drive. Keep your eye on the money the onboarding is meant to produce, which — once again — means keeping onboarding telemetry and revenue on the same timeline.

Feature adoption to conversion: which features actually earn

Feature-to-conversion analysis identifies which product features are associated with users upgrading, converting, and retaining — as opposed to features that get used but never move revenue. Every roadmap has both kinds, and telling them apart is one of the highest-value things subscription analytics can do, because it redirects engineering effort toward the features that pay.

The analysis is a behavioural cohort joined to a revenue outcome: for each feature, compare the conversion and retention of users who adopted it against users who did not. A feature with high usage but no lift in revenue outcomes is engaging but not commercial — fine to keep, but not the thing to double down on. A feature with lower usage but a strong lift among the users who find it is a hidden gem: the priority is not to build more, but to get more users to discover what already works. That distinction is impossible to draw without revenue in the picture; usage numbers alone would tell you to invest in the popular feature and ignore the profitable one.

This is the same shape of question as trial-to-paid and onboarding impact, and deliberately so — feature adoption, activation, and conversion are one continuous story about which product experiences produce revenue. A subscription analytics platform that holds behaviour and verified revenue together lets you ask all three from one dataset. A split stack forces each one into a manual export, which is why, in practice, most teams never ask them at all. The value of the cross-match is not that any single question is impossible otherwise — it is that it makes the questions cheap enough that you actually ask them.

Instrumenting an iOS or SwiftUI app for subscription analytics

To instrument an iOS app for subscription analytics you need two streams captured against one identity: product telemetry (what the user does) and subscription state (what they bought), joined so a StoreKit transaction and a screen view belong to the same customer. On modern iOS that means pairing your telemetry events with StoreKit 2, whose Transaction and Product.SubscriptionInfo APIs give you verified purchase data you never have to trust the client to compute. For the metrics side, our guide to StoreKit 2 subscription analytics: what developers should track covers exactly which transaction fields matter.

The design goal is that you never end up with a telemetry stream and a purchase stream that have to be reconciled later. You capture both through one SDK, tagged with one identity, so the join is done at the source rather than in a spreadsheet afterward. The illustrative sketch below shows the shape — telemetry for behaviour, StoreKit 2 for verified purchases, both attributed to the same actor. (Method names are illustrative; check the current SDK docs for exact signatures.)

// 1. Identify the actor once, so every event and purchase joins to one customer.
Crossdeck.identify(userId: account.id)

// 2. Record product behaviour — ordinary telemetry.
Crossdeck.track("onboarding_step_completed", ["step": "connected_calendar"])
Crossdeck.track("feature_used", ["feature": "export"])

// 3. Observe verified subscription state from StoreKit 2, not a client flag.
for await update in Transaction.updates {
    guard case .verified(let transaction) = update else { continue }
    // The transaction is cryptographically verified by StoreKit 2.
    Crossdeck.track("subscription_renewed", [
        "productId": transaction.productID,
        "isTrialPeriod": transaction.offer?.type == .introductory
    ])
    await transaction.finish()
}
// Behaviour and verified revenue now share one timeline, one identity.

Two properties make this trustworthy. First, verification happens against the rail. StoreKit 2 hands you a signed transaction; your subscription state should be confirmed server-side against Apple rather than inferred from a value the app set locally, because a local flag can be stale or spoofed. Second, the entitlement is the durable concept, not the transaction. A customer may hold the pro entitlement through an Apple subscription today and a Stripe one tomorrow; your analytics should key on the entitlement so the customer's history survives a change of rail or device. Our deeper walkthrough — how to instrument a SwiftUI app for telemetry and paid access — covers gating features on verified entitlements as well as recording them.

What to look for in an iOS or Swift analytics SDK

If you are choosing the best iOS analytics SDK for a paid app, the decisive question is not the size of the event catalogue — most SDKs record events fine. It is whether the SDK closes the loop to revenue. Judge a Swift analytics SDK on three things:

• Does it join telemetry to verified subscriptions? An SDK that records behaviour but leaves you to reconcile StoreKit transactions in another tool has handed you back the split-stack problem.
• Does it carry one entitlement model across iOS, Android, and web? Customers cross surfaces; an SDK that only understands the device it runs on cannot follow them.
• Is it privacy-first by default? On iOS especially, an SDK that reaches for the advertising identifier or fingerprints devices is a liability under App Store rules and App Tracking Transparency. First-party analytics does not need it.

Instrumenting a Next.js or web app for subscription analytics

On the web the pattern is the same as on iOS — telemetry plus verified subscription state, joined to one identity — but the rail is usually Stripe and the verification happens on your server via webhooks. The client records behaviour; the server listens for Stripe's subscription lifecycle events (created, renewed, updated, cancelled, refunded) and treats those, not anything the browser reports, as the truth about revenue. That server-side verification is the web equivalent of StoreKit 2's signed transaction. We cover the full setup in how to instrument a Next.js app for subscriptions and entitlement checks.

The one web-specific trap worth calling out is where each event fires. A Next.js app has a client and a server, and it is easy to record the same conversion twice — once from the browser and once from the webhook — or to miss it entirely if you rely only on the client, which the user can close mid-checkout. The reliable rule is that behaviour is recorded from the client where it happens, and revenue is recorded from the server webhook where it is verified. Keep that division and you get one clean event per real thing.

// Client component — record behaviour where it happens.
crossdeck.identify(user.id);
crossdeck.track("pricing_viewed", { plan: "pro_annual" });
crossdeck.track("checkout_started", { plan: "pro_annual" });

// Server route — verify revenue from the Stripe webhook, never the browser.
export async function POST(req) {
  const event = stripe.webhooks.constructEvent(body, sig, secret); // verified
  if (event.type === "customer.subscription.created") {
    const sub = event.data.object;
    crossdeck.track("subscription_started", {
      userId: sub.metadata.userId, // same identity as the client events
      priceId: sub.items.data[0].price.id,
      amount: sub.items.data[0].price.unit_amount, // the ledger, not list price
    });
  }
  return Response.json({ received: true });
}

Because the client events and the webhook events share userId, the browser behaviour and the verified revenue land on the same customer timeline automatically — the join is designed in, not reconstructed later. And because the revenue amount comes from Stripe's event rather than a hard-coded price, your MRR and LTV read from what actually settled. The same discipline applies if you use Stripe for web and the App Store for mobile: the entitlement is what unifies them, so a customer who pays on the web and uses the app on iOS is one person with one history, not two half-records. Our guide to connecting app analytics to revenue events expands on keeping that identity intact across rails.

Privacy-first subscription analytics: revenue without surveillance

Privacy-first analytics measures your own customers' behaviour and revenue inside your own first-party system, without third-party tracking, cross-app identifiers, device fingerprinting, or shipping personal data to ad networks. The common assumption that you must choose between good analytics and respecting privacy is false — it comes from conflating analytics with advertising surveillance, which are different things. You do not need the advertising identifier to know that one of your paying customers finished onboarding and then renewed. You already have a first-party relationship with that customer; measuring it is not tracking them across the internet.

This matters more for subscription apps than for most, for two concrete reasons. First, Apple's App Tracking Transparency and App Store privacy rules make surveillance-style analytics an active liability — the advertising identifier requires explicit consent most users decline, and privacy-label disclosures make invasive SDKs a competitive disadvantage. Second, and more simply, you do not need it. Every metric in this guide — MRR, trial-to-paid, churn, NRR, LTV, cohort and feature analysis — is computed entirely from first-party data: your customers' interactions with your app and their subscriptions on your account. None of it requires a third-party tracker.

• First-party identity, not cross-app tracking. Attribute events to your own user or account ID, established when the customer signs in — not to a device advertising ID shared across apps.
• Aggregate by default, identify by exception. Most subscription metrics are aggregates; row-level identity is needed only for specific support and journey work, and can be scoped accordingly.
• Data minimisation. Record the events and amounts the metrics require, not everything you could capture. Less collected is less to protect.

The upshot is that privacy-first is not a constraint you accept at the cost of insight — it is simply the correct architecture for first-party revenue analytics, and it happens to be the compliant one too. We build on this principle deliberately, and it is the whole premise of our privacy-friendly analytics connected to revenue approach: keep the privacy posture people like about tools such as TelemetryDeck, and add the revenue join those tools lack. For a broader treatment, see our writing on building a privacy-conscious analytics dashboard.

Build vs buy: should you build subscription analytics yourself?

Build the parts genuinely specific to your product; buy the parts that are identical for every subscription app. The reliable way to get this decision wrong is to look at the visible layer — the charts — and conclude that analytics is a dashboard you can build in a sprint. The charts are the easy part. The hard part is the invisible infrastructure beneath them that makes the charts trustworthy, and that infrastructure is nearly identical across apps, which is exactly what makes it a buy rather than a build.

What sits under the charts is a subscription state engine that models trials, renewals, grace periods, billing retry, upgrades, downgrades, refunds, and cancellations correctly across Apple, Google Play, and Stripe; an identity system that keeps one customer's history intact across rails, devices, and reinstalls; reconciliation logic so a missed webhook does not silently corrupt revenue or access; and the join that keeps behaviour and revenue aligned as all of the above changes. None of that is your product's differentiator, and all of it is a permanent maintenance commitment — the rails change their APIs, edge cases surface for years, and the correctness bar is unforgiving because wrong revenue data is worse than none. We laid out the full trade-off in how to build a subscription analytics dashboard from scratch — and why not to.

The honest case for building is real but narrow: you have unusual requirements a managed product genuinely cannot meet, you have deep data-platform capacity, and analytics is close enough to your core that owning it is strategic. For everyone else — and especially for a small team whose best engineers should be building the product customers pay for — the maintenance of subscription infrastructure is the wrong place to spend them. The right split is usually to buy the joined timeline and the state engine, and build the handful of product-specific metrics and views that are truly yours on top of it.

Crossdeck vs single-purpose analytics (TelemetryDeck, Amplitude, PostHog)

TelemetryDeck, Amplitude, and PostHog are good product-analytics tools, but they measure behaviour, not revenue — they can tell you what a user did, not whether it earned or kept money. This is not a flaw in those tools; it is their design. They are built to record events, funnels, and usage retention, and they do that well. The gap is structural: they do not natively verify subscriptions or hold entitlement state, so the revenue side of every question in this guide sits outside them, in a billing tool or store dashboard they cannot see into.

That means the split-stack tax described earlier is not something you configured wrong — it is inherent in using a behaviour-only tool for a revenue business. Trial-to-paid, NRR, ledger-based LTV, feature-to-conversion, onboarding impact: each needs behaviour and verified revenue in one record, and a behaviour-only tool can supply only half. You can bolt on the other half by exporting and joining, but you are then maintaining the join by hand, forever.

Two fair points in the other direction. First, if you run a free app with no subscriptions, a product-analytics tool is the right choice — there is no revenue to join, and a privacy-first behaviour tool like TelemetryDeck is an excellent fit. Second, the mature behaviour-only tools have deeper event-exploration and experimentation surfaces than a revenue-joined platform typically leads with; if free-form behavioural exploration is your primary need, weigh that. The case for Crossdeck is specific: it is for paid apps whose important questions all cross the line between behaviour and revenue, where holding telemetry, verified subscriptions, entitlements, and errors on one timeline turns a week of exports into a single query. We wrote the honest, side-by-side version of the TelemetryDeck comparison in the TelemetryDeck alternative guide.

A decision framework for your subscription analytics stack

Pulling the whole guide together, here is a framework to decide what your app actually needs. Work through it in order; the first questions do most of the sorting.

• Do you charge for the app at all? If not, you do not need subscription analytics — a privacy-first product-analytics tool covers you. Everything below assumes a paid app.
• Do your important questions cross behaviour and revenue? "Which feature drives conversion", "does onboarding retain", "what precedes churn" — if these are the questions you keep needing to answer, a behaviour-only tool will cost you a manual export every time. You need the cross-match.
• Do customers cross surfaces? If a user can trial on iOS and upgrade on the web, you need one entitlement model across rails, not per-device analytics that double-counts or loses them.
• Is your team small relative to the maintenance? The subscription state engine, reconciliation, and identity layer are a permanent commitment. If your engineers are better spent on the product, buy the infrastructure and build only the product-specific views.
• Do your privacy requirements rule out surveillance analytics? On iOS, and increasingly everywhere, they should. Confirm any tool is first-party and privacy-first — you lose nothing on the metrics by insisting on it.

The pattern behind every answer is the same one this guide keeps returning to: for a paid app, the metrics are not the hard part — they are well-defined and universally agreed. The hard part is holding behaviour and verified revenue together so those metrics are trustworthy and the questions between them are cheap to ask. Whether you build that join or buy it, design it in from the start; retrofitting it onto a split stack is the expensive path almost everyone takes first and regrets. If you want to see the joined timeline in practice, you can start free or read the revenue intelligence docs.

Frequently asked questions