We often see teams focusing on DAU while missing that retention is falling. Our experience shows: day-1 retention of 40% and day-7 retention of 20% indicate different issues. Cohort analysis is the only way to see real user behavior. It shows how users from the same install week behave 7, 14, 30 days after first launch. Aggregated DAU hides degradation: if new users arrive faster than old ones leave, DAU grows—but retention drops. Cohorts reveal this. The concept of cohort analysis is widely used in mobile analytics. However, in practice, typical errors arise: unstable user identifier, wrong choice of the first valuable action, lack of version breakdown. These problems distort the data, misleading the team. Contact us to set up cohort analysis correctly.
What is needed for cohort analysis
Two mandatory conditions: a stable user_id and an activation event. Without them, cohorts cannot be built correctly. Savings on advertising budget after precise setup can reach 20%.
User ID must be the same after app reinstall. If you generate a new one each time, the user will always be in a new cohort. Solutions:
- iOS: Keychain to store a generated UUID (survives app deletion)
- Android: AccountManager or server-side ID after registration
- After authentication: Analytics.setUserId(serverUserId) — user binds to the account
Tip: check if the ID persists after reinstall
Install a test build, delete the app and reinstall. If the user_id remains the same—it's fine. If not—configure Keychain or AccountManager.Activation event—the first action that shows the product's value. Different apps have different ones:
| App type | Activation event |
|---|---|
| Marketplace | first_purchase |
| Streaming | content_played (3+ minutes) |
| Fitness | workout_completed |
| Game | level_2_started |
| Social network | first_post or 5_connections |
Choosing the activation event affects what the cohort shows. app_open is too broad—includes casual users. premium_purchase is too narrow for retention analysis of the entire audience.
Why stable user_id matters
Without a stable identifier, you can't distinguish a new user from a returning one after reinstall. This inflates new user numbers and deflates retention. We guarantee correct configuration of Keychain and AccountManager based on your platform. According to our data, 90% of clients had unstable user_id before setup, distorting cohorts by 50% or more. Get a free audit of your current analytics—we'll evaluate user_id stability and event correctness.
How to choose the activation event?
The activation event should reflect the first moment the user gets value. For a fitness app, it's workout_completed, not app_open. One of our clients (a fitness app) after setting cohorts by workout_completed discovered that retention among those who completed their first workout within the first 2 days was 30% higher. We changed the onboarding to push the first workout, and retention grew by 15% in a month. Contact us for a consultation to select the activation event for your app.
Implementing cohort analysis
Firebase / BigQuery—setting up cohort analysis
Firebase builds Retention Chart in the Analytics section natively, but with limited flexibility. For deep analysis, we export raw data to BigQuery via Firebase → Integrations → BigQuery. Then SQL:
-- Cohort by install week, retention on day 7 WITH cohorts AS ( SELECT user_pseudo_id, DATE_TRUNC(MIN(PARSE_DATE('%Y%m%d', event_date)), WEEK) AS cohort_week, MIN(event_timestamp) AS first_open_ts FROM `project.analytics_*.events_*` WHERE event_name = 'first_open' GROUP BY user_pseudo_id ), activity AS ( SELECT DISTINCT user_pseudo_id, DATE_TRUNC(PARSE_DATE('%Y%m%d', event_date), WEEK) AS activity_week FROM `project.analytics_*.events_*` WHERE event_name = 'session_start' ) SELECT c.cohort_week, DATE_DIFF(a.activity_week, c.cohort_week, WEEK) AS week_number, COUNT(DISTINCT c.user_pseudo_id) AS cohort_size, COUNT(DISTINCT a.user_pseudo_id) AS retained_users, ROUND(COUNT(DISTINCT a.user_pseudo_id) / COUNT(DISTINCT c.user_pseudo_id) * 100, 1) AS retention_pct FROM cohorts c LEFT JOIN activity a ON c.user_pseudo_id = a.user_pseudo_id GROUP BY 1, 2 ORDER BY 1, 2 This query produces a weekly retention table.
Amplitude
In Amplitude, cohort analysis is a native tool in the Retention Analysis section. We configure:
- Starting Event—first_open or activation event
- Return Event—session_start or app_open
- Grouping by days/weeks
- Breakdown by: install source, platform, app version
Amplitude allows side-by-side cohort comparison—easy to see if retention improved after a product update.
Mixpanel
In Mixpanel, the Retention section builds a classic retention matrix. Additionally, Lifecycle shows what percentage of users return after a long absence. For casual games, this is an important metric.
Comparison of tools for cohort analysis
| Criterion | Firebase + BigQuery | Amplitude | Mixpanel |
|---|---|---|---|
| Flexibility | High (SQL) | Medium (UI) | Medium (UI) |
| Behavioral cohorts | SQL | Native | Lifecycle |
| Setup complexity | High | Low | Low |
| Cost | BigQuery queries | Subscription | Subscription |
Behavioral cohorts
Besides time-based cohorts (by install date), behavioral cohorts are useful—groups of users who performed a specific action. For example, in Amplitude Behavioral Cohorts you can segment users by actions: "added to cart", "shared content".
# Example logic in BigQuery: # Cohort: users who completed onboarding # Question: what is their retention vs users who skipped onboarding? If retention among those who completed onboarding is 2x higher—that's proof that onboarding needs improvement, not reduction.
Typical problems when setting up cohort analysis
- Unstable user_id—data is distorted.
- Wrong activation event—cohort doesn't reflect value.
- Using only app_open as return—mixes sessions and active users.
- Missing breakdown by version—can't see effect of updates.
Our experience includes setting up cohort analysis for apps with audiences from 10,000 to 5 million users. We guarantee correct retention and LTV display.
What is included in the work
- Audit of user_id stability in the current implementation
- Definition of activation events together with the product manager
- Configuration of cohort analysis in Firebase + BigQuery / Amplitude / Mixpanel
- SQL queries for custom cohort reports
- Setup of behavioral cohorts for key hypotheses
- Documentation and handover to the team
Timelines
Setup of cohort analysis in a ready-made tool (Amplitude/Mixpanel): 1–2 days. BigQuery + custom SQL queries: 2–4 days. Cost is calculated individually.
Get a free audit of your current analytics—we'll evaluate user_id stability and event correctness.