Title: Retention Analysis
Locale: en
URL: https://sensorswave.com/en/docs/analytics/retention-analysis/
Description: Analyze user retention and improve product stickiness
Retention Analysis is a core metric for measuring product health, used to track whether users return to the product and perform specific behaviors within subsequent time periods after completing an initial behavior. With Retention Analysis, you can understand user stickiness, the long-term value of the product, and the impact of different features, channels, or user groups on retention. A high retention rate typically means users have found the product's core value, while declining retention signals the need to optimize user experience or product features.

Retention Analysis supports flexible definition of Starting Events and Return Events, can analyze at different time granularities such as daily, weekly, and monthly, and provides multiple retention calculation methods to help you gain insights into user behavior patterns from different angles.

## Typical Use Cases

Retention Analysis can help you answer the following questions:

**Product stickiness evaluation**:
- What are the Day-7 and Day-30 retention rates for newly registered users?
- What proportion of users continue to return after first using a core feature?
- How have user retention rates changed after different version releases?

**Feature value validation**:
- Do users who used a particular new feature have higher retention than those who didn't?
- Which features contribute the most to long-term user retention?
- How does retention perform for users who completed the onboarding flow?

**Channel effectiveness comparison**:
- What are the retention rate differences for users from different acquisition channels?
- Which has better retention — paid channels or organic traffic?
- How do retention rates vary across regions?

**User group comparison**:
- How large is the retention rate gap between paid and free users?
- How does retention compare between iOS and Android users?
- How do retention curves differ between high-value and regular users?

**Churn risk identification**:
- At which time point does user churn primarily occur?
- What common characteristics do users who were initially active but later churned share?
- Which user groups have the highest churn risk?

## Prerequisites

Before using Retention Analysis, make sure you have:

- Completed [SDK integration](../data-integration/client-sdks/javascript.mdx) and started receiving data
- Understood the basic concepts of the [Data Model](../data-integration/data-model.mdx) and [Events and Properties](../data-integration/events-and-properties.mdx)
- Created the [Event Definitions](../08-数据管理/01-事件类型.md) you need to analyze in Data Center
- Have view or analysis permissions for the project, see [Roles and User Permissions](../10-组织与项目/03-角色和用户权限.md)

## Quick Start

### Create a Retention Analysis

1. Click **Insights** in the left navigation bar
2. Click the **New Analysis** button in the upper right corner
3. Select the **Retention Analysis** model
4. Configure analysis conditions:
   - Select the **Starting Event** (the user's initial behavior)
   - Select the **Return Event** (the user's subsequent return behavior)
   - Set the retention type and time granularity
5. Click the **Query** button to view the Retention Analysis results

### Save and Share

After completing the analysis configuration, you can:

1. Click the **Save** button in the upper right corner to name and save the analysis
2. Click the **Add to Report** button to add the analysis to an existing report
3. Click the **Share** button to generate a share link or export an image

## Core Features in Detail

The Retention Analysis configuration is divided into four parts: metric configuration, Segment By, Group By, and visualization settings. These features work together to enable deep retention analysis.

### 1. Metric Configuration

Metric configuration determines "what to analyze" and is the core of Retention Analysis. Unlike Event Analysis, Retention Analysis requires configuring two key events: the **Starting Event** and the **Return Event**.

#### Starting Event (Initial Behavior)

The Starting Event defines the entry point for Retention Analysis — "after the user does this, we start tracking their retention."

**Selecting the Starting Event**:
- Choose an event that represents a key user behavior
- Common Starting Events include: User Registration, First Launch, Complete Onboarding, First Purchase, etc.

**Starting Event property filters**:
- You can add property filter conditions to the Starting Event to precisely define the analysis scope
- Example: Filter "Registration Channel" equals "TikTok Ads" for the user registration event

**Use case examples**:

Analyze new user retention:
- Starting Event: User Registration
- Meaning: Track user retention starting from the date of registration

Analyze feature usage retention:
- Starting Event: First Search Use
- Meaning: Track return visits after users first use the search feature

Analyze purchaser retention:
- Starting Event: Complete Payment
- Filter condition: Order Amount > 100
- Meaning: Track subsequent retention for users whose first purchase exceeded 100

#### Return Event (Subsequent Behavior)

The Return Event defines "what the user does that counts as being retained."

**Selecting the Return Event**:
- Can be the same as or different from the Starting Event
- Same: Indicates users repeat the same behavior (e.g., after registration, continue to launch the app)
- Different: Indicates users completed another key behavior (e.g., after registration, made a purchase)

**Return Event property filters**:
- Also supports adding property filters to the Return Event
- Example: Filter "Page Type" equals "Core Feature Page" for page view events

**Use case examples**:

Scenario 1: App active retention
- Starting Event: User Registration
- Return Event: App Launch
- Meaning: After registration, did the user open the app in subsequent time periods

Scenario 2: Feature usage retention
- Starting Event: First Search Use
- Return Event: Search Use
- Meaning: After first using search, did the user continue to use the search feature

Scenario 3: Conversion behavior retention
- Starting Event: Add to Cart
- Return Event: Complete Payment
- Meaning: After adding to cart, did the user complete a purchase

Scenario 4: Cross-feature retention
- Starting Event: Complete Onboarding
- Return Event: Use Core Feature
- Meaning: Did users who completed onboarding actually use the core feature

#### Retention Type

The retention type determines how retention rates are calculated. Different retention types are suited for different analysis scenarios.

**On (N-day Retention)**:
- **Definition**: Whether the user returned on the Nth day (or Nth week, Nth month) after the initial behavior
- **Calculation**: Only counts return visits at a specific time point, not before or after
- **Applicable scenarios**:
  - Precisely understand retention performance at specific time points
  - Discover time points where retention rate suddenly drops
  - Compare retention differences across different time points
- **Examples**:
  - Day-7 retention = Whether the user opened the app on the 7th day after registration
  - Day-30 retention = Whether the user opened the app on the 30th day after registration

**Streak (Streak Retention)**:
- **Definition**: Whether the user returned **every single day** within N days after the initial behavior
- **Calculation**: Counts whether the user triggered the Return Event on every consecutive day within the N-day period; only counts as retained if all days have return visits
- **Applicable scenarios**:
  - Measure high user stickiness and product dependency
  - Identify core loyal user groups
  - Evaluate the effectiveness of habit-forming or engagement products
  - Monitor the formation of consecutive usage habits
- **Examples**:
  - 7-day Streak retention = User opened the app on days 1, 2, 3, 4, 5, 6, and 7 after registration
  - 30-day Streak retention = User opened the app every day for 30 consecutive days after registration

> **Tip**: Streak retention rates are typically much lower than On retention rates because they require users to return every day. Streak retention reflects users' deep dependency on the product and the degree to which usage habits have formed.

**Retention type comparison**:

| Comparison Aspect | On | Streak |
|---------|---------|---------|
| **Calculation** | Only counts return on the Nth day | Counts whether user returned every day from Day 1 to Day N |
| **Value relationship** | Typically higher | Typically lower (≤ On retention) |
| **Trend characteristics** | Curve may fluctuate, can show recovery | Curve drops quickly and doesn't recover |
| **Applicable scenario** | Precisely analyze specific time points | Measure user stickiness and habit formation |
| **Reflects** | User activity patterns | User dependency and loyalty |

**Comparison example**:

Assume 100 users registered on January 1:
- Day 7: 20 users returned on Day 7 (On retention = 20%)
- Streak 7 days: Only 5 users returned every day from Day 1-7 (7-day Streak retention = 5%)

In this example:
- Day-7 On retention = 20% (only checks whether users returned on Day 7)
- 7-day Streak retention = 5% (requires return visits every day from Day 1-7)

#### Retention Time Granularity

Time granularity determines the time unit for Retention Analysis.

**Daily**:
- Suitable for daily-use products such as social media, news, and utility apps
- Observe daily usage habits
- Example: Day-1, Day-3, Day-7 retention

**Weekly**:
- Suitable for products used weekly, such as e-commerce and O2O services
- Smooth out daily fluctuations and observe weekly retention trends
- Example: Week-1, Week-4, Week-12 retention

**Monthly**:
- Suitable for low-frequency but high-value products such as enterprise services and financial products
- Observe long-term retention and user lifecycle value
- Example: Month-1, Month-3, Month-6 retention

> **Tip**: Choose a time granularity that matches your product's natural usage cycle. For example, food delivery apps are suited for daily analysis, while B2B enterprise services are better analyzed monthly.

### 2. Segment By (Segmentation)

Segment By is equivalent to the `WHERE` clause in SQL, used to filter the user groups you care about from massive data. For detailed information about Segment By, see [Common Analysis Features](common-analysis-features.mdx#2-细分筛选-segmentation).

#### Filter Condition Types

In Retention Analysis, Segment By applies to the entire analysis, affecting which users are included in the retention calculation.

**User Property filter**:
- Filter based on inherent user characteristics
- Example: Filter "Registration Channel" equals "TikTok Ads"
- Example: Filter "Membership Level" in "Gold Member", "Platinum Member"

**Cohort filter**:
- Use pre-created Cohorts as filter conditions
- Example: Filter "Belongs to 'New User Cohort'"
- Example: Exclude "Belongs to 'Internal Test Accounts'"

**Use case examples**:

Analyze user retention from paid channels:
- Add User Property filter: "Registration Source" in "Baidu Ads", "TikTok Ads", "Xiaohongshu Ads"

Analyze mobile user retention:
- Add User Property filter: "Platform" equals "iOS" or "Android"

Exclude internal test users:
- Add User Property filter: "Email" not contains "@sensorswave.com"

#### Comparative Analysis (Multiple Segments)

Similar to Event Analysis, Retention Analysis also supports configuring multiple independent Segment By filters to compare retention differences across user groups.

**Usage steps**:

1. **Create the first segment**:
   - Click the "Add Segment" button
   - Set filter conditions, e.g., "Platform = iOS"
   - Name this segment, e.g., "iOS Users"

2. **Create the second segment**:
   - Click the "Add Segment" button again
   - Set different filter conditions, e.g., "Platform = Android"
   - Name this segment, e.g., "Android Users"

3. **View comparison results**:
   - The retention curve chart displays each segment's retention curve in different colors
   - The retention table shows data for each segment separately
   - You can visually compare retention performance differences across groups

**Use case examples**:

Scenario 1: Compare retention across channels
- Segment 1: "Registration Source = TikTok Ads" named "TikTok Channel"
- Segment 2: "Registration Source = Baidu Search" named "Baidu Channel"
- Observe retention quality differences across acquisition channels

Scenario 2: Compare paid and free users
- Segment 1: "Membership Level in Gold Member, Platinum Member" named "Paid Users"
- Segment 2: "Membership Level = Free Member" named "Free Users"
- Analyze the impact of payment on retention

Scenario 3: Compare users who completed vs. didn't complete onboarding
- Segment 1: "Users who completed onboarding Cohort" named "Completed Onboarding"
- Segment 2: "Users who didn't complete onboarding Cohort" named "Did Not Complete Onboarding"
- Evaluate the value of onboarding on retention

### 3. Group By (Grouping)

Group By is equivalent to the `GROUP BY` clause in SQL, splitting retention data by specified dimensions. For detailed information about Group By, see [Common Analysis Features](common-analysis-features.mdx#3-分组查看-grouping).

#### Supported Group Types

**Group by User Property**:
- Group by inherent user characteristics
- Example: "Group by 'Province' to view retention differences across regions"
- Example: "Group by 'Registration Channel' to compare retention quality across channels"

**Group by Starting Event property**:
- Group by contextual information at the time of the Starting Event
- Example: "Group by 'Device Model' to view retention performance across devices"
- Example: "Group by 'App Version' to compare retention rates across versions"

> **Tip**: Retention Analysis supports a single Group By dimension. The system generates independent retention curves for each group value, enabling intuitive comparison.

#### Group Result Sorting

**Sort by initial user count**:
- Sort from highest to lowest or lowest to highest by the number of initial users
- Useful for quickly identifying the groups with the most users

**Sort by retention rate**:
- Sort by the retention rate at a specified time point (e.g., Day-7 retention rate)
- Useful for quickly identifying the best or worst performing groups

**Top N display**:
- Displays the Top 10 group results by default
- Adjustable to show only Top 5 or display all groups

### 4. Visualization Settings

Retention Analysis provides specialized visualization methods for displaying retention data.

#### Retention Curve Chart

The retention curve chart is the most commonly used visualization in Retention Analysis, displaying Retention Rate trends over time as a Line chart.

**Chart elements**:
- **X-axis**: Time period (Day 1, Day 2... or Week 1, Week 2...)
- **Y-axis**: Retention Rate (percentage)
- **Curves**: Retention trends for each user cohort or segment

**Applicable scenarios**:
- Observe the decay trend of retention rates
- Compare retention curves across groups
- Identify key time points where retention drops

#### Retention Table

The retention table displays detailed retention data in table format, supporting precise viewing of Retention Users and Retention Rate at each time point.

**Table structure**:
- **Rows**: User cohorts (grouped by Starting Event date)
- **Columns**: Time periods (Day 0, Day 1, Day 2...)
- **Cells**: Retention Users and Retention Rate for that cohort at that time point

**Applicable scenarios**:
- View precise retention values
- Drill down to specific user lists
- Export data for secondary analysis

**Color coding**:
- The system colors cells based on retention rate levels
- Dark colors indicate high retention rates, light colors indicate low retention rates
- Helps quickly identify strong and weak retention performance

#### Time Settings

**Analysis time range**:
- Select analysis start and end dates
- Determines which user cohorts are included in the analysis
- Example: "2026-01-01 to 2026-01-31" means analyzing users acquired in January

**Retention observation period**:
- Determines the time span for observing retention
- Example: Observing 30 days shows retention data for Days 0-29
- The system automatically adjusts the display range based on time granularity

> **Tip**: If the selected analysis time range is recent, later retention data may not be available because the observation period hasn't ended yet (e.g., a user who registered yesterday cannot have Day-30 retention calculated).

## Data Detail Area

The Data Detail Area is located below the visualization charts, providing detailed data for Retention Analysis. For detailed information about the Data Detail Area, see [Common Analysis Features](common-analysis-features.mdx#-数据明细区).

### User List Drill-down

In the retention table, you can click on any cell to view the specific user list for that cohort at that time point.

**Usage steps**:
1. In the retention table, find the cell you're interested in (e.g., Day-7 Retention Users)
2. Click the cell, and the system will pop up a user list
3. The user list shows: user ID, trigger count, last active time, and other information
4. You can:
   - Click a user ID to jump to [User List](../05-受众计算/01-用户细查.md) to view the user's complete behavior trail
   - Select multiple users and save them as a [Cohort](../05-受众计算/02-用户分群.md)
   - Export the user list as a CSV file

**Use cases**:
- Analyze common characteristics of high-retention users to summarize successful experiences
- Analyze behavior patterns of low-retention or churned users to discover improvement opportunities
- Save users who churned at a specific time point as a Cohort for recall campaigns

### Data Export

Click the "Export" button in the upper right corner of the data table to export Retention Analysis results as:
- **CSV format**: Contains complete retention table data, suitable for secondary analysis
- **Excel format**: Suitable for creating presentation materials
- **Image format**: Save the retention curve chart directly as a PNG image

## Tips and Best Practices

### Choosing the Right Starting Event and Return Event

The choice of Starting Event and Return Event directly impacts the value of Retention Analysis.

**Recommended practices**:

(Recommended) **Choose core conversion nodes as the Starting Event**:
- User Registration: Measure overall product retention
- First Purchase: Measure paying user retention
- Complete Onboarding: Measure the impact of onboarding on retention
- First Use of Core Feature: Measure feature value

(Recommended) **Choose active behaviors as the Return Event**:
- App Launch: Measure whether users return to the product
- Core Feature Use: Measure whether users continue using valuable features
- Any Event: Measure whether users have any active behavior

(Recommended) **Relationship between Starting Event and Return Event**:
- Same event: Analyze the frequency of repeated behaviors (e.g., repurchase after first purchase)
- Different events: Analyze behavioral conversion (e.g., whether users use core features after registration)

**Practices to avoid**:

(Not recommended) Choosing a low-value Starting Event like "Page View", resulting in analysis lacking business meaning
(Not recommended) Return Event being too broad (like "Any Event"), failing to reflect actual product value
(Not recommended) Starting Event and Return Event combinations that are illogical, unable to form a retention relationship

### Understanding and Choosing the Right Retention Type

Different retention types are suited for different analysis scenarios.

**When to use On retention**:
- (Recommended) When you need to understand user activity at specific time points
- (Recommended) When you want to discover time points with sudden retention drops or recoveries
- (Recommended) When you want to compare retention performance at different time points (e.g., Day 7 vs. Day 30)

**When to use Streak retention**:
- (Recommended) When you need to measure high user stickiness and product dependency
- (Recommended) When you want to identify core loyal user groups
- (Recommended) When you want to evaluate user habit formation and usage frequency
- (Recommended) When you need to understand the consistency of daily user return visits

**Practical recommendations**:
- Daily monitoring: Use On retention, focusing on key time points (e.g., Day 1, 3, 7, 30)
- Stickiness evaluation: Use Streak retention to identify core users and habit formation
- Comparative analysis: Use both types simultaneously to understand both activity patterns and dependency levels

### Using Time Granularity Wisely

Choosing the right time granularity can display retention trends more clearly.

| Product Type | Recommended Granularity | Key Retention Metrics |
|---------|---------|------------|
| Social, News, Utility apps | Daily | Day-1 retention, Day-7 retention, Day-30 retention |
| E-commerce, O2O services | Weekly | Week-1 retention, Week-4 retention, Week-12 retention |
| Enterprise services, Financial products | Monthly | Month-1 retention, Month-3 retention, Month-12 retention |
| Gaming | Daily | Day-1 retention, Day-3 retention, Day-7 retention |

**Industry benchmark retention rates**:

Retention rate benchmarks vary significantly across industries and product types:
- **Day-1 retention**: Generally 30%-40% is considered good
- **Day-7 retention**: Generally 20%-30% is considered good
- **Day-30 retention**: Generally 10%-20% is considered good

> **Tip**: These benchmarks are for reference only. Actual retention rates are influenced by many factors including product type, usage frequency, and user value.

### Group Comparison Best Practices

When using Group By or multiple segments to compare retention across groups, keep these points in mind:

**Recommended practices**:
- (Recommended) Comparison dimensions should have clear business hypotheses (e.g., hypothesize that paid users have higher retention)
- (Recommended) Ensure each group has a sufficiently large sample size (at least 100 users recommended) to avoid small sample bias
- (Recommended) Compare 2-5 key groups first to avoid analysis confusion from too many groups
- (Recommended) Combine retention curves and retention tables — look at both trends and specific values

**Practices to avoid**:
- (Not recommended) Comparing groups with vastly different sample sizes (e.g., 1,000 vs. 10 users), resulting in poor comparability
- (Not recommended) Group By dimensions that are too fragmented (e.g., by User ID), losing comparison value
- (Not recommended) Only looking at retention differences at a single time point, ignoring overall trends

### From Retention Analysis to Action

The ultimate purpose of Retention Analysis is to discover issues and take action.

**Discover high-retention driving factors**:
1. Identify user groups with retention rates significantly above average
2. Drill down to user lists and analyze their common characteristics and behavior patterns
3. Summarize success factors and promote them to more users

**Identify key churn time points**:
1. Observe the retention curve and find the time period where retention drops the fastest
2. Analyze user behavior and experience during that period
3. Optimize product features or operational strategies to reduce churn

**Validate the effectiveness of features or strategies**:
1. Compare retention rate changes before and after a feature launch or strategy implementation
2. Use time comparison to quickly identify improvement effects
3. Continue iterating and optimizing

**Targeted recall of churned users**:
1. In the retention table, click the cell for churned users
2. Save churned users as a Cohort
3. Conduct targeted push notifications, coupon distributions, or content recommendations

## Important Notes

### Data Accuracy

**Event tracking quality**:
- The accuracy of Retention Analysis depends on the completeness of tracking data
- Ensure both the Starting Event and Return Event are correctly instrumented and reported
- Before making important decisions, we recommend checking event trigger volumes and completeness in Data Center

**User identification**:
- Retention Analysis relies on accurate user identification; ensure the same user is correctly identified across different time periods
- If a user switches devices or clears cache and is identified as a new user, retention rates will be underestimated
- See [How to Properly Identify Users](../data-integration/user-identification.mdx)

### Time and Data Completeness

**Data completeness**:
- Recent retention data may be incomplete because the subsequent observation period hasn't ended
- Example: A user who registered yesterday cannot have Day-30 retention calculated — you need to wait 30 days for complete data
- We recommend focusing on cohort data with sufficient observation periods

**Data freshness**:
- Retention data update latency depends on the data integration method, typically within 1-5 minutes
- If you need real-time monitoring, we recommend refreshing the analysis every 10-30 minutes

### Performance and Limits

**Query performance**:
- Longer analysis time ranges and observation periods result in longer query times
- We recommend using shorter time ranges (e.g., past 30 days of user cohorts) for exploratory analysis
- For long time ranges, use weekly or monthly granularity

**Feature limits**:
- Up to 10 Segment By filters for comparison
- Up to 10 Group By dimensions
- Default maximum retention observation period is 365 days (daily), adjustable as needed

### Interpreting Retention Data

**Avoid over-interpreting a single metric**:
- Retention rate is just one dimension for measuring product health; consider it alongside other metrics (e.g., activity, conversion rate) for comprehensive judgment
- Retention rate benchmarks vary significantly across product types; don't blindly compare

**Consider seasonality and external factors**:
- User behavior may be influenced by seasons, holidays, marketing campaigns, and other factors
- When analyzing retention changes, account for these external factors

**Sample size and statistical significance**:
- Small sample retention rates may have significant fluctuations and lack statistical significance
- When comparing different groups, ensure each group has a sufficiently large sample

## Related Documentation

**Analysis models**:
- [Choosing the Right Analysis Model](choosing-analysis-model.mdx): Learn how to choose an analysis model
- [Common Analysis Features](common-analysis-features.mdx): Learn about features shared across all analysis models
- [Event Analysis](event-analysis.mdx): Analyze user behavior trends and distributions
- [Funnel Analysis](funnel-analysis.mdx): Analyze conversion processes and drop-off points

**Data integration**:
- [Data Model](../data-integration/data-model.mdx): Understand the Sensors Wave data model
- [Events and Properties](../data-integration/events-and-properties.mdx): Learn about event and property concepts
- [How to Properly Identify Users](../data-integration/user-identification.mdx): Ensure user identification accuracy

**Data Center**:
- [Event Definitions](../08-数据管理/01-事件类型.md): Manage and maintain event metadata
- [Event Properties](../08-数据管理/02-事件属性.md): Manage event property information
- [User Properties](../08-数据管理/03-用户属性.md): Manage user property information

**Users**:
- [User List](../05-受众计算/01-用户细查.md): View detailed behavior trails for individual users
- [Cohorts](../05-受众计算/02-用户分群.md): Create and manage user groups

**Reports and visualization**:
- [Chart Management](../04-可视化与报表/01-图表管理.md): Save and manage analysis charts
- [Report Management](../04-可视化与报表/02-报表管理.md): Create Dashboards and reports

## Next Steps

After completing Retention Analysis, you can:

1. **Analyze conversion processes**: Use [Funnel Analysis](funnel-analysis.mdx) to identify conversion bottlenecks in key processes
2. **Analyze user behavior in depth**: Use [Event Analysis](event-analysis.mdx) to understand specific user behavior patterns
3. **Create Cohorts**: Save specific user groups from Retention Analysis as [Cohorts](../05-受众计算/02-用户分群.md) for targeted operations
4. **Monitor core metrics**: Add key retention metrics to [Reports](../04-可视化与报表/02-报表管理.md) for daily data monitoring
5. **View best practices**: See [Best Practices](best-practices.mdx) to improve analysis efficiency
6. **Resolve common issues**: If you encounter problems, check the [FAQ](faq.mdx)