一个数据分析报告的框架

作者：潘一鸣

一个项目到了汇总的时候，免不了形成一份相对完整的数据分析报告。

报告也需要多种情况。按照应用场合可以划分多种类型：有的需要向上邮件汇报，有的需要给项目组里一个交代，有的是需要直接进行展示汇报等。按照项目类型也可以划分多种类型：新项目上线效果评估，AB test结果，日常数据汇总，活动数据分析等。

文本也好，PPT也罢，数据分析报告核心的思路都是相通的。

1. 你要一个故事

我自己有个想法，就是产品经理应该多学习相关领域的知识，比如学一些基础的设计规范、交互原则、营销知识，心理学知识，算法知识等等。除了一些明显的对工作的帮助，也能帮助自己扩展思路。其实做好报告，就应向咨询机构或者投资机构学习。

一个报告核心不是包含很多内容，让听众或者读者去花时间理解，核心是讲好一个简单的故事。咨询和投资机构做BP之前，会先花时间理清楚storyline。其实各种报告都应该这样，先理清楚你要讲的故事。

2. 一个数据分析报告的框架

这里列出一个我个人比较喜欢的报告框架，可能针对不同的报告场景需要有所调整（比如删除部分步骤，或者增加部分细节）：

项目背景：简述项目相关背景，为什么做，目的是什么项目进度：综述项目的整体进程，以及目前的情况名词解释：关键性指标定义是什么，为什么这么定义数据获取方法：如何取样，怎么获取到的数据，会有哪些问题数据概览：重要指标的趋势，变化情况，重要拐点成因解释数据拆分：根据需要拆分不同的维度，作为细节补充结论汇总：汇总之前数据分析的主要结论，作为概览后续改进：分析目前存在的问题，并给出解决改进防范致谢附件：详细数据

项目背景 & 项目进度

项目背景，需要简述项目相关背景，为什么做，目的是什么。项目进度，需要综述项目的整体进程，以及目前的情况。这两点其实没什么可说的，如果对象是项目成员，可以写简单一些，如果对象是对项目不了解的人，则需要多写 一些，但还是要尽量用最简单的话，跟别人讲明白。

名词解释 & 数据获取方法

名词解释：关键性指标定义是什么，为什么这么定义。这点是很多人忽略的，其实很多时候数据的误解都是因为对指标没有统一的定义。举例而言，点击率可以是点击次数/浏览次数，也可以是点击人数/浏览人数。人数可能按访问去重，也可能按天去重。如果没有清晰的解释，不同人理解不同，对整个数据的可读性就大打折扣。

数据获取方法：如何取样，怎么获取到的数据，会有哪些问题。原始数据往往有一些缺憾，要经过数据清洗剔除噪声，也需要部分假设进行数据补全。数据清洗和数据补全的方法需要跟汇报对象说明并且获得认可，让对方对于置信度有一个估计。

数据概览 & 数据拆分

数据概览，需要有重要指标的趋势，变化情况，重要拐点成因解释。

数据拆分，需要根据需要拆分不同的维度，作为细节补充。

这里基本上就是之前说的数据分析方法了。如果需要对方知道对比或者趋势，则使用图，如果需要对方知道具体数据，则使用表。表格对需要强调的数字要做明显标识。需要注意的点是：核心指标要少而关键，拆分指标要有意义且详细。同时如果是PPT的话，每页说明白一个结论或者解释清楚一个趋势足以。关键性结论要用一句话能说清楚。

结论汇总 & 后续改进

结论汇总，基本是对之前数据分析阶段的数据进行汇总，形成完整的结论。

后续改进，需要在数据分析的结论和问题的基础上，对后续的迭代和改进措施作出方向性的说明。这部分其实很多时候也是分析的根本目的。

致谢 & 附件

致谢是对项目组合相关协助部门的致谢，基本上对于项目组和相关协助部门而言，也希望自己的工作或者积极配合能看到有效的数据结果。在之后的合作中，也会更加融洽。

附件是需要附赠更多没有必要在数据报告中体现但是仍然有价值的数据。对于PPT而言，这部分也可以放在PPT致谢之后，与会同事有疑问，可以随时翻到最后解释。

3. 总结

一个产品，如果你不能衡量它，你就不能了解它，自然而然，你就无法改进它。这是说数据。

而数据报告的意义也是类似，项目完成之后需要完整汇报，这样无论是对上汇报还是对团队而言，都是有重要意义。

突然想到一个事情。去年的时候做了一个内部数据平台，到了取名字的时候，我用了dice。为什么叫dice呢？

这得从物理说起（开启神棍模式）。物理学不断前行，之前人们认为物理学是决定论的，只要知道系统的初始值和足够细节，就能知道之后系统的演化路径。后来发现不是这样的，对于一个基本粒子而言，观测之前，粒子状态和位置是不可预测的。爱因斯坦说“上帝不会掷骰子”，然后后续的研究，更多的是支持上帝是掷骰子的。这也是dice的来源。

即使是上帝视角，也不可能知道提前知道数据的结果。那么作为产品经理而言，尊重数据结果，并分析形成结论，远比相信一些所谓的方法论的条条框框好得多。

关于数据，能讲的还有很多，之后再开新坑。