脚本怎样计算用户次日留存率

wen 实用脚本 2026-06-26 31

从数据埋点到自动化计算的完整指南

📚 目录导读

理解次日留存率：为什么它是产品健康度的“黄金指标”
计算次日留存的核心逻辑：用户、时间与行为的三角关系
数据埋点：脚本计算的第一步如何正确采集数据
实战脚本解析：从SQL到Python的完整计算流程
常见问题解答：计算中的坑与避坑策略
提升留存率的实用建议：从数据到行动

理解次日留存率：为什么它是产品健康度的“黄金指标”

Q: 什么是次日留存率？为什么产品经理和运营都盯着它不放？

脚本怎样计算用户次日留存率

次日留存率（Day-1 Retention）指的是：在某一日新增的用户中，在次日（通常是第二天0:00至23:59）再次启动或使用产品的用户比例。

公式很简单：

次日留存率 = 次日活跃的新增用户数 ÷ 当日新增用户总数 × 100%

但它的意义并不简单,次日留存率是衡量产品“初次体验”是否吸引用户的关键指标，如果用户第二天就不回来了，说明产品的首次使用体验存在严重问题——可能是激活流程太长、核心功能没击中痛点，或是新用户引导不够顺畅。

权威来源：根据《增长黑客》作者Sean Ellis的研究，次日留存率低于30%的产品，通常难以实现长期增长，头部应用如Instagram、TikTok等，次日留存率往往在60%以上。

Q: 为什么不直接用“次日活跃用户”来衡量？

因为“活跃用户”包含了老用户，无法反映新产品对新增用户的吸引力，只有聚焦新增用户群体，才能判断产品是否“留住”了人。

计算次日留存的核心逻辑：用户、时间与行为的三角关系

要写脚本计算留存,必须先理解三个维度：

用户维度：你需要知道“谁是新增用户”，通常以用户首次注册或首次启动的日期作为基准，标记为Day 0。
时间维度：留存计算的时间窗口是“次日”，即Day 0的次日（Day 1），注意跨天问题：如果用户在23:59注册，次日00:01活跃，就算留存。
行为维度：什么是“活跃”？通常定义为有一次有效的页面访问、API调用或核心操作，要注意排除系统自动触发、后台静默等非用户自主行为。

关键点：留存率的计算必须基于“用户颗粒度”——

一个用户只计算一次,无论他在当天启动了多少次。
如果用户在Day 0注册，Day 1未活跃，Day 2才活跃，他的“次日留存”算失败，但可能会被计入“3日留存”。

Q: 如果用户跨时区怎么办？

建议以服务器的UTC时间为准,或者以用户注册时的本地时区进行对齐，但一定要保持全局统一，最稳妥的做法是：所有时间戳统一转换为UTC+0，避免时区导致的偏差。

数据埋点：脚本计算的第一步如何正确采集数据

脚本再聪明,也离不开原始数据的支撑，计算留存率所需的基础数据表通常包含两个关键字段：

字段名	类型	说明
`user_id`	String	用户唯一标识（如UUID）
`event_time`	DateTime	用户活跃事件发生时间
`event_name`	String	事件类型（如“app_launch”“register”）

核心数据表结构示例（以MySQL为例）：

-- 用户注册表（新增用户来源）
CREATE TABLE user_registration (
    user_id VARCHAR(64) PRIMARY KEY,
    register_time DATETIME NOT NULL,
    register_channel VARCHAR(32)
);
-- 用户活跃日志表（每日行为记录）
CREATE TABLE user_activity (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    user_id VARCHAR(64),
    activity_time DATETIME NOT NULL,
    device_type VARCHAR(16),
    INDEX idx_user_date (user_id, activity_time)
);

Q: 如果没有埋点数据，还能计算留存吗？

理论上不能,但一些第三方统计工具（如Firebase、友盟）会自动采集基础数据，你只需导出它们的“新增用户表”和“活跃用户表”即可。

实战脚本解析：从SQL到Python的完整计算流程

1 最直接的SQL计算方法

如果你使用的是关系型数据库,且数据量在百万级以内，以下SQL脚本可以直接出结果：

WITH new_users AS (
    -- 步骤1：获取某日所有新增用户
    SELECT user_id, DATE(register_time) AS register_date
    FROM user_registration
    WHERE DATE(register_time) = '2024-01-01'
),
next_day_activity AS (
    -- 步骤2：找出这些用户在次日的活跃记录（去重）
    SELECT DISTINCT n.user_id
    FROM new_users n
    INNER JOIN user_activity a 
        ON n.user_id = a.user_id
        AND DATE(a.activity_time) = DATE_ADD(n.register_date, INTERVAL 1 DAY)
)
-- 步骤3：计算留存率
SELECT 
    COUNT(DISTINCT n.user_id) AS total_new_users,
    COUNT(DISTINCT nd.user_id) AS retained_users,
    ROUND(COUNT(DISTINCT nd.user_id) * 100.0 / COUNT(DISTINCT n.user_id), 2) AS retention_rate
FROM new_users n
LEFT JOIN next_day_activity nd ON n.user_id = nd.user_id;

Q: 为什么用LEFT JOIN而不是INNER JOIN？

因为LEFT JOIN能保证即使次日没有活跃的用户（留存失败），也会被计入分母，分子则为0，如果使用INNER JOIN，会漏掉未留存的用户，导致留存率虚高。

2 用Python脚本实现自动化计算（适用于大数据量或跨周期）

当需要计算多日的留存率,或数据存储在Hive、Spark等大数据平台时，Python脚本更灵活：

import pandas as pd
from datetime import timedelta
def calculate_d1_retention(reg_df: pd.DataFrame, activity_df: pd.DataFrame, target_date: str):
    """
    reg_df: 包含user_id, register_time的DataFrame
    activity_df: 包含user_id, activity_time的DataFrame
    target_date: 要计算留存的日期, 格式'YYYY-MM-DD'
    """
    # 筛选当日新增用户
    reg_day = reg_df[reg_df['register_time'].dt.date == pd.to_datetime(target_date).date()].copy()
    if reg_day.empty:
        return {"date": target_date, "total_new": 0, "retained": 0, "rate": 0}
    # 计算次日日期
    next_day = pd.to_datetime(target_date) + timedelta(days=1)
    # 筛选次日的活跃用户（去重，一个用户只计一次）
    next_day_activity = activity_df[
        activity_df['activity_time'].dt.date == next_day.date()
    ]['user_id'].unique()
    # 求交集：新增用户中在次日活跃的
    retained = set(reg_day['user_id'].unique()) & set(next_day_activity)
    rate = round(len(retained) * 100 / len(reg_day), 2)
    return {
        "date": target_date,
        "total_new": len(reg_day),
        "retained": len(retained),
        "rate": rate
    }
# 示例调用（假设已加载数据）
result = calculate_d1_retention(registrations, activities, "2024-06-01")
print(f"次日留存率为: {result['rate']}%")

高级技巧：如果要计算过去30天每天的留存率，可以用循环或apply函数批量处理，结果可自动生成趋势图。