「活跃用户」到底怎么定义？产品和数据口径打架怎么办？

-- 同一个DAU指标，不同口径可能差很大
 
-- 口径A：产品定义——打开App就算活跃（包含后台唤醒）
SELECT COUNT(DISTINCT user_id) AS dau_product
FROM dwd_app_event
WHERE dt = '2024-01-15'
  AND event_name = 'app_open';         -- 包含所有app_open事件
 
-- 口径B：运营定义——有明确交互行为才算活跃
SELECT COUNT(DISTINCT user_id) AS dau_ops
FROM dwd_app_event
WHERE dt = '2024-01-15'
  AND event_name IN ('click', 'scroll', 'search', 'purchase');
  -- 只算有交互的用户
 
-- 两个SQL的结果可能差20%，但都没错

-- 出海业务时区处理：按用户当地时间计算DAU
SELECT
  country,
  -- 把UTC时间转换成用户当地时间
  DATE(CONVERT_TZ(event_time, 'UTC', 
    CASE country
      WHEN 'JP' THEN 'Asia/Tokyo'         -- UTC+9
      WHEN 'US' THEN 'America/New_York'    -- UTC-5/UTC-4
      WHEN 'BR' THEN 'America/Sao_Paulo'   -- UTC-3
      ELSE 'UTC'
    END
  )) AS local_date,
  COUNT(DISTINCT user_id) AS dau
FROM dwd_app_event
WHERE dt BETWEEN '2024-01-14' AND '2024-01-16'  -- 多取一天防止时区跨天
GROUP BY country, local_date;

关键细节：dt分区是UTC天，但local_date是当地时间天。查询时dt要多取一天，因为UTC和当地时间可能跨天。这个SQL我在出海公司用了无数次。

解决口径冲突的方法论

我在三家公司尝试过不同方法，最终总结出一套有效的流程：

步骤	做什么	关键动作
① 定义对齐	拉所有相关方开会，明确每个指标的精确定义	文档记录，参与者签字确认
② 口径分版本	允许同一维度有多个口径，但必须命名清楚	dau_product / dau_ops / dau_strict
③ 代码对应	每个口径有且只有一个SQL/代码实现	一个口径=一条SQL，不允许两个地方算同一指标
④ 元数据注册	口径定义录入元数据管理系统	指标名+定义+负责人+SQL+更新频率
⑤ 定期审计	每季度review一次口径，废弃不用的	Owner负责制，无人认领的指标下线

指标元数据管理实战

当指标多到一定程度，光靠文档和会议是管不住的。我在出海硬件品牌后期引入了指标元数据管理——虽然没用成熟的产品（公司不愿意买），但用Hive表+简单的Web页面实现了最核心的功能：

-- 指标元数据管理表
CREATE TABLE dim_metric_registry (
  metric_id       STRING COMMENT '指标唯一ID',
  metric_name     STRING COMMENT '指标英文名，如dau_product',
  metric_cn_name  STRING COMMENT '指标中文名，如DAU(产品口径)',
  definition      STRING COMMENT '精确定义',
  sql_logic       STRING COMMENT '对应的SQL逻辑',
  data_source     STRING COMMENT '来源表：dwd_app_event',
  owner           STRING COMMENT '负责人',
  department      STRING COMMENT '归属部门：产品/运营/数据',
  status          STRING COMMENT 'active/deprecated/draft',
  created_at      TIMESTAMP,
  updated_at      TIMESTAMP
) COMMENT '指标口径注册表';
 
-- 原则：有争议时看这张表，以注册信息为准

面试高频追问

追问一：如果产品经理坚持用他的口径，运营也坚持用她的口径，你怎么办？

不要试图强行统一——这不是数据组的活，而且强行统一容易得罪人。正确做法是：两个口径都保留，但必须明确命名。比如dau_product和dau_ops是两个不同的指标，在报表上分别展示，标注口径来源。如果CEO要看公司整体DAU，由数据组和业务方一起确定一个官方口径，所有对外报告统一用这个。内部各团队可以继续用自己的口径做分析，但不用来对外汇报。

追问二：指标口径变了，历史数据要不要重算？

这取决于口径变化的影响范围。如果是小调整（比如把「打开App」改成「打开App且停留>3秒」），影响在5%以内，一般不重算，但在变更记录里标注「从X日起口径调整」。如果是大调整（比如从设备去重改成账号去重），影响超过10%，就必须重算历史数据，否则同比环比都不可比了。重算前先和业务方确认回溯时间范围，一般回溯6-12个月就够了。

追问三：你们用什么工具做指标管理？

业界常见的方案有：Apache Atlas做元数据管理，但比较重；DataHub（LinkedIn开源）做指标注册；还有商业产品如数据力。我们公司规模不大，用的是Hive元数据表+Notion文档+季度审计的轻量方案，够用了。工具不重要，重要的是流程——必须让每个指标有人负责、有定义、有代码对应。

实战踩坑

我在某短剧出海公司接手数据组时，发现一个典型的口径混乱问题：同一个付费率指标，报表上有三个不同的数字——产品后台是5.2%，运营日报是4.8%，老板的周报里是5.5%。

排查后发现原因：产品后台的分母是「活跃用户」（他们的口径是包含后台唤醒），运营日报的分母是「有交互行为的用户」，老板周报的分母是「新增用户」——三个人算的都对，但分母不一样。

解决方案：我花了一周时间，把公司所有核心指标（30+个）的口径全部梳理清楚，录入元数据表，和每个部门的负责人确认。然后在周会上做了一次统一宣讲，把官方口径和各部门口径的区别说清楚。从那以后口径冲突减少了90%。

教训：口径问题不会自己解决，必须有人主动推动。数据组是最适合做这件事的团队，因为你最懂数据流向和计算逻辑。早点做、主动做，比等问题爆发再被动处理要好得多。

总结

活跃用户的口径没有标准答案，关键是定义清楚、命名清楚、管理清楚。解决口径冲突的方法论是：定义对齐→口径分版本→代码对应→元数据注册→定期审计。面试时能讲出「我们遇到过口径冲突，我是怎么推动解决的」，面试官会觉得你不只是一个写SQL的，更是一个能推动团队改进的人。

下一篇聊一个技术含量更高的问题：用户ID不统一，手机号/设备号/账号怎么打通？ID Mapping实战。

你们公司的DAU口径统一吗？有没有遇到过口径打架的情况？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长

用户画像面试通关手册

第6-10篇：ID打通、调度保障与架构设计

Wood聊大数据

9年大数据老兵，聊技术、聊职场、聊成长