Cohorts

Cohort analysis is a powerful tool for gaining insights into how users renew subscriptions and how well subscribers and revenue are retained over time.

The Cohorts section features two charts: one for subscribers and another for net revenue retention. Analyzing both charts provides a comprehensive view of subscriber behavior.

Overview

By default, cohorts are calculated based on the user's first seen date. However, you can choose to analyze cohorts based on the first purchase date instead.

Typically, cohorts are built using the user's first seen date. This approach considers the time users may take to decide whether to make a payment, as well as any trial periods that might delay their conversion to paying subscribers.

Analyzing cohorts from the first purchase date can complicate the understanding of user behavior, particularly in determining the impact of marketing efforts. For instance, users attracted by a campaign in March might only make their purchases in April after a trial period.

📘
Note
Cohorts can be viewed on a weekly, monthly, quarterly, or yearly basis.

Data Freshness

Subscriber Retention and Net Revenue Retention charts are updated within 1 hour.

📘
Note
As cohort-based metrics require consistency in both user and revenue data, please avoid analyzing cohort metrics for users whose first seen date is today.
User and receipt data may be ingested into the analytics database with different delays — from a few minutes up to 2 hours. This can cause discrepancies, such as purchases being reflected before the users appear in the cohort. For reliable results, include only users with a first seen date at least one full day before the current date. Example: if today is June 17, 2025 and you'd like to check a metric for "this month's" cohort, set the cohort range to June 1–16.

Renewal periods

The charts feature columns labeled Renewals 0-N. Each column represents the Nth renewal of a user's subscription. These renewals can occur at irregular intervals. During the grace billing period, the subscriber's status remains active.

Renewal 0 represents the initial subscription purchase when the user makes their first payment, not the start of a trial period.

Subscriptions Reactivation

When a paid subscription fully expires, it marks the end of consecutive user renewals. A subscription is considered fully expired if the paid period has ended and auto-renewal setting is off.

If a subscription expires due to a billing issue but auto-renewal remains active, we do not consider the subscription as fully expired. Note that auto-renewal setting can not be indefinitely active. Apple and Google have policies for automatically canceling subscriptions with unresolved billing issues. Specifically, Apple cancels auto-renewal after 60 days, whereas the cancellation period for Google Play apps is configurable via the Google Play Console.

If users reactivate their subscription after it has been fully expired, they are counted as new subscribers, and their renewal count resets to zero. Thus, a user may appear in the cohorts charts multiple times if previous subscription has been fully expired.

For the most current information on subscription cancellation policies, please refer to the following resources:

Subscribers Retention Chart

Shows how app subscribers retain (in other words, how many of them renewing their subscriptions).

❗️
Important Note
Subscribers, who made a full refund of their App Store/Google Play subscriptions are not counted in the Renewal 0 group.

ARPPU

Average Revenue Per Paying User (LTV) for each cohort. Sum of all cohort's subscriptions revenue divided by subscribers count.

Average

This metric shows how many times an average user in the cohort renews the subscription.

📘
Note
For example, "in May cohort average user is renewing subscription 1,35 times"

Active Subs Users

This metric displays the number of users from a selected cohort who currently have an active non-trial subscription, meaning their latest subscription has not yet expired.

Only subscriptions that are still valid as of the current date are included. This helps you understand how many users from a specific acquisition or purchase cohort are still subscribed at the moment.

Autorenew Enabled Users

This metric represents the subset of Active Subs Users whose subscriptions still have auto-renewal enabled. It reflects users who have not manually turned off the auto-renewal option in their Apple or Google account settings and whose subscription status is still active. Thus, users whose subscription expired due to Billing issues, but they still have enabled auto-renewal, are excluded from calculation.

This metric is especially useful for identifying subscribers likely to renew automatically in future billing cycles and for forecasting revenue continuity.

Net Revenue Retention Chart

Shows your in-apps revenue retention (i.e. how much money left in each cohort after Nth renewal). It's crucial to be aware of how in-app subscription drops.

Net revenue is the amount of money left after each renewal.

❗️
Important Note
Revenue is counted as PROCEEDS – after App Store/Google Play commissions and refunds deduction.

Total

Summarized revenue for each cohort.

FAQ

What does First purchase date mean? Is it the day when the user actually paid for the subscription?

Yes, First purchase date is the date of the user’s first successful purchase with revenue > 0. A trial start is not a first purchase — it counts only when the trial converts to paid. If an introductory or promo offer has a $0 first period (which could be a case if developer applied such configuration of products), it still doesn’t count. The first purchase is recorded only when the user is actually charged.

Delayed payments

Please note that, according to Apple’s delivery model, purchase receipts and server notifications may not always be delivered instantly. Apple explicitly describes a system of retries — repeated notification attempts — and recommends that developers continuously synchronize transaction data using the App Store Server API, especially when any events are delayed, lost, or partially received (Apple — Responding to App Store Server Notifications). In practice, this means that Apphud can receive a notification (e.g., about a renewal or purchase) before the corresponding receipt is available or complete. When such cases occur, Apphud automatically queries the App Store Server API to retrieve the missing transaction history, subscription status, and receipt data. Once the missing information is obtained, Apphud backfills the purchase into analytics. Even if the receipt arrives later, the transaction is still attributed to the user’s original first purchase week, ensuring that cohort calculations, LTV, and retention metrics reflect the true historical behavior rather than the time of data delivery.

Can First purchase date change if a user has multiple subscriptions or reinstalls the app?

No. It always remains the date of the very first successful paid transaction. Example: The user was subscribed from May to July 2024, then deleted and reinstalled the app in September 2025, and subscribed again — their first purchase date remains May 2024.

However, in very rare cases when Apphud gets a delayed payment with a purchase date that is earlier than the currently recorded one, the First purchase date is updated, and the user is reassigned to a different cohort.

Why can Renewal 0 change and repeat for the same user?

Renewal 0 represents the first paid period of a subscription chain — either after a trial ends or when a new subscription starts. For more info, check Reactivations section above. If a user cancels their subscription, it expires, and if the user purchases again, they create a new subscription chain, which will generate another renewal 0 entry. This is expected behavior, since a single user can have multiple independent subscription chains over time.

In Cohorts analytics, all these activities (regardless of when the chain start event occurred) are still grouped under the cohort corresponding to the user’s first purchase week. The actual timestamps of payments remain accurate; however, in the cohort view, subsequent renewals and restarts are displayed as activity within that original cohort.

For example, imagine a user who purchased a weekly subscription on August 2, 2025. This is their first paid transaction, so they belong to the August 2025 cohort, and there are no other users in it. During the first subscription chain, the user made 3 additional payments, i.e., was a customer during four weekly iterations. After the third renewal, the user canceled the subscription and did not continue to Renewal 4. When viewing the Subscribers Retention report as of September 15, 2025, this user appears once in Renewals 0–3, since they completed four paid periods in their first chain. Later, the same user resubscribed to the same product, starting a new subscription chain on September 13. By October 10, the report now shows “2” in Renewals 0–3 for that cohort — one count from the first subscription chain and another from the new one. Although the user has restarted their subscription, they still belong to the August 2025 cohort because that is when their very first paid purchase occurred.