如何在Firebase Analytics中按日维度查看留存分析

Firebase控制台首页默认展示的留存卡片为固定周粒度，没有直接的粒度切换入口，要获取第1日、第2日这类分日留存指标，可以通过以下两种方式实现：

方法1：控制台内自定义探索报表（无需导出数据） #

这是最简便的实现路径，全程在Firebase控制台内操作即可：

• 进入对应项目的Firebase控制台，在左侧「分析」栏目下找到「探索」入口，新建空白探索项目
• 在右侧变量配置区的「技术」分类中，选择留存分析模板
• 在留存配置项中找到粒度选择控件，将默认选中的「周」切换为「日」
• 根据你的业务需求配置判定规则：起始事件默认选first_open（新用户首次打开应用），回访事件默认选session_start（用户启动会话），也可以替换为你自定义的活跃事件（比如完成指定操作、停留时长达标等）
• 配置完成后画布会自动生成分日留存矩阵，你可以直接读取第1日、第2日……第N日的留存率数值，支持按渠道、用户属性、设备类型等维度做拆分对比。

方法2：BigQuery导出原始数据自定义计算 #

如果你需要更灵活的留存计算规则（比如自定义活跃判定标准、超长周期留存、精细化用户分群留存），可以开通Firebase的BigQuery原始数据导出能力，用SQL自主计算：

• 先在Firebase控制台「项目设置-集成」中开通BigQuery导出，选择同步Analytics事件数据，开通后所有事件级原始数据会每日自动同步到对应的BigQuery数据集
• 留存计算的核心逻辑为：先圈定指定日期范围内首次触发起始事件的新用户集合，再匹配这些用户在后续第N天是否触发回访活跃事件，最终计算对应日期的留存用户占比
• 基础日留存计算SQL参考框架如下，可根据自身业务逻辑调整：

-- 新用户分日留存计算示例
WITH new_user_base AS (
  SELECT
    user_pseudo_id,
    DATE(TIMESTAMP_MICROS(event_timestamp)) AS first_open_date
  FROM `替换为你的BigQuery表路径.events_*`
  WHERE event_name = 'first_open'
    -- 限定统计的新用户时间范围
    AND _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)) 
      AND FORMAT_DATE('%Y%m%d', CURRENT_DATE())
  GROUP BY user_pseudo_id, first_open_date
),
user_active_records AS (
  SELECT DISTINCT
    user_pseudo_id,
    DATE(TIMESTAMP_MICROS(event_timestamp)) AS active_date
  FROM `替换为你的BigQuery表路径.events_*`
  WHERE event_name = 'session_start' -- 可替换为自定义活跃判定事件
    -- 覆盖留存计算需要的时间范围
    AND _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 60 DAY)) 
      AND FORMAT_DATE('%Y%m%d', CURRENT_DATE())
)
SELECT
  first_open_date,
  COUNT(DISTINCT new_user_base.user_pseudo_id) AS total_new_user_count,
  -- 第1日留存（次留）
  ROUND(COUNT(DISTINCT CASE WHEN active_date = DATE_ADD(first_open_date, INTERVAL 1 DAY) THEN new_user_base.user_pseudo_id END)
    / COUNT(DISTINCT new_user_base.user_pseudo_id), 4) AS day1_retention_rate,
  -- 第2日留存
  ROUND(COUNT(DISTINCT CASE WHEN active_date = DATE_ADD(first_open_date, INTERVAL 2 DAY) THEN new_user_base.user_pseudo_id END)
    / COUNT(DISTINCT new_user_base.user_pseudo_id), 4) AS day2_retention_rate
  -- 第3日、7日等更长周期留存可按相同逻辑扩展字段
FROM new_user_base
LEFT JOIN user_active_records 
  ON new_user_base.user_pseudo_id = user_active_records.user_pseudo_id
GROUP BY first_open_date
ORDER BY first_open_date DESC

注意：如果你的产品有独立账号体系，建议将计算逻辑中的user_pseudo_id替换为你自主上报的用户唯一ID，避免用户重装、切换设备导致的留存计算偏差。

内容的提问来源于stack exchange，提问作者Рафаэль солихов