文章目录1. Active User 是什么1.1 DAU、WAU、MAU2. AU在大数据场景中的常见应用2.1 多维分析不同分群的用户活跃情况2.1.1 基本计算方式2.1.2 多维 AU 不能直接上卷2.1.3 什么时候可以直接相加2.1.4 多维分析的业务价值2.2 漏斗对比不同渠道的用户转化情况2.2.1 渠道 DAU 对比2.2.2 真正的用户漏斗2.2.3 漏斗必须注意用户集合约束2.2.4 漏斗中的时间窗口2.2.5 渠道归因问题2.3 留存计算次日、7 日、30 日留存2.3.1 不能只使用每日 AU 数值计算留存2.3.2 留存的集合公式2.3.3 新增用户留存和活跃用户留存2.3.3.1 新增用户留存2.3.3.2 活跃用户留存2.3.4 “第 7 日留存”与“7 日内留存”2.3.4.1 第 7 日留存2.3.4.2 7 日内留存2.3.5 用户留存的SQL 实现思路2.4 三类应用之间的关系3. 在数据模型中的关键设计原则3.1 保留统一的用户标识3.2 明确时间口径3.3 AU 字段不能默认 SUM4. 一句话总结我的网站原文 https://eleanora-lyh.github.io/MyLearningNotes/csdn处的文章会尽快同步更新欢迎大家来访问1. Active User 是什么Active User简称 AU表示在指定时间范围内完成了某种“有效行为”的去重用户数。它不是一个天然统一的指标而是由三个口径共同定义口径要回答的问题示例用户标识“谁”算一个用户UserId、CookieId时间窗口在什么时间内活跃一天Daily、一周Weekly、一个月Monthly活跃行为做了什么才算活跃打开 App、阅读内容、观看超过 N 秒、完成购买因此一个完整定义应该是DAU 在某自然日内至少发生一次符合活跃条件事件的去重用户数。通用计算形式为COUNT(DISTINCTCASEWHENis_active_event1THENuser_idEND)在不同系统中“Active”口径可能不同。例如官方定义中活跃用户通常强调用户在指定日期范围内发生了符合参与条件的行为而总用户只要求触发过事件。因此在业务数据场景中不能只写“AU”还必须同时说明活跃事件、统计窗口和用户标识。 [support.google.com]1.1 DAU、WAU、MAUDAUDaily Active Users日活跃用户数WAUWeekly Active Users周活跃用户数MAUMonthly Active Users月活跃用户数假设同一个用户8 月 1 日活跃8 月 2 日活跃8 月 10 日活跃那么8 月 1 日 DAU计数 18 月 2 日 DAU计数 18 月 1 日至 7 日 WAU仍然只计数 1因为这一周出现的是同一个用户8 月 MAU仍然只计数 1因为这一个月出现的是同一个用户所以WAU 不能通过七天 DAU 相加得到MAU 也不能通过每天 DAU 相加得到。因为 AU 本质上是集合中不同用户的数量而不是事件数量。2. AU在大数据场景中的常见应用以AU为基础可以扩展出多维分析、漏斗对比、留存计算多维分析如你之前所示按市场、设备等维度拆分 AU了解不同分群的用户活跃情况。漏斗对比比较不同渠道的 DAU 变化辅助运营决策。留存计算基于每日 AU 计算次日/7日/30日留存率。2.1 多维分析不同分群的用户活跃情况数字产品的用户生命周期分析框架如下分析环节核心问题对应维度用户画像​用户是谁用什么设备用户所在地域、设备型号用户获取​用户从哪里来平台、渠道用户行为​用户在产品里做什么兴趣类别、内容用户体验​用户在不同版本下的体验如何APP版本商业表现​用户在哪些市场/区域贡献价值市场、国家多维 AU 分析是把整体活跃用户集合按照不同维度进行切分观察不同用户群体、业务区域或内容类型的活跃表现。——这个思路在移动应用和广告分析领域是通用的分析方法各家平台都会提供类似的维度百度移动统计的常用维度就包含品牌、设备型号、操作系统、运营商、、渠道、地域国家/省/市等Apple App Store Connect​ 的分析维度包含App Version、Platform Version、Region、Product Page 等Google Firebase / Google Mobile Ads SDK​ 自动采集的用户属性包含国家、设备品牌、设备类别、应用版本、操作系统版本、兴趣类别等Braze​ 等用户参与平台也按设备类型、平台、内容互动情况等维度评估活跃用户2.1.1 基本计算方式假设原始行为数据如下UserIdDateMarketDeviceContentU0012026-08-01USMobileC001U0012026-08-01USPCC002U0022026-08-01USMobileC001U0032026-08-01UKMobileC003按Market Device计算 DAUSELECTDate,Market,Device,COUNT(DISTINCTUserId)ASDAUFROMtableGROUPBYDate,Market,Device;DateMarketDeviceDAU2026-08-01USMobile22026-08-01USPC12026-08-01UKMobile1这里可以回答US 市场 Mobile 用户有多少——2个不同设备上的用户活跃分布如何——Mobile的用户活跃度高于PC设备某个 Market 的 DAU 下跌是否集中在某种设备——由于目前只有一天的数据暂时看不出下跌某个 类型文章 的活跃用户增长主要来自哪个 Market——由于目前只有一天的数据暂时看不出下跌2.1.2 多维 AU 不能直接上卷上面的三个分组不能直接相加得到整体 AUUS Mobile AU2US PC AU1不能推导 US Overall AU213因为U001同时使用了 Mobile 和 PC。正确结果是US 用户集合 Mobile {U001, U002} PC {U001} 并集 {U001, U002} US Overall AU 2用集合表达AU(Mobile ∪ PC) AU(Mobile) AU(PC)只有在能够保证用户不会跨分组出现时分组 AU 才能直接相加。但实际的 市场/设备/内容/供应商 场景通常不能保证这一点。2.1.3 什么时候可以直接相加结合着两个指标理解浏览量PageViewCount发生了多少次内容消费行为活跃用户数PageViewAUCount有多少个不同用户发生过内容消费行为例如PartnerContentPageViewCountPageViewAUCountPartner AC00110,0002,000Partner AC0028,0001,500PageViewCount可以反映内容被消费了多少次PageViewAUCount可以反映内容覆盖了多少不同用户。但 Partner A 的整体 AU 不能计算为2,000 1,500 3,500因为同一个用户可能同时看过 C001 和 C002。正确方式是基于 Partner A 范围内的明细重新去重SELECTdate,partner,COUNT(DISTINCTuser_id)ASpartner_auFROMuser_eventWHEREis_active_event1GROUPBYdate,partner;这也解释了为什么数据模型中需要同时保存叶子级别的 Content AUContent All的 Partner AUMarket All、Device All等不同上卷组合的 AU这些All粒度的 AU 不是由叶子行求和得到的而是针对对应维度组合重新去重计算出来的2.1.4 多维分析的业务价值多维 AU 分析主要用于定位“整体变化来自哪里”。例如整体 DAU 下降 15%继续拆分可能发现整体 DAU -15% ├── US Market -3% ├── UK Market -2% └── DE Market -40% ├── Mobile -5% └── PC -65%这样可以将问题进一步定位到特定市场特定设备特定版本特定渠道特定内容类型如果 PV 浏览量未明显下降但 AU 活跃用户数大幅下降需要重点检查用户标识是否缺失UserId生成逻辑是否变化去重逻辑是否变化某些用户事件是否没有进入上游匿名用户是否被统一写成同一个默认 ID2.2 漏斗对比不同渠道的用户转化情况这里需要先区分两个概念只比较不同渠道的 DAU 变化严格来说属于渠道趋势对比不是完整的漏斗分析。真正的漏斗要求存在一组有先后顺序的业务阶段例如内容曝光 ↓ 内容点击 ↓ 开始阅读 ↓ 有效阅读 ↓ 订阅或购买2.2.1 渠道 DAU 对比如果只是比较渠道活跃情况可以计算DateChannelDAU2026-08-01Search20,0002026-08-01Recommendation35,0002026-08-01Direct10,000这可以回答哪个渠道带来的活跃用户最多某个渠道 DAU 是否持续增长一次运营活动是否带来了更多活跃用户渠道增长是新增用户增长还是老用户回流但仅有 DAU 仍不能判断渠道质量。例如ChannelDAU购买用户数购买转化率A100,0001,0001%B20,0008004%A 的活跃规模更大但购买转化率只有1%B 的购买转化率是 4%所以渠道评估通常需要同时看活跃用户规模转化用户数转化率留存率人均消费深度2.2.2 真正的用户漏斗假设定义以下阶段ExposureUser看到内容曝光ClickUser点击内容ReadUser开始阅读EffectiveReadUser阅读超过 N 秒SubscribeUser完成订阅每一步都应该按照用户去重曝光用户数COUNT(DISTINCTexposure_user_id)点击用户数COUNT(DISTINCTclick_user_id)有效阅读用户数COUNT(DISTINCTeffective_read_user_id)订阅用户数COUNT(DISTINCTsubscribe_user_id)阶段转化率点击率 点击用户数 / 曝光用户数 有效阅读率 有效阅读用户数 / 点击用户数 订阅转化率 订阅用户数 / 有效阅读用户数 整体转化率 订阅用户数 / 曝光用户数2.2.3 漏斗必须注意用户集合约束漏斗中的后一步用户原则上应该是前一步用户集合的子集SubscribeUser ⊆ EffectiveReadUser EffectiveReadUser ⊆ ClickUser ClickUser ⊆ ExposureUser实际计算时不能简单统计每天触发各事件的所有用户否则可能出现曝光用户数1,000 点击用户数1,200这通常说明点击事件缺少对应曝光事件曝光事件丢失统计周期对不齐用户在统计周期之前曝光、周期内点击不同阶段用了不同的用户标识Join 条件或事件时间逻辑存在问题因此严格漏斗一般需要根据user_id和事件顺序建立用户路径。2.2.4 漏斗中的时间窗口漏斗还必须定义转化窗口。例如用户曝光后 24 小时内发生点击点击后 7 天内发生订阅。如果不定义窗口一个用户 8 月 1 日曝光、8 月 20 日订阅是否还算同一次转化就会产生歧义。因此完整漏斗口径至少包括漏斗起始事件后续阶段事件用户标识事件先后顺序阶段间允许的时间窗口是否允许跨天是否允许同一用户多次进入漏斗用户归属哪个渠道2.2.5 渠道归因问题用户可能经过多个渠道Search 曝光 → Direct 访问 → Recommendation 点击 → 完成订阅此时订阅算给哪个渠道需要提前定义归因规则例如First-touch归因给首次渠道Last-touch归因给最后一次渠道Conversion-touch归因给直接促成转化的渠道多触点归因按照规则分摊所以“比较渠道漏斗”并不只是按Channel做一个GROUP BY还需要保证渠道归因规则一致。2.3 留存计算次日、7 日、30 日留存留存用于回答一批在某天活跃或首次活跃的用户经过一段时间后还有多少人再次活跃留存通常基于用户集合或 Cohort也就是具有共同起始条件的一批用户进行计算。2.3.1 不能只使用每日 AU 数值计算留存假设8 月 1 日 DAU 100 8 月 2 日 DAU 120仅凭这两个数字无法计算次日留存率。因为我们不知道 8 月 2 日的 120 个用户中有多少人在 8 月 1 日也活跃。可能是情况 A 8 月 1 日用户 {U001 ... U100} 8 月 2 日用户中有 80 人来自 8 月 1 日 次日留存率 80 / 100 80%也可能是情况 B 8 月 2 日用户中只有 10 人来自 8 月 1 日 次日留存率 10 / 100 10%所以更准确的表述是留存基于每日活跃用户明细集合计算而不是基于已经聚合好的每日 AU 数值计算。2.3.2 留存的集合公式令A0 基准日用户集合 A1 基准日后第 1 天的活跃用户集合 A7 基准日后第 7 天的活跃用户集合 A30 基准日后第 30 天的活跃用户集合那么次日留存用户数 |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 新增用户留存基准用户是当天首次出现的用户8 月 1 日新增用户 → 8 月 2 日是否再次活跃 → 8 月 8 日是否再次活跃 → 8 月 31 日是否再次活跃适合评估新用户质量拉新渠道质量首次体验效果新版本 onboarding 效果2.3.3.2 活跃用户留存基准用户是当天所有活跃用户8 月 1 日所有 AU → 后续是否再次活跃适合评估整体用户黏性产品持续使用情况内容用户回访情况两种口径不能混用。因为新增用户集合通常只是当日所有活跃用户的一个子集。2.3.4 “第 7 日留存”与“7 日内留存”这两个指标也不相同。2.3.4.1 第 7 日留存用户必须在基准日后的第 7 个自然日再次活跃cohort_date 8 月 1 日 retention_date 8 月 8 日2.3.4.2 7 日内留存用户在基准日后的第 1 至第 7 日内只要任意一天回来就算留存A0 ∩ (A1 ∪ A2 ∪ ... ∪ A7)一般来说7 日内留存率 第 7 日留存率因此报表中只写“7 日留存”是不够严谨的需要说明是第 7 日留存还是 7 日内任意一天回来还是第 7 日及以后仍有活跃2.3.5 用户留存的SQL 实现思路假设先生成用户每日活跃表WITHdaily_activeAS(SELECTDISTINCTevent_date,user_idFROMuser_eventWHEREis_active_event1),cohortAS(SELECTevent_dateAScohort_date,user_idFROMdaily_activeWHEREevent_date2026-08-01)SELECTc.cohort_date,COUNT(DISTINCTc.user_id)AScohort_users,COUNT(DISTINCTCASEWHENDATEDIFF(d.event_date,c.cohort_date)1THENc.user_idEND)ASday_1_retained_users,COUNT(DISTINCTCASEWHENDATEDIFF(d.event_date,c.cohort_date)7THENc.user_idEND)ASday_7_retained_users,COUNT(DISTINCTCASEWHENDATEDIFF(d.event_date,c.cohort_date)30THENc.user_idEND)ASday_30_retained_usersFROMcohort cLEFTJOINdaily_active dONc.user_idd.user_idGROUPBYc.cohort_date;然后计算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_users2.4 三类应用之间的关系可以把三类分析理解成三个不同问题分析类型要回答的问题说人话就是去重范围核心运算多维分析活跃用户来自哪些分群谁在活跃来自哪个 Market、Device、Partner、Channel在某个维度组合内去重分组后去重漏斗分析用户在不同业务阶段流失在哪里用户做到了哪一步曝光、点击、阅读、订阅之间在哪里流失在每个业务阶段内去重并建立阶段关系阶段集合的包含与转化留存分析同一批用户后续是否再次回来用户以后还回来吗次日、第 7 日、第 30 日是否再次活跃在不同日期的用户集合之间求交集跨时间集合求交集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因为下面这些通常都是错误的月 AU 每日 AU 求和 整体 AU 各 Market AU 求和 Partner AU 各 Content AU 求和 全设备 AU 各 Device AU 求和如果下游经常查询固定的维度组合可以提前生成每种All粒度的精确 AU如果需要大量灵活的任意维度上卷则可以考虑用户明细、Bitmap 或近似去重结构。4. 一句话总结Active User 的本质是“在特定时间窗口内满足特定活跃条件的去重用户集合大小”。因此多维分析是在不同维度范围内分别计算这个集合。用来了解不同分群的用户活跃情况。漏斗分析是在多个有先后关系的行为阶段之间比较用户集合。比较不同渠道的 DAU 变化辅助运营决策。留存分析是在不同时间点之间计算同一批用户集合的交集。基于每日 AU 计算次日/7日/30日留存率。AU 不是普通可加指标跨日期、设备、市场、内容或渠道汇总时通常必须重新基于用户粒度去重。