欠下的债迟早都要还。互联网快速迭代虽然能提前满足用户需求，验证业务模式，但也带来 BUG 增多，管理混乱的问题。
比如随着人员流动，没留下迭代记录。新同事提的需求却不知道离职的老同事曾经做过效果不佳，又重复做了一次，浪费资源。即使想到去查数据，每个人对埋点的命名规则都不一样，又得求研发工程师翻代码，查一次历史数据身心俱疲。
如果通过制定流程规范让大家来写文档留下记录又拖慢了开发速度，于是我在思考如何能快速留下记录，后续回顾的人也方便查看。
58UXD 出品的这篇数据分析基础也非常实用：
“凭什么说你的方案有效果？
阅读文章 >1. 可视化结构化
作为交互设计师我知道研发工程师看交互说明文档喜欢看图不喜欢看字，我自己也讨厌看长篇大论的报告。这份文档结构要清晰，最好能可视化，看起来一目了然。考虑到数据的呈现，我决定采用表格。
2. 形成习惯不费力
如果在这件事上耗费太多精力得不偿失，要形成习惯，在固定的节点花较小的代价来做这个事情。为此我根据团队的版本开发流程，决定在功能上线数据分析后撰写《上线数据分析表格》。数据分析需要查询埋点，在功能开发后期，研发工程师需要处理埋点，因此在此时记录《埋点记录表格》是最佳的。
经过一段时间的摸索，我总结出了一个管理埋点和数据的模板和方法，来和大家分享。
1. 埋点记录
在完成设计方案后填写如下表格。
修改点是设计方案，目标、预期结果来源于 Google 发明的 GSM 模型，若读者不了解可自行寻找资料学习。
我们为什么要使用 GSM 模型常规工作中，需求往往由 PM 发起，UE 团队到底如何跟 PM、FE 等团队成员协同，达成目标共识，是我们值得讨论的。
阅读文章 >搞清楚预期结果（指标）后，自然就知道需要什么数据。根据需要的数据思考需要哪些埋点，再梳理现存埋点，最后通知研发工程师新增还缺失的埋点。
在版本上线分析数据后填写如下表格。
前三列与之前表格相同，实际结果根据埋点的数据分析结论填写。为了让之后来回顾的同事一目了然，建议用绿色表示结果符合预期，红色表示不符合，黄色表示待观察。如果上线之后有遗留问题需要后续优化或者有下一步计划，可填写在后两列中。
或许有同事看完表格后想深究，我们可以把具体详细的数据列在上线表格下方。最后补充版本号和上线日期就得到一份完整的埋点和数据文档，如下图所示。
建议把文档命名成“版本号+上线日期”，便于识别。
制作为模板后，每个版本花半天时间就能完成分析记录。清晰简明的文档让后续回顾某个版本的修改点和数据变得简单。
需要模板可点击如下链接获取： https://fd0bvliidp.feishu.cn/docs/doccn52pJfYmUxrl4eIiqyF4mYf
欢迎关注作者的微信公众号：「龙爪槐守望者」
本篇来源：优设网
原文地址：https://www.uisdc.com/burial-point-and-data
广告
