产品与运营
├── 产品线
│ ├── C 端产品经理
│ ├── B 端产品经理
│ └── 数据产品经理 ← 本篇
└── 运营线（用户／内容／活动／商业化运营）
定位一句话：数据产品经理交付的不是"功能"，而是"看得清"——让企业里的决策者与新员工都能拿到口径一致、可信、能直接用来说事情的数据与工具。
它为什么属于"产品线"而不是纯数据岗：因为它同样在做取舍——做哪些指标、给谁看、什么时候看、看完做什么动作。数据本身不会创造价值，被使用才会，这正是产品视角存在的理由。
一句话定义：数据产品经理负责数据类产品与数据能力的规划与落地，包括指标体系与数据口径的定义、报表与看板与自助分析工具的设计、埋点与数据采集需求的管理、数据质量与权限规则的制定，以及推动数据在业务决策中的实际使用。
职责边界（五类日常）
一、指标体系与口径定义
与业务方共同定义核心指标的计算方式、统计范围与责任方，处理同一指标多套算法的历史遗留问题。
- 先解决"谁说了算"：同一指标出现多个版本时，要指定唯一权威来源与责任人，否则后面所有工具都会继承这种混乱。
- 写进指标字典：名称、口径、计算逻辑、维度、责任人、更新时间。字典的价值在于新人和新系统不必再问一遍。
- 建立变更流程：口径改动要通知使用方并留记录，否则会出现"上个月的数和这个月对不上"的投诉。
二、报表与看板设计
设计分析场景与信息层级，明确"谁在什么时机看什么数、看完要做什么动作"。
- 以决策场景为入口：晨会看什么、月度复盘看什么、异常时看什么，决定了看板怎么分层。
- 控制数量：报表膨胀的根源是"来了需求就做一张"。每新增一张，都应能回答它替代了哪些临时取数。
- 看板是产品不是文物：长期无人访问的要归档，否则口径会越积越旧。
三、数据采集需求
规划埋点与日志方案，明确事件定义与字段规范，参与验收以保证数据可分析。
- 埋点的常见坑：事件命名随意（同一个动作三种叫法）、缺少唯一标识（无法串联用户行为）、只埋点击不埋曝光（无法算转化率）、埋点变更没有版本导致历史数据断裂。
- 一次定义、一次验收：埋点方案要与研发一起评审，并在测试环境验证数据是否真的上报、字段是否为空。
- 宁可少而规范：埋点过多会拖慢产品并增加维护成本。
四、数据工具与平台
参与自助查询、指标平台、标签体系或数据应用的功能设计，降低业务方取数门槛。
- 把重复需求产品化：同一个取数需求被提三次以上，就该做成模板或自助能力。
- 标签体系要管生命周期：标签会老旧失效，需要明确更新与下线机制。
- 与治理侧共用一份白名单：指标与标签的定义不应在两个团队各有版本。
百科资料数据截止：2008-12