Cohorts

This page is the concept hub for Apphud's cohort retention charts: Subscribers retention and Revenue retention. Analyzing both side-by-side gives the most complete picture of how subscribers and revenue retain over time.

The charts live under Analytics → Reports → Cohorts in the sidebar. This page explains the underlying model — read it once, then refer back as needed.

What is a cohort

A cohort is a group of users who share the same start date — defined by some anchor event. In Apphud retention reports, the anchor is either when the user first appeared in the app or when they first paid (see Anchor date below). Users in the same cohort are tracked together over time so you can compare how groups acquired in different weeks / months behave at the same point in their lifecycle.

The point of cohort analysis is to compare like with like, regardless of calendar time.

Retention charts

• Subscribers retention — how many users renew their subscription at each Renewal column. Plus ARPPU, Average renewals, Active subs users, Autorenew-enabled users per cohort.
• Revenue retention — how much revenue is retained at each Renewal column. Revenue is counted as Proceeds (after store commission, VAT, and refunds).

How a retention chart is laid out

Both Subscribers and Revenue retention charts use the same matrix layout:

• Rows = cohort start dates at the chosen granularity (week / month / quarter / year). Each row is one cohort of users who started in that period.
• Columns = Renewal N — the user's progress through their subscription chain (see Renewal periods). Renewal 0 is the user's first paid transaction; Renewal 1 is one renewal later; and so on.
• Each cell = how that cohort performed at that renewal step (count of users for Subscribers retention; Proceeds for Revenue retention).

Reading across a row answers "how does this cohort decay over its lifecycle?" Reading down a column answers "is the Nth renewal getting better or worse over time as we acquire newer cohorts?"

The matrix is not a calendar grid. Two different cohorts at "Renewal 3" represent the same step in the customer journey, not the same calendar date — that's how cohort analysis isolates retention from acquisition timing.

Anchor date — First Seen vs. First Purchase

The Anchor date control at the top of the chart decides who belongs to which cohort row in the matrix. It does not change the columns or the lifecycle definition — only how users are assigned to a cohort.

How the switch changes the matrix

Same user, two different rows depending on the anchor:

User installs March 15 → starts a 7-day free trial → converts to a paid subscription on April 1.

• With First Seen Date → user lands in the March cohort. Renewal 0 (their April 1 paid transaction) is counted in the March row.
• With First Purchase Date → user lands in the April cohort. Renewal 0 sits in the April row instead.

Two consequences when you flip the anchor:

1. The same cohort's row population changes — trial-then-convert users move forward; never-converters disappear entirely from First Purchase view because they have no Renewal 0.
2. Revenue retention totals shift between rows — earlier months can look "smaller" under First Purchase if many of their installed users actually paid in later months.

Renewal periods

The retention charts show columns labeled Renewal 0, Renewal 1, ..., Renewal N. Each column represents the Nth renewal in a user's subscription chain.

• Renewal 0 = the user's first paid transaction of the chain — not the start of a trial.
• Renewal 1 = the first paid renewal after Renewal 0.
• Renewal N = the Nth paid renewal.

These renewals can occur at irregular intervals. During the grace billing period the subscription remains active for retention purposes.

Subscription reactivations

A subscription chain is a continuous sequence of paid periods. The chain ends when the subscription is fully expired — meaning both the paid period is over and auto-renew is off.

• A subscription that lapses due to a billing issue but still has auto-renew on is not fully expired — the store keeps retrying. (Apple retries for up to 60 days; Google Play retry windows are configurable in the Google Play Console.)
• When a user resubscribes after full expiration, that becomes a new chain with its own Renewal 0.

A user can appear multiple times in the same cohort with multiple Renewal 0 entries if they had multiple chains.

More on store cancellation policies:

• Apple Developer — Retaining Subscribers
• Android Developers — Subscription Lifecycle

Data freshness

Both retention charts update within 1 hour.

❗️

Don't analyze same-day cohorts

Cohort metrics require consistency between user and revenue data. User and receipt data can ingest with different delays — minutes up to 2 hours. For reliable cohort numbers, exclude users whose First Seen Date is today. If today is June 17 and you want this month's cohort, set the range to June 1–16.

Refund handling

Refunds only affect respected renewal values:

• If a user fully refunded their App Store / Google Play subscription, they are not counted in Renewal 0 on retention charts

• If only later renewals were refunded, the user is still counted in all non-refunded iterations starting with Renewal 0.

FAQ

What does "First Purchase Date" mean exactly?

The date of the user's first successful purchase with revenue > 0. Trial starts don't count. An intro / promo offer with a $0 first period also doesn't count — the first purchase is only recorded once the user is actually charged.

Can First Purchase Date change later?

Normally no. It always stays the date of the very first successful paid transaction.

Rare exception: when Apphud receives a delayed payment notification with a purchase date earlier than the currently recorded one (Apple can delay or batch notifications). In that case First Purchase Date is updated to the earlier date and the user moves to a different cohort. See Delayed payments below.

Delayed payments — what happens?

Per Apple's delivery model, purchase receipts and server notifications can arrive late. Apphud queries Apple's App Store Server API to fetch missing transaction history when this happens. Recovered transactions are backfilled to the user's original first-purchase week — cohort calculations, LTV, and retention metrics reflect the true historical behavior, not the data-delivery time.

See Apple — Responding to App Store Server Notifications.

Why can Renewal 0 repeat for the same user?

Because a user can have multiple subscription chains. Each chain starts a fresh Renewal 0.

Example: User starts a weekly subscription Aug 2 (their first ever paid transaction → August 2025 cohort). They renew 3 times, then cancel. By Oct 10 they resubscribe — that's a new chain with its own Renewal 0. The user is still in the August 2025 cohort (their original first-purchase week), but Subscribers Retention now shows 2 in Renewals 0–3 for August (one from each chain).

How are billing issues and recovered renewals handled?

A user starts on Feb 2 → February cohort. The lifecycle goes:

• Feb 9 — billing issue (payment fails)
• Feb 15 — access ends (grace period over)
• Mar 20 — successfully recovered

If auto-renew never went off, the subscription isn't a new chain — Apple's retry continued the original one. The Mar 20 transaction is Renewal 1 of the original chain (not a new Renewal 0). The user stays in the February cohort and doesn't appear as a "new" March cohort user.

Are refunded subscriptions counted?

• If a user fully refunded their first paid subscription, they're not counted in Renewal 0.
• If only later renewals were refunded, the subscription is counted in Renewal 0 and all non-refunded renewals after it.