越来越觉得“数据日报”应该是每个产品必备的“衍生产品”了，每一位产品经理，都应该清楚的了解怎么设计数据日报。
第一次认识“数据日报”，是在去哪儿就职的时候，当时花了很长时间，也花了很多精力去研究，这也成为我最在意的“衍生产品”之一。
什么是数据日报呢？
电影里，总有那么一些神奇的人，每天早上都会有一段惬意的时间，喝早茶，看日报。如果这份日报里的内容全部都是数据，那些就算是一份“数据日报”了。
最初，数据日报是比较忌讳的产物，不是指定的角色，是没有查看权限的，并且也绝对禁止外传，因为我们很容易通过数据去观察企业运作状态以及规律。
这会有一个前提，日报里的数据要有意义。
数据日报的意义
我们会认为数据日报是一种过时的产物，毕竟现在有那么多更全面，更丰富的第三方数据统计平台，我也是非常依赖第三方统计，在我认识“数据日报”之前。
与第三方统计平台相比，数据日报会有几个让人着迷的好处。
他总是比统计平台，更懂你
主动和被动，是一个持久话题。一个产品在设计的过程中，我们其实一直在平衡主动与被动的关系。
对于统计平台而言，需要用户产生主动查找内容的行为，数据日报则是系统主动推送内容，用户变成了被动接受。
我应该算喜欢“懒惰”的那部分人，这也是我依赖数据日报的原因。
在我有所行动之前，特定的内容应该已经放到了我的邮箱里，就像电影里的人们，每天看看早报一样，总是在你想要看的时候，就已经被放在邮筒里了。
认识的一位朋友告诉我，他在每个周一早上都会去数据中心看看数据，这已经成了他的习惯了，这让我感到好奇，偶然的情况下，我体验了他们的数据中心。
坦白说，这并不是一次很好的体验，我能想象，每周一他是在多么排斥的情况下，不得不去数据中心查看数据。
太复杂了！
显然，他这时需要看的是“数据日报”。作为一个分公司的实际负责人，其实只需要关注部分典型数据就可以了，更多的细节数据，只会成为干扰和负担。
你无法通过三方平台或者数据中心，实现多个产品线的数据查阅，不是因为功能不支持，是因为我们对信息的过滤及处理能力有限，所以我们要依赖团队合作。
这就是数据日报存在的意义了。
1.主动将信息送达给我们，通过邮件，或者其他手段;
2.过滤后的信息，能让这件复杂的事情变得简单，尤其是多产品线的环境里;
3.自定义的重点突出，会让我们知道发生了什么事情，直接影响了数据;
福利
这个是某上司公司的部分日报内容，当然信息部分已经被处理了。
“生产”与“用户模型”
数据日报作为产品的“衍生产物”，其本身也应该作为一款独立的“产品”被对待。
当我向朋友提出建议时，他也说出了他的顾忌，我相信这并不是他一个人的顾忌。
- 现在核心数据的规则并不清晰，变动可能性会很大;
- 只是内部机制，不要去占用宝贵的研发资源;
- 他并不认为数据日报和他现在的行为有什么“区别”;
这是一种惯性思维，是我们互联网人特有的一种思维模式：“只有研发能够扮演生产者的角色”。
实际上，数据日报更多的是产品经理或者运营来生产的，整个日报的制作过程中，需要由研发协助完成，每日固定时间导出上一日数据的脚本，且是原始数据。
其实我更喜欢将数据日报交给产品经理完成，毕竟其本身也是一款“产品”。
换言之，我们可以在数据日报里，很好的锻炼自己的产品能力。比如我们常提到的“用户需求模型”。
数据日报会有两类用户，其一是生产者，其二是阅读者。
这就像产品的后台与前端一样。
生产者是指每天来制作数据日报的角色，有很长一段时间，我们的前台行政扮演了这个角色，每天会发一份数据日报给公司所有人，这会花费她10分钟的时间。
数据日报作为产品被生产出来以后，必须考虑到生产者的“易用性”，如果他过于复杂，成为了团队的负担，这样就很难被有效的使用了。
阅读者是指每天查看这份数据日报的人，可能是Boss，可能是管理，也可能是我们全体成员，这就要求我们在表达层面留意“信息层级”“阅读体验”“可扩张性”。
数据日报的设计思路
我们已经做了一个简单的用户模型，接下来就可以将他产品化了。
这个是我自己使用的一套产品结构。
对于生产者而言，我们希望他的操作尽可能简单，最好是让不会用excel的同事，都能够快速的进行操作。
我们设计了三个Excel表，并且尽量不去有任何的“修改”动作，一切依托公式，函数来自动运算完成。
原始数据：
这是我们每天从数据库中导出的数据，如果有多张表，就会存在多张原始数据表，但他们本质是一样的。
对于原始数据，我不建议在上面做任何的修改，包括公式和函数的运用，最好只是复制就可以了。
过渡数据：
这是我们的计算中心，大部分的公式、函数、都在这个表里进行计算。
这个表会有多张sheet ，一部分是用于粘贴指定的原始数据，一部分则是输出运算结果。
结果数据：
这是我们的输出数据，基本上阅读者看到的数据是从这个表里产生的，我们可以在这个表里做一些图形化的处理。
整个设计思路很大程度是围绕”生产者”展开，只有足够简单，我们才能实现低成本的生产，也是高效的。
在这套设计思路里，“生产者”的动作只有“复制”与“粘贴”
案例：
按照这个思路，我们来计算一下昨天的日活数据。
1.导出昨日的“登录记录”表，作为我们的原始数据，这张表会记录用户昨日所有的登录时间（会出现重复记录，一个用户登录了多次），
2.将“用户ID”复制并粘贴到过渡数据指定的列“昨日登录用户ID”，得到“昨日登录的用户数”（公式自动计算出的结果：统计某一列不重复的数据）。
3.将“昨日登录的用户数”复制粘贴到“结果数据表”，得到日活的折线图（自动生成固定周期的折线图）。
4.最后，只要将“结果数据表”里的内容，复制到邮件或者截图到邮件里，就可以发送给所有人了。
文末
如果你目前在初创团队任职，我建议尽早尝试接触数据日报，这会让你更了解数据，对团队而言，这也是我们所能产出的一个比较重要的贡献。
要知道产品初创阶段，对于数据非常的依赖，但往往我们只是知道数据很重要，真的要去说出需要哪些数据，往往就不得而知了。
即使你在一个成熟的团队，我也仍然建议你去研究一下，不论是数据中心或者是三方平台所能提供给我们的数据都是固化的，缺少灵活性以及特定性。
相信这个技能，会在未来给你很大的帮助。
#专栏作家#
枯叶，微信公众号，枯叶咖啡馆，人人都是产品经理专栏作家。擅长社交，社区，细分群体挖掘。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
给作者打赏，鼓励TA抓紧创作！ 赞赏 2人打赏
