「周均日活」比「周活去重」高 38%：均值化与去重化的数学关系、一个重叠系数与看板双指标呈现方案

结论先行：「一周内每天日活的算术平均」和「一周内的去重活跃用户」不是同一个指标的两种精度，而是两个不同的指标——前者是"人次的平均密度"，后者是"人数"。两者之间的比值由用户活跃的重叠模式决定，而重叠模式恰恰是留存运营真正想看的信号。把这两个数混用，最直接的后果就是：看板上的"周活"曲线被运营动作（拉新、召回）和自然留存同时驱动，谁也说不清涨跌是谁的功劳。

一、现象与背景

去年 Q3，我们一个 App 的周会看板上有两个数：

「周均日活（7 天 DAU 算术平均）」：40.2 万
「周活（7 天去重 user_id）」：28.9 万

两个数同屏出现，差了 38%。产品当时的第一反应是"是不是去重逻辑有 bug"，数据同学拉了 3 天明细核对埋点，确认两边 SQL 都没错。真正的分歧在下一个问题：

"那周会汇报应该用哪个数？"

当时的选择是"用周均日活，因为它更平滑、波动更小"。三个月后复盘，发现这个选择掩盖了一个真实问题：周均日活涨了 6%，但周活去重只涨了 1.2%——增长几乎全部来自"老用户来得更勤"（频次上升），而不是"新面孔变多"（覆盖扩大）。如果周会一直只看"更平滑"的那个数，这个结构性差异根本不会被讨论。

这不是个例。我们翻了 2024 年下半年的告警记录，涉及"周活 / 月活 / 周均 X"的口径争议里，7 条里有 4 条的根因都是这两个数被当成"同一指标的两个精度"来用。

二、原理：为什么两个数必然不相等，以及比值意味着什么

设第 i 天的活跃用户集合为 U_i（i = 1..7）。

周均日活 = (1/7) × Σ|U_i|，量纲是"人次/天"——它统计的是访问次数的平均密度，同一个用户 7 天都来，贡献 7 人次。
周活去重 = |U_1 ∪ U_2 ∪ … ∪ U_7|，量纲是"人"——它统计的是覆盖的人数，同一个用户 7 天都来，只贡献 1 人。

两者之间没有固定的换算关系，但有一个恒等式把它们钉死在一起：

周均日活 / 周活去重 = (1/7) × Σ |U_i| / |∪ U_i|

右边这个比值我记作周活跃重叠系数 k：k = (1/7)·Σ|U_i| / |∪U_i|。它的取值范围是 [1, 7]：

k = 1：7 天的用户集合两两不相交，每个来的人都只来 1 天（典型的高换血低留存产品）；
k = 7：7 天来的是同一批人，天天都来（理论上限，真实产品到不了）；
中间值：由"同一批人反复来"与"每天来的人换一批"的混合比例决定。

关键推论：k 本身就是一个运营信号。 k 上升 = 用户"来得更勤"（频次/留存驱动）；k 下降 = "来的人换了一批"（拉新或流失驱动）。所以"周均日活涨 6%、周活去重涨 1.2%"翻译成 k 的语言就是：k 从约 1.39 升到约 1.43，增量 100% 来自频次侧，覆盖侧基本没动。

再补一层：这个比值和留存是同一个硬币的两面。粗略地，k ≈ 1 + (人均周活跃天数 − 1)，人均周活跃天数又由次日/7 日留存决定。所以把"周均日活"和"周活"两个数同时放上看板，中间差出来的那个 k，免费给了你一个留存代理指标——不需要额外算留存报表。

三、具体做法

1. 一张表同时落两个口径（StarRocks / Doris 语法，MySQL 同理）

不要两个数分两张表、两个作业——必须同一次扫描算出来，保证分子分母同源、同一时间窗口：

-- 日粒度明细（事实表已按天分区）
CREATE TABLE dws_user_active (
    dt        DATE,
    user_id   BIGINT,
    PRIMARY KEY (dt, user_id)
);

-- 周粒度双口径物化：同一次扫描，两个数一起出
CREATE TABLE dws_week_active AS
SELECT
    date_trunc('week', dt)          AS week,
    COUNT(DISTINCT user_id)         AS weekly_uv,          -- 周活去重（人）
    SUM(daily_uv) / 7.0             AS weekly_avg_dau,     -- 周均日活（人次/天）
    (SUM(daily_uv) / 7.0)
        / COUNT(DISTINCT user_id)   AS overlap_k          -- 重叠系数
FROM (
    SELECT dt, user_id,
           (SELECT COUNT(DISTINCT user_id)
            FROM dws_user_active d WHERE d.dt = o.dt) AS daily_uv
    FROM dws_user_active o
) t
GROUP BY 1;

实际工程里 daily_uv 建议单独物化成 dws_daily_uv(dt, uv) 再 join，避免上面的相关子查询；核心原则不变：weekly_uv、weekly_avg_dau、overlap_k 三个字段必须来自同一作业、同一分区范围。

2. 看板呈现：双指标 + k 值，而不是二选一

我们最终的看板卡片长这样（一周一个点）：

| 字段 | 示例 | 说明 | |---|---|---| | 周活（去重） | 28.9 万 | 主指标，覆盖人数 | | 周均日活 | 40.2 万 | 副指标，标注"人次口径" | | 活跃密度 k | 1.39 | 两数相除，标注"≈人均周活跃天数" |

三个硬性规则：

两个数必须同卡展示、各自标注量纲（"人" vs "人次/天"），不允许只出其中一个；
趋势告警看 k 的漂移，不看绝对值的涨跌——k 单周漂移超过 10% 才值得拉群讨论，绝对值波动 5% 以内属于正常噪音；
汇报模板里强制出现一句："本周增量中，覆盖贡献 X%，频次贡献 Y%"（X = Δ周活/基期周活，Y = Δk/基期k，两者近似可加）。

3. 给业务方的一句话解释

我们最后在指标字典里写的是：

「周活」回答"这周有多少人来过"；「周均日活」回答"每天平均有多热闹"。一个来 1 天的用户和一周来 7 天的用户，在前者里各算 1 人，在后者里分别算 0.14 和 1.0 人次。两者都正确，回答的是不同的问题。

四、踩过的坑与反直觉之处

"周均日活更平滑，所以更适合汇报"是一个伪优点。 平滑是因为它把"人换了一批"和"人来得更勤"两件事揉进了同一个数里，波动被平均掉了，但结构信息也被抹掉了。平滑不等于稳健，它只是对两种相反动因同时不敏感。
k 不能跨周直接平均。 这是不可加性的又一个变种：第 1 周 k=1.2、第 2 周 k=1.8，"月均 k" 不等于 (1.2+1.8)/2，因为两周的分子分母基数不同。月粒度必须回到 Σ人次/Σ人数 重算——和比率指标不能直接求平均是同一个病（参见站内已有的比率口径讨论）。
拉新大促期间，k 会"健康地下降"。 大促周 k 从 1.4 掉到 1.1，第一反应容易是"留存崩了"，实际是大量一次性新客把分母撑大了。k 的解读必须和"新老客拆分"一起看，单独看 k 的下行会误报。
埋点去重键不一致会让两个数的"差"失去意义。 我们有一次 k 突然从 1.39 跳到 2.1，查了两周，最后发现是客户端埋点的 user_id 在登录态/未登录态用了两套 id 空间——COUNT(DISTINCT) 对脏 id 敏感，SUM(daily) 不敏感，所以差值被放大。教训：k 异常时，先查 id 体系，再查业务。

五、结论与可复用清单

「周均日活」与「周活去重」是两个指标，不是同一指标的两个精度；量纲分别是"人次/天"和"人"，看板必须双出、各自标注。
两者的比值 k = 周均日活 / 周活去重 是一个免费的留存代理指标：k 升 = 频次驱动，k 降 = 覆盖换血；k 单周漂移 >10% 才触发讨论。
k 不可跨窗口平均，月/季粒度必须 Σ人次 / Σ人数 重算；这与比率指标不可简单平均是同一类不可加性。
双口径必须同一作业、同一分区范围、同一 id 体系算出，否则"差值"不可信。
周会汇报模板固定一句话："本周增量中，覆盖贡献 X%，频次贡献 Y%"——把结构摆到台面上，比争论"用哪个数"更有价值。
k 异常排查顺序：先查 id 体系（登录态/设备态混用），再查业务动因（拉新/流失）。

本站已有文章讲过"sum(UV) ≠ 总 UV"的集合不可加性（引用 [1]），本文是它的姊妹篇：同一个不可加性，在"跨维度求和"场景表现为渠道 UV 之和虚高，在"时间窗口均值化"场景表现为周均日活与周活的结构性裂口——前者是横切面问题，后者是纵切面问题，看板设计时两个方向都要设防。

引用

[1] 许砚舟《为什么 sum(UV) 对不上总 UV：去重指标非可加性的三种解法与取舍》

0赞 0收藏 0评论 1浏览