夜雨聆风
上篇我们聊了如何在 PRD 中写埋点需求——简单场景写在 PRD 里就够了。
但当你面对多端产品、跨团队协作、需要长期维护的数据资产时，一份独立的数据需求文档（DRD）就必不可少。
这篇文章把 DRD 拆开讲清楚：它是什么、包含哪几部分、每一部分怎么写、以及最常见的坑在哪里。
DRD 全称 Data Requirement Document，是一个独立的、可追加的全局维表。
它不是 PRD 里一个叫"数据埋点"的章节，而是一份独立的文档。不同公司有不同叫法——外企和大厂常叫 DRD，有的团队叫"埋点文档"或"事件追踪方案"，但本质都一样：定义数据怎么被记录。
什么时候需要写独立的 DRD？四个判断维度：
记录每一次改动：版本号、变更日期、修订人、涉及模块、变更类型、详细说明。
为什么重要？数据团队排查历史异常时，能追溯到每一次变更的版本、时间和原因。建议每次发版前更新，不要事后补录。
变更类型分三种：
新增 配合新功能新上线的点
修改 原有埋点因业务变化，需追加参数
下线 页面下线或坑位移除，清理冗余，停止上报
如果每个事件都单独写一遍 user_id、设备信息、app_version，不仅重复劳动，还容易写错。在公共属性里统一定义一次，所有事件自动继承。
常用公共属性包括：
这是 DRD 绝对的核心。研发和测试不可能每次发版都核对几百个埋点，只看这张表，就能秒懂这次迭代要写什么代码、测什么流。
完整的事件表包含 7 列：
以电商购买全链路为例：
以商品详情页「点击立即购买」为例，拆成三步：
用户点击了"立即购买"按钮。
detailpage_buy_click。全小写，下划线分隔，团队统一风格即可。
选属性的原则：每个属性都应回答一个业务问题。
product_id→ 用户对哪个商品感兴趣 → 支撑商品热度分析
sku_id→ 用户选了哪个规格 → 支撑规格偏好和库存策略
关注公众号回复 资料，即可获取整理好的埋点文档模板，还有常用的文档合集。
下篇预告：埋点上线后，产品经理怎么验收？
你在写 DRD 时踩过什么坑？评论区聊聊
如果觉得有用，点赞 / 在看 / 转发，一起持续进化