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