同样叫"活跃用户"，运营/产品/数据各说各的——指标口径冲突怎么对齐？

-- 4个部门的DAU SQL（口径全部不同）
 
-- 增长部：当日启动APP的设备数
SELECT COUNT(DISTINCT device_id) FROM ods_app_launch WHERE dt='${dt}';
 
-- 产品部：当日有页面访问的UID（必须登录态）
SELECT COUNT(DISTINCT user_id) FROM ods_page_view
WHERE dt='${dt}' AND user_id IS NOT NULL;
 
-- 商业化：当日有广告曝光的UID
SELECT COUNT(DISTINCT user_id) FROM ods_ad_impression WHERE dt='${dt}';
 
-- CEO周报：当日登录成功的UID
SELECT COUNT(DISTINCT user_id) FROM ods_login_success WHERE dt='${dt}';

方法二：北极星指标作为统一参考

不能强行统一所有DAU，但必须确定一个对外（董事会、季度报、媒体）唯一的DAU。这个就是「北极星DAU」，由数据部Owner，全公司只此一份。

-- 北极星DAU定义：登录且有效互动
-- 必须满足：①登录成功 ②停留>30秒 ③不是测试账号
WITH valid_users AS (
  SELECT user_id
  FROM dws_user_action_1d
  WHERE dt = '${dt}'
    AND is_login = 1
    AND duration_sec > 30
    AND user_type != 'TEST'
)
SELECT '${dt}' AS dt, COUNT(DISTINCT user_id) AS dau_north_star
FROM valid_users;

北极星指标的关键属性：①只有一个 ②不可在BI里改口径 ③变更必须走变更评审会。这是一根定海神针，所有其他口径都在这个基础上派生说明差异。

方法三：口径冲突的处理流程

当业务方提出新口径需求时，按以下流程走：

[业务方提需求]
    ↓
[查指标字典：是否已存在？]
    ↓ 存在               ↓ 不存在
[直接复用]            [评估是否真的需要新口径]
                          ↓ 需要        ↓ 不需要
                      [走新增评审]    [推荐已有口径]
                          ↓
                      [3方签字：业务+产品+数据]
                          ↓
                      [入字典+定Owner+发公告]

评审会上必须问3个问题：①已有口径为什么不能用？②新口径Owner是谁？③和已有口径的diff能不能算清？算不清就不批。

方法四：字典平台的强制约束

字典不能只是一张表，必须接入BI工具，做硬约束：

# BI工具发布拦截示例
def validate_metric_publish(metric_name, formula):
    # 1. 查字典是否登记
    if metric_name not in metric_dict:
        raise ValidationError(f'{metric_name}未在指标字典登记，请先登记')
    
    # 2. 查公式是否一致
    expected = metric_dict[metric_name].formula
    if normalize(formula) != normalize(expected):
        raise ValidationError(f'{metric_name}口径与字典不符\n字典：{expected}\n你写：{formula}')
    
    # 3. 查Owner是否签字
    if not metric_dict[metric_name].owner_approved:
        raise ValidationError(f'{metric_name}尚未Owner签字，请先走评审')
    
    return True

没有这层约束，字典就是Word文档没人看。我在出海硬件品牌做的字典平台接入了Tableau和自研报表，发布拦截后口径冲突case从每月8起降到每月1起。

面试高频追问

追问一：业务方说"你们数据部凭什么定义指标？"，怎么回应？

数据部不是"定义"指标，是"维护字典"。每个指标的定义是业务+产品+数据三方共同评审的，数据部只是字典的Owner（保证唯一性、可追溯）。这个定位很关键——讲清楚之后业务方就不会觉得是被数据部强加规则。我会把这层关系写进《指标管理章程》文档发给所有Stakeholder。

追问二：跨业务线的指标怎么对齐？比如A业务线和B业务线都有「订单数」

两层处理：①顶层抽象——公司级有一个跨业务线的「订单数」总指标，由集团数据部Owner ②业务线下沉——A业务线和B业务线各自有自己的订单数（命名为order_cnt_a、order_cnt_b），允许定义不同。集团总订单≠A+B（因为有去重逻辑、跨业务订单等），这点必须在字典里写明。我在出海硬件品牌就是这么处理智能硬件和配件两条业务线的。

追问三：历史报表已经在用错口径了，怎么处理？

不能直接改，会破坏历史趋势的连续性。我的做法是：①保留旧口径报表，加deprecated标签 ②上线新口径报表（新名字+新URL）③双口径并行3个月，业务方做切换 ④3个月后下线旧口径。最忌讳直接改老报表的SQL，用户看到数突变会信任崩塌。

实战踩坑：北极星DAU改口径，CEO投诉

某次我们把北极星DAU从「登录UID」改成「登录且停留>30秒UID」，自以为改得更准了。结果发布当天CEO看周报发现DAU降了12%，直接炸了——以为业务出问题。

教训：北极星指标改口径必须做三件事：①提前2周公告 ②保留旧口径30天双跑 ③在报表里同时展示新旧两版+差异说明。后来我们做了一个"指标变更日历"，所有指标变更必须提前进入日历，CEO办公室每周review一次。

总结

面试这道题答出三层就是Senior：①承认冲突的合理性（不同场景需要不同口径）②给出共存机制（命名规范+北极星）③给出治理机制（字典+评审+平台约束）。强调"指标管理是组织协作问题不是技术问题"，这一句话让面试官刮目相看。

下一篇聊一个偏技术的话题：一个指标到底该放DWS还是ADS？派生指标和原子指标的边界怎么划？

你们公司DAU有几个口径？哪个是北极星？评论区聊聊～

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