1. Active User 是什么

Active User，简称 AU，表示在指定时间范围内，完成了某种“有效行为”的去重用户数。

它不是一个天然统一的指标，而是由三个口径共同定义：

因此，一个完整定义应该是：

DAU = 在某自然日内，至少发生一次符合活跃条件事件的去重用户数。

通用计算形式为：

1
2
3

COUNT(DISTINCT CASE
    WHEN is_active_event = 1 THEN user_id
END)

在不同系统中，“Active”口径可能不同。例如，官方定义中，活跃用户通常强调用户在指定日期范围内发生了符合参与条件的行为，而总用户只要求触发过事件。因此，在业务数据场景中不能只写“AU”，还必须同时说明活跃事件、统计窗口和用户标识。 [support.google.com]

1.1 DAU、WAU、MAU

• DAU：Daily Active Users，日活跃用户数
• WAU：Weekly Active Users，周活跃用户数
• MAU：Monthly Active Users，月活跃用户数

假设同一个用户：

• 8 月 1 日活跃
• 8 月 2 日活跃
• 8 月 10 日活跃

那么：

• 8 月 1 日 DAU：计数 1
• 8 月 2 日 DAU：计数 1
• 8 月 1 日至 7 日 WAU：仍然只计数 1（因为这一周出现的是同一个用户）
• 8 月 MAU：仍然只计数 1（因为这一个月出现的是同一个用户）

所以：

WAU 不能通过七天 DAU 相加得到，MAU 也不能通过每天 DAU 相加得到。

因为 AU 本质上是：集合中不同用户的数量，而不是事件数量。

2. AU在大数据场景中的常见应用

以AU为基础可以扩展出多维分析、漏斗对比、留存计算：

• 多维分析：如你之前所示，按市场、设备等维度拆分 AU，了解不同分群的用户活跃情况。
• 漏斗对比：比较不同渠道的 DAU 变化，辅助运营决策。
• 留存计算：基于每日 AU 计算次日/7日/30日留存率。

2.1 多维分析：不同分群的用户活跃情况

数字产品的用户生命周期分析框架如下：

多维 AU 分析，是把整体活跃用户集合按照不同维度进行切分，观察不同用户群体、业务区域或内容类型的活跃表现。

——这个思路在移动应用和广告分析领域是通用的分析方法，各家平台都会提供类似的维度：

• 百度移动统计的常用维度就包含：品牌、设备型号、操作系统、运营商、、渠道、地域（国家/省/市）等
• Apple App Store Connect​ 的分析维度包含：App Version、Platform Version、Region、Product Page 等
• Google Firebase / Google Mobile Ads SDK​ 自动采集的用户属性包含：国家、设备品牌、设备类别、应用版本、操作系统版本、兴趣类别等
• Braze​ 等用户参与平台也按设备类型、平台、内容互动情况等维度评估活跃用户

2.1.1 基本计算方式

假设原始行为数据如下：

按 Market + Device 计算 DAU：

1
2
3

SELECT Date, Market, Device, COUNT(DISTINCT UserId) AS DAU
FROM table
GROUP BY Date, Market, Device;

这里可以回答：

• US 市场 Mobile 用户有多少？——2个
• 不同设备上的用户活跃分布如何？——Mobile的用户活跃度高于PC设备
• 某个 Market 的 DAU 下跌是否集中在某种设备？——由于目前只有一天的数据，暂时看不出下跌
• 某个 类型文章 的活跃用户增长主要来自哪个 Market？——由于目前只有一天的数据，暂时看不出下跌

2.1.2 多维 AU 不能直接上卷

上面的三个分组不能直接相加得到整体 AU：

1
2
3
4
5

US Mobile AU = 2
US PC AU     = 1

不能推导：
US Overall AU = 2 + 1 = 3

因为 U001 同时使用了 Mobile 和 PC。

正确结果是：

1
2
3
4
5
6
7
8

US 用户集合：

Mobile = {U001, U002}
PC     = {U001}

并集 = {U001, U002}

US Overall AU = 2

用集合表达：

1

AU(Mobile ∪ PC) <= AU(Mobile) + AU(PC)

只有在能够保证用户不会跨分组出现时，分组 AU 才能直接相加。但实际的 市场/设备/内容/供应商 场景通常不能保证这一点。

2.1.3 什么时候可以直接相加

结合着两个指标理解：

• 浏览量PageViewCount：发生了多少次内容消费行为

• 活跃用户数PageViewAUCount：有多少个不同用户发生过内容消费行为

例如：

• PageViewCount 可以反映内容被消费了多少次；

• PageViewAUCount 可以反映内容覆盖了多少不同用户。

但 Partner A 的整体 AU 不能计算为2,000 + 1,500 = 3,500，因为同一个用户可能同时看过 C001 和 C002。

正确方式是基于 Partner A 范围内的明细重新去重：

1
2
3
4
5
6
7
8
9

SELECT
    date,
    partner,
    COUNT(DISTINCT user_id) AS partner_au
FROM user_event
WHERE is_active_event = 1
GROUP BY
    date,
    partner;

这也解释了为什么数据模型中需要同时保存：

1. 叶子级别的 Content AU
2. Content = All 的 Partner AU
3. Market = All、Device = All 等不同上卷组合的 AU

这些 All 粒度的 AU 不是由叶子行求和得到的，而是针对对应维度组合重新去重计算出来的

2.1.4 多维分析的业务价值

多维 AU 分析主要用于定位“整体变化来自哪里”。

例如整体 DAU 下降 15%，继续拆分可能发现：

1
2
3
4
5
6

整体 DAU -15%
    ├── US Market -3%
    ├── UK Market -2%
    └── DE Market -40%
            ├── Mobile -5%
            └── PC -65%

这样可以将问题进一步定位到：

• 特定市场
• 特定设备
• 特定版本
• 特定渠道
• 特定内容类型

如果 PV （浏览量）未明显下降，但 AU （活跃用户数）大幅下降，需要重点检查：

• 用户标识是否缺失
• UserId 生成逻辑是否变化
• 去重逻辑是否变化
• 某些用户事件是否没有进入上游
• 匿名用户是否被统一写成同一个默认 ID

2.2 漏斗对比：不同渠道的用户转化情况

这里需要先区分两个概念：

只比较不同渠道的 DAU 变化，严格来说属于渠道趋势对比，不是完整的漏斗分析。

真正的漏斗要求存在一组有先后顺序的业务阶段，例如：

1
2
3
4
5
6
7
8
9

内容曝光
  ↓
内容点击
  ↓
开始阅读
  ↓
有效阅读
  ↓
订阅或购买

2.2.1 渠道 DAU 对比

如果只是比较渠道活跃情况，可以计算：

这可以回答：

• 哪个渠道带来的活跃用户最多？
• 某个渠道 DAU 是否持续增长？
• 一次运营活动是否带来了更多活跃用户？
• 渠道增长是新增用户增长，还是老用户回流？

但仅有 DAU 仍不能判断渠道质量。

例如：

A 的活跃规模更大，但购买转化率只有：1%

B 的购买转化率是： 4%

所以渠道评估通常需要同时看：

• 活跃用户规模
• 转化用户数
• 转化率
• 留存率
• 人均消费深度

2.2.2 真正的用户漏斗

假设定义以下阶段：

1. ExposureUser：看到内容曝光
2. ClickUser：点击内容
3. ReadUser：开始阅读
4. EffectiveReadUser：阅读超过 N 秒
5. SubscribeUser：完成订阅

每一步都应该按照用户去重：

1
2
3
4

曝光用户数 = COUNT(DISTINCT exposure_user_id)
点击用户数 = COUNT(DISTINCT click_user_id)
有效阅读用户数 = COUNT(DISTINCT effective_read_user_id)
订阅用户数 = COUNT(DISTINCT subscribe_user_id)

阶段转化率：

1
2
3
4

点击率 = 点击用户数 / 曝光用户数
有效阅读率 = 有效阅读用户数 / 点击用户数
订阅转化率 = 订阅用户数 / 有效阅读用户数
整体转化率 = 订阅用户数 / 曝光用户数

2.2.3 漏斗必须注意用户集合约束

漏斗中的后一步用户，原则上应该是前一步用户集合的子集：

1
2
3

SubscribeUser ⊆ EffectiveReadUser
EffectiveReadUser ⊆ ClickUser
ClickUser ⊆ ExposureUser

实际计算时，不能简单统计每天触发各事件的所有用户，否则可能出现：

1
2

曝光用户数：1,000
点击用户数：1,200

这通常说明：

• 点击事件缺少对应曝光事件
• 曝光事件丢失
• 统计周期对不齐
• 用户在统计周期之前曝光、周期内点击
• 不同阶段用了不同的用户标识
• Join 条件或事件时间逻辑存在问题

因此，严格漏斗一般需要根据 user_id 和事件顺序建立用户路径。

2.2.4 漏斗中的时间窗口

漏斗还必须定义转化窗口。

例如：

用户曝光后 24 小时内发生点击，点击后 7 天内发生订阅。

如果不定义窗口，一个用户 8 月 1 日曝光、8 月 20 日订阅，是否还算同一次转化就会产生歧义。

因此完整漏斗口径至少包括：

• 漏斗起始事件
• 后续阶段事件
• 用户标识
• 事件先后顺序
• 阶段间允许的时间窗口
• 是否允许跨天
• 是否允许同一用户多次进入漏斗
• 用户归属哪个渠道

2.2.5 渠道归因问题

用户可能经过多个渠道：

1
2
3
4

Search 曝光
→ Direct 访问
→ Recommendation 点击
→ 完成订阅

此时订阅算给哪个渠道，需要提前定义归因规则，例如：

• First-touch：归因给首次渠道
• Last-touch：归因给最后一次渠道
• Conversion-touch：归因给直接促成转化的渠道
• 多触点归因：按照规则分摊

所以“比较渠道漏斗”并不只是按 Channel 做一个 GROUP BY，还需要保证渠道归因规则一致。

2.3 留存计算：次日、7 日、30 日留存

留存用于回答：

一批在某天活跃或首次活跃的用户，经过一段时间后，还有多少人再次活跃？

留存通常基于用户集合或 Cohort，也就是具有共同起始条件的一批用户进行计算。

2.3.1 不能只使用每日 AU 数值计算留存

假设：

1
2

8 月 1 日 DAU = 100
8 月 2 日 DAU = 120

仅凭这两个数字，无法计算次日留存率。因为我们不知道 8 月 2 日的 120 个用户中，有多少人在 8 月 1 日也活跃。

可能是：

1
2
3
4

情况 A：
8 月 1 日用户 = {U001 ... U100}
8 月 2 日用户中有 80 人来自 8 月 1 日
次日留存率 = 80 / 100 = 80%

也可能是：

1
2
3

情况 B：
8 月 2 日用户中只有 10 人来自 8 月 1 日
次日留存率 = 10 / 100 = 10%

所以更准确的表述是：

留存基于每日活跃用户明细集合计算，而不是基于已经聚合好的每日 AU 数值计算。

2.3.2 留存的集合公式

令：

1
2
3
4

A0 = 基准日用户集合
A1 = 基准日后第 1 天的活跃用户集合
A7 = 基准日后第 7 天的活跃用户集合
A30 = 基准日后第 30 天的活跃用户集合

那么：

1
2
3
4
5
6
7
8

次日留存用户数 = |A0 ∩ A1|
次日留存率     = |A0 ∩ A1| / |A0|

7 日留存用户数 = |A0 ∩ A7|
7 日留存率     = |A0 ∩ A7| / |A0|

30 日留存用户数 = |A0 ∩ A30|
30 日留存率     = |A0 ∩ A30| / |A0|

其中：

• |A0| 表示集合 A0 的用户数
• ∩ 表示两个用户集合的交集

2.3.3 新增用户留存和活跃用户留存

这是留存分析中非常重要的口径区别。

2.3.3.1 新增用户留存

基准用户是当天首次出现的用户：

1
2
3
4

8 月 1 日新增用户
→ 8 月 2 日是否再次活跃
→ 8 月 8 日是否再次活跃
→ 8 月 31 日是否再次活跃

适合评估：

• 新用户质量
• 拉新渠道质量
• 首次体验效果
• 新版本 onboarding 效果

2.3.3.2 活跃用户留存

基准用户是当天所有活跃用户：

1
2

8 月 1 日所有 AU
→ 后续是否再次活跃

适合评估：

• 整体用户黏性
• 产品持续使用情况
• 内容用户回访情况

两种口径不能混用。因为新增用户集合通常只是当日所有活跃用户的一个子集。

2.3.4 “第 7 日留存”与“7 日内留存”

这两个指标也不相同。

2.3.4.1 第 7 日留存

用户必须在基准日后的第 7 个自然日再次活跃：

1
2

cohort_date = 8 月 1 日
retention_date = 8 月 8 日

2.3.4.2 7 日内留存

用户在基准日后的第 1 至第 7 日内，只要任意一天回来就算留存：

1

A0 ∩ (A1 ∪ A2 ∪ ... ∪ A7)

一般来说：

1

7 日内留存率 >= 第 7 日留存率

因此报表中只写“7 日留存”是不够严谨的，需要说明：

• 是第 7 日留存
• 还是 7 日内任意一天回来
• 还是第 7 日及以后仍有活跃

2.3.5 用户留存的SQL 实现思路

假设先生成用户每日活跃表：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

WITH daily_active AS (
    SELECT DISTINCT
        event_date,
        user_id
    FROM user_event
    WHERE is_active_event = 1
),
cohort AS (
    SELECT
        event_date AS cohort_date,
        user_id
    FROM daily_active
    WHERE event_date = '2026-08-01'
)
SELECT
    c.cohort_date,
    COUNT(DISTINCT c.user_id) AS cohort_users,
    COUNT(DISTINCT CASE
        WHEN DATEDIFF(d.event_date, c.cohort_date) = 1
        THEN c.user_id
    END) AS day_1_retained_users,
    COUNT(DISTINCT CASE
        WHEN DATEDIFF(d.event_date, c.cohort_date) = 7
        THEN c.user_id
    END) AS day_7_retained_users,
    COUNT(DISTINCT CASE
        WHEN DATEDIFF(d.event_date, c.cohort_date) = 30
        THEN c.user_id
    END) AS day_30_retained_users
FROM cohort c
LEFT JOIN daily_active d
    ON c.user_id = d.user_id
GROUP BY
    c.cohort_date;

然后计算：

1
2
3

Day 1 Retention = day_1_retained_users / cohort_users
Day 7 Retention = day_7_retained_users / cohort_users
Day 30 Retention = day_30_retained_users / cohort_users

2.4 三类应用之间的关系

可以把三类分析理解成三个不同问题：

3. 在数据模型中的关键设计原则

3.1 保留统一的用户标识

如果一部分事件使用 UserId，另一部分使用 DeviceId，则可能出现：

• 同一个人被识别成多个用户
• 不同漏斗阶段无法关联
• 留存率被低估
• AU 被高估

因此最好建立统一的 CanonicalUserId 或明确身份拼接规则。

3.2 明确时间口径

需要固定：

• 使用 UTC 还是 Market Local Time
• 自然日从几点到几点
• 跨市场报表按哪个时区计算
• 迟到数据如何回补
• 回补后是否重算历史 AU 和留存

对于跨 Market 的全球数据，同一个 UTC 时间可能属于不同地区的不同自然日。

3.3 AU 字段不能默认 SUM

在 BI 或语义模型中，AU 应标记为：

• 不可加指标
• Non-additive Metric
• 禁止默认 SUM

因为下面这些通常都是错误的：

1
2
3
4

月 AU = 每日 AU 求和
整体 AU = 各 Market AU 求和
Partner AU = 各 Content AU 求和
全设备 AU = 各 Device AU 求和

如果下游经常查询固定的维度组合，可以提前生成每种 All 粒度的精确 AU；如果需要大量灵活的任意维度上卷，则可以考虑用户明细、Bitmap 或近似去重结构。

4. 一句话总结

Active User 的本质是“在特定时间窗口内，满足特定活跃条件的去重用户集合大小”。

因此：

• 多维分析是在不同维度范围内分别计算这个集合。用来了解不同分群的用户活跃情况。
• 漏斗分析是在多个有先后关系的行为阶段之间比较用户集合。比较不同渠道的 DAU 变化，辅助运营决策。
• 留存分析是在不同时间点之间计算同一批用户集合的交集。基于每日 AU 计算次日/7日/30日留存率。
• AU 不是普通可加指标，跨日期、设备、市场、内容或渠道汇总时，通常必须重新基于用户粒度去重。