数据埋点治理与数据质量体系
数据埋点治理是利多星数据产品体系中的基础设施项目。它覆盖 APP、小程序、PC 和 H5 页面行为数据，目标是让埋点从“能查到数据”升级为 可信、可验收、可进入 BI、可支撑用户分析 的数据资产。
3 端覆盖APP、小程序、PC / H5 行为数据
5 阶段 SOP盘点、标准、检查、修复、上线监控
7 个事件完成 14 天全量事件专项验数分析
A/B/C/D 分级建立埋点质量准入标准
项目背景
金融产品的用户行为数据分布在 APP、小程序、PC 和 H5 页面中。业务需要分析 VIP 页面点击、系统通知栏、案例股详情页、策略组合、直播、课程、栏目浏览等行为。
但埋点数据一旦字段不稳，就会直接影响后续分析：
- 用户点击了哪里，但页面 URL 没洗出来。
- 同一个模块有多个编码，口径无法合并。
- 关键字段未上报，无法判断用户行为归属。
- APP、小程序、PC 端字段不一致，三端不可比。
- 埋点用户 ID 与订单客户 ID 无法稳定关联。
- 原始表和宽表清洗逻辑不一致，导致看板结果不同。
因此，这个项目的重点是建立 埋点资产盘点、质量验收、问题修复和宽表治理 的完整机制。
项目目标
- 建立跨产品、跨端口的统一埋点管理和验收流程。
- 对核心事件进行全量验数，识别字段缺失、ID 差异、URL 清洗、模块编码等问题。
- 建立 A/B/C/D 埋点质量分级，明确哪些数据能进入正式 BI。
- 输出宽表清洗规则，让原始行为数据能被后续 BI、标签和客户分析复用。
- 将埋点治理从临时排查转成长期可执行的数据质量体系。
我的角色
我负责埋点治理的方法论梳理、验收 SOP 设计、字段质量分析、问题清单整理和数仓协同。这个项目需要同时懂业务页面、埋点事件、SQL 验数、宽表清洗和 BI 使用场景。
| 工作方向 | 我承担的工作 |
|---|---|
| 资产盘点 | 梳理核心产品、核心事件、所属模块、端口、触发条件和关键属性 |
| 验收标准 | 设计 A/B/C/D 质量分级，明确属性完整率、空值率、趋势稳定性等标准 |
| 全量验数 | 对重点事件做 7 天 / 14 天全量 SQL 分析和 HTML 报告 |
| 问题定位 | 识别字段未上报、URL 缺失、模块编码重复、ID 映射差异等问题 |
| 宽表治理 | 输出神策宽表清洗规则、short_user_code 补全、H5 URL 字段清洗和页面类型识别 |
| 协同推进 | 将问题反馈给产品、开发、数仓和业务方，推动修复和重新验数 |
埋点验收 SOP
我将埋点验收拆成 5 个阶段：
| 阶段 | 核心动作 | 产出 |
|---|---|---|
| 1. 埋点资产盘点 | 整理事件 ID、事件名、模块、端口、触发条件、关键属性和 Owner | 埋点资产清单 |
| 2. 验收标准定义 | 按 P0/P1/P2 定义准确性、完整率、趋势稳定性要求 | 量化验收标准 |
| 3. 数据质量检查 | 检查 PV/UV 趋势、字段空值率、三端一致性和漏斗逻辑 | 数据质量报告 |
| 4. 问题分类修复 | 区分埋点未报、字段错误、清洗缺失、业务口径不明等问题 | 问题清单与修复计划 |
| 5. 看板上线监控 | 只有达到准入标准的事件进入 BI，并持续监控波动 | 质量看板和复盘机制 |
质量分级
为了让业务明确哪些埋点可用，我设计了 A/B/C/D 分级：
| 等级 | 判断标准 | BI 使用方式 |
|---|---|---|
| A - 可用 | 三端一致性高，关键属性完整，趋势稳定 | 可进入正式 BI |
| B - 谨慎 | 有小问题但趋势清晰 | 可做趋势分析，不做精确结论 |
| C - 排查 | 字段缺失或波动明显 | 只用于问题排查 |
| D - 不用 | 关键字段严重缺失或数据不稳定 | 不进入 BI |
这个分级的价值，是让“数据能不能用”变成可讨论、可验收的标准，减少感觉判断。
专项验数
项目中对 14 天全量数据做了多个事件专项分析，覆盖系统通知栏、案例股详情页、VIP 策略组合、尊享直播汇、精彩推荐、精品课程、栏目浏览等场景。
| 验数对象 | 分析重点 | 发现的问题 / 价值 |
|---|---|---|
| 系统通知栏点击 | PV、UV、消息类型、落地页 URL | 将通知用户与 H5 落地页访问关联起来 |
| 案例股详情页 | H5 访问、sp_id 分布、页面贡献 | 识别少数核心 ID 贡献主要流量 |
| VIP 策略组合 | 策略组合点击、用户权限分布 | 判断核心付费用户行为 |
| 尊享直播汇 | 直播间点击、周末回放行为 | 发现同名直播间多 ID 和回放流量问题 |
| 精品课程 | 点击、课程 ID、父模块探索率 | 发现部分字段未上报问题 |
| 栏目浏览 | column_code、column_sort | 发现字段空值和双编码问题 |
这些分析用于验证每个事件是否具备进入正式看板的条件，重点不在单个事件的流量展示。
宽表清洗
埋点治理的另一个重点，是让原始行为数据可以被业务稳定使用。
我输出的宽表治理思路包括：
short_user_code补全逻辑：当用户短编码为空或异常时，用可映射字段补齐。- H5 URL 字段清洗：补充
page_url、url_path、url_host、referrer_title等字段。 - 页面类型识别：从 URL 中提取页面类型、策略代码、股票代码等信息。
- 原始表与宽表差异复核：避免同一事件在不同表中出现不同结果。
- 宽表 v2 建表方案：修复 v1 宽表漏洗 H5 URL 字段的问题。
数据如何驱动
埋点治理的数据链路是：
text
原始埋点
-> 字段拆解
-> 质量评分
-> 问题修复
-> 宽表清洗
-> BI / 标签 / 用户分析这个项目让后续的私享家 BI、用户标签、客户活跃分析和产品运营看板有了更可信的数据基础。
成果与价值
- 建立跨端埋点验收 SOP，将埋点工作从需求记录推进到质量管理。
- 输出 A/B/C/D 分级标准，让埋点是否可进入 BI 有明确判断依据。
- 完成重点事件的全量验数分析，沉淀 SQL、HTML 报告和问题清单。
- 发现并记录字段未上报、双编码、URL 清洗缺失、ID 体系差异等问题。
- 输出宽表 v2 清洗方案，为后续 BI 和用户标签提供稳定底表。
- 体现了 数据产品经理对“数据可信度”的把控能力。
个人能力沉淀
这个项目让我更加明确：数据产品的第一步是判断数据是否可信。只有埋点、字段、ID 和宽表稳定，业务看板、客户标签和用户分析才有意义。