报表开发(补充篇)-技术圈

报表的作用

监控业务，构建数据参考基线，数据要回答的两个问题是是多少？好不好？，通过数据指标来衡量后就能知道目前业务表现如何？是否健康？和同行比是什么水平？
数据反馈，为了扩大盘子、降本增效，技术、产品、运营等，投了很多人力物力做了很多事情，做完之后效果怎样？用户有没有增长？销售有没有增长？性价比如何？
异动诊查，突然某天销售或其他关键指标往下掉？是哪里出现了波动(空间和时间定位)？更进一步，就是将异常和业务内部的操作关联起来，看是否最近是搞了什么操作导致了指标波动；
数据预测，“接下来会怎样？”功能比较好的BI软件，可以根据历史指标趋势做出预测，数据的基线除了可以参考历史已发生的数值，还可以参考预测值；
从数据分析产品化的角度去理解，报表是固化高频数据需求的主要输出物，每天自动跑数的报表能极大减少数据分析师劳动量；

报表的核心要素

趋势，长期发展趋势(trend)，短期波动、达标进展；
变化：

关键指标的波动，波动值多少？主要发生了什么环节？什么原因导致？原因是否可控可操作？
主要业务对象的状态变化，e.g. 用户是否进入生命周期的下一步还是发生了流失，外部渠道的引流质量或者成本是否稳定？
操作事件，短期关注的目标(第1点中的关键指标相当于长期关注的指标)是啥？业务上有什么动作？这些动作对业务的短期和长期影响如何？

细分：

横向(人、货、场)，纵向业务转化环节(产品漏斗或时间周期)；
细分的核心目的是在于找到薄弱的环节，e.g. 转化漏斗中流失率大的环节，或者细分组群中“拖后退”的那部分；

对比

对比的核心目的在于确定差异、变化或优劣，e.g. 如果你要说这个月的业绩表现优秀，那么潜台词就是这个月和某个月比表现是好的，从数据角度来讲，你可以说这个月的订单额相对于去年同期比上涨了20%；
可以是横向的组间对比，也可以在时间维度上对比；
指标是可比的；

指标体系构建的出发点

首先，关注整体概况，也就是看大盘，从业务关键指标(e.g.KPI)出发，再拓展到指标的变化趋势、是否达标、细分情况，从一个指标变成一套指标体系的核心是“拆解”，比如可以按照指标计算公式、业务转化环节、人货场细分等；

其次，关注“事件”，事件可以分为两类：

产品->用户,比如产品运营面向用户搞的那些操作、运营活动、ABT什么的，对这些操作归个类，再看每类别下具体有哪些操作活动，哪些是“活的”(正在进行中)，哪些是“死的”(已经结束)，效果如何？
用户->产品，用户主动和产品交互的行为，e.g.浏览、播放、付费等，除了正常行为，也要关注异常行为(参考产品中的异常行为)，e.g.行为中断、用户流失、异常流量等。

最后，就是看“专项”，比如关注人货场中的某个主体或者某个主题。拿用户举例，可以考察用户规模(存量多少，进量多少，出量多少)以及来源渠道，可以考察用户生命周期的转化进展(e.g.参考AARRR)，还可以考察单客或细分客群的获客成本、生命周期价值等；

产品处于不同生命周期阶段关注的指标或者业务优先级不一样，所以有的指标虽然在报表中体现，但是优先级并不是那么高，此时可能更应该关注在长期目标下拆分出来的短期的目标及相对应的数据需求。

指标的衍生

目前可以考虑两种思路：

1.自上而下拆解

可以从业务环节入手，看不同的产品角色是如何在产品中一步一步往下走的，从用户视角出发，绘制用户地图，每一步走一下看看哪些关键行为节点，也可以从内部视角出发，看我们对于用户在产品上有哪些期待的行为或产出；
可以按照指标公式拆解，参考杜邦公式类似的思路，将指标一层一层细化；
时间、空间两个维度下都可以拆分；

2.自下而上组合

指标可以分为“维度”和“度量”两部分，度量是没有“修饰词”的数量、金额、长度等，加上场景等修饰词就是业务上的指标。

笔者参考“人货场”模型，将业务上的维度分为如下5种。

指标拆解的操作详情可以参考前文报表开发(指标篇)

报表开发容易遇到的坑

伪报表需求

报表开发是为了解决高频看数据的需求的，一般不要把一次性或者偶发性的数据需求做成报表，花了很多时间做出来可能很少用到；

谈报表需求的时候还是要先沟通清楚需求方的意图，具体可参考报表开发(需求篇)以及如何提升工作效率

指标口径不统一

不同的人做不同的报表，但是指标有交叉的时候，很容易遇到业务方拿某个数据问你为啥和另一个报表的数据对不上这样的情况。

报表的口径要统一，最好整理个指标白皮书，放到wiki这样分析师和业务方都可以看到且能随时编辑和及时更新的地方(遇到关键指标的计算逻辑改动，最好邮件知会相关人员)，写清楚指标的名称，具体的计算口径(包括业务上的口径描述以及业务背景)，以及技术上用的是什么源表的什么字段，也可以附上sql代码什么的。

报表冗余

这也是很常见的问题，多个报表出现了较大的overlap，但是每个报表的信息又不完整，一方面业务方看数据很累，另一方面，数据分析师维护报表的工作量也不小。

建议：

将一些在报表或者分析中高频用到的指标按用户或天这样的颗粒度建成中间表，后面要分析或者出报表的时候，就可以快速通过少数几张表输出数据，中间表最好能每天自动更新；
做好业务指标的主题规划，把不同的业务方关注的指标归类，然后组织成不同的指标体系，尽量在一张报表(或者一个页面)中呈现出来，这也是搞数据指标“体系”的原因。

报表的维护

报表的维护可以分为增、删、改3种情况。

“删”报表比较简单，如果是业务变动或者被其他报表替代等原因，报表下线就行，用不上的数据任务都要停掉，另一方面要做好对报表的生命周期管理。

报表的“增”和“改”就是要在原有报表基础上添加或者删除一些指标，或者调整指标的计算口径，改动的前提是要熟悉报表中的数据计算过程。

假设现在有一个用Excel做出来的报表，用了大量公式加上还有逻辑复杂的VBA，这样很难直观看到从最初的数据输入到最后的指标输出之间的计算过程，更不要说一步一步复原出来，类似这种“可逆向性”很差的工作后期维护就相当坑。

所以报表好维护的前提，首先是让没做这个报表的人也能轻易上手，从头到尾把数据流程跑通，提供必要的代码和文档说明，其次工具的选择也很重要，比如你很非主流，用Java把报表搞了出来，但是数据分析组的其他同事并不熟悉Java，这就是坑队友的行为，工具的选择首先要保证团队协作的便利，其次是维护性和易用性等方面的考量。