干货分享 - 作为 Lead 接手一个新的数据团队一 问题盘点 与 Insights 的发现

这个纪要是我从自己的工作日志中逐步的整理出来的，记录了在 2015 年时接手一个数据团队时的工作内容。

当时受命接手一个新的数据团队需要在前一个 Q 要做哪些工作，这个 Q 中拆分开该如何去做？

我会把当时工作日志中的内容整理出来并通过公众号发出来。这一篇包含三部分内容， 一个工作任务的盘点、盘点问题后的一些 insights 的发现，接下来行动 action；

Stage One 问题汇总：

1. 业务口径变化非常频繁，每个季度会调整与变化，需要重新写一遍 metric 逻辑，相关的数据统计，报表都需要重新部署，每次重新部署的工作量越来越大（需要拆解的维度越来越细）。周期性周报日报，异常波动分析，主要跟 apps OKR（分发量）有关；这部分基本每周都有涉及。Muce Report ①固化，对于日常需求频繁，且 metric 逻辑变动较小的数据，固化到 muce ①（如应用升级、分类页分发量及 CTR）。

2. 临时性 assign 的 task，属于专题分析，通常跟核心 metric 波动有关，从常规的监测日报周报也不能直接发现原因，常需投入 2-3 天甚至更长（比如春节后 DLU 的下跌、apps 人均消费的渗透）。

3. 目前数据预警的周期相对较短，日、周，日常工作中对于 metres 的异常分析会占用大部分的工作时间，专项分析的时间会相对较少,有高价值的业务产出不多。

4. 紧跟版本（每两周一版）和 feature，埋点、log 测试、feature 效果评估、提出产品和运营建议（比如前两 Q 投入时间最多的是应用升级、详情页相关推荐、分类改版）。新 feature 通常没有 log（区别于 SP 策略评估直接切流量看 policy ID 即可），以上流程得从头到尾跟进。

5. 目前除了对接产品，也常对接运营，比如 apps 用户的生命周期（对接 push 运营），临时需求杂多。

6. 宏观数据预测分析和研究，重要但不紧急。

7. 基础数据底层的维护，工作量不大，一周 1~2 次集中参与解决。

8. 在 Muce2 ①实施了很多算法，ETL 过程，需要往 muce3 迁移。工作量大，没时间来搞这块

9. startpage 的数据周期性的异动分析（主要是周报和数据波动较大的时间）.想办法通过数据的方法如定投来驱动数据增长. 新特性发布后效果分析与运营建议

10. 各种临时需求覆盖了绝大部分工作时间，投入到深入的专题分析的时间受到限制。

11. 由于目前接手的 2 个项目，不定时的临时需求会 double，这些需求紧急性不好评估，会打乱原有的工作计划；

12. Buffet 平台维护，用户反馈收集和使用问题的解决。但没有人力可以支援项目的优化，心有余而力不足。

13. 业务分析，无固定对接对象，一般会视业务紧急程度做分析立项和报告的输出。这一部分人力投入相对可控。

14. 数据组织和梳理。一般服务对象为 ripple，用研，mkt 等。主要是他们对解决底层数据不了解，不懂如何获取数据。一般是针对他们的具体问题进行辅助和指导。这部分工作内容的特定是：需求零散，数量较多，但单个需求并不十分耗时的。

15. muce3 ①替换 muce2 ①貌似会对已经建立的中间表或结果表以及 muce ①报表有较大影响，很可能之前建立的都不可用了.

16. 和业务方合作数据驱动产品或运营的案例较少，更多是数据评估产品改动或特性, 起到的价值不大.

17. 目前支持较少，主要是 push 测试定投用户包提取和效果评估.

18. 业务变化快，必然导致看数据就着急；有时业务的决策等不及数据结果；在小流量测试中分析的数据有问题，要求快速改进；在产品改进时都是与分析师一起来讨论想看的指标，统计口径与 定义埋点，工程实施后看一下；业务上看数据还是散落在四处，没法统一起去看

19. CLM 应该是一个长期项目，短期来看不见能有很大产出，做的越久产出越大，不同数据经验人来做产出也不同；现有的业务口径上处在不统一的问题，weekly 经常碰到口径不一致；没有一个全流量图，可查询部分；目前在各个 PM 那边想要获取到的数据可能都存在，只是没有组织在一起；日报的数据来源有时根本找不到

20. 数据同学 近 2 个月工作内容，结论如下：

21. 临时需求过多，容易产生二次需求，三次需求；占用大量时间，减少了数据分析、专题分析的时间；造成直接有价值的产出少；

22. 数据分析师当前临时需求快到到团队极限，同时还面临很多底层建设、口径梳理等；

23. 临时需求能否分流到产品、运营？提供什么样的工具合适？

24. APP 主要新版涉及到的页面改动比较多，影响范围较大，对应的 Log 也需跟着调整，这部分是不是可以由负责日志管理的技术来统一下？

Stage Two Insights：

1. 业务每个 Q 都有变化，涉及口径业务等变化迅速，每次重新部署的工作量越来越大，临时需求较多，没有太多时间投入到更有价值的数据分析，；每个分析师每月需求量有极限；在建设中面临大量的中低层建设开发；没有一点时间搞其他的；变成了人肉取数机

2. 无从知晓数据分析师对业务的掌握度；通常跟核心 Mertics 波动有关，从日常监控日报、周报中无法直接发现原因，需要投入 2-3 天甚至更长时间做分析，已经变为专题分析；

3. 版本升级和 featur，需要花费很多精力跟进埋点、log 测试、feature 评估，新的 feature 通常没有 log；需要从头到尾的跟进；没有统一的路径管理；

4. 如果 muce2 切换 muce3 影响甚大，目前不知道 Muce3 的数据准确性，可用数据 Muce3 覆盖 muce2 百分比；在 muce2 实施日常报表预计在 150+（apps pa）分析师落地的加工逻辑约在 500+条，CLM 使用的加工宽表；往 Muce3 转成本较大；

5. Buffet 平台新增需求与维护，因为没有数据开发、后台、前台的支持项目优化，心有余力不足；

6 . CLM 的应用前景，流失挽救策略；数据的产出直接作用到业务线；

7. 业务线在使用数据效率不高，靠产品、运营人肉来扛；在现阶段公司状况下，如何做到小投入大产出，通过杠杆撬动业务；如何协助开拓新业务；

Stage Three To Do List：

1. 面向培训：面向 Apps PA（未来公司）的产品、运营、工程 ，引导大家对数据认知；与业务经典结合案例（如何寻找大盘波动的秘密，如何探索 Mertics 的趋势），数据分析方法、工具的使用、数据源的获取、数据获取的流程；

--面向分析师自我学习：每个人每 Q 要做 2 场以上业务分享，业务数据探索与发现分享；

--提高分析师在专题分析上产出质量；想办法分流临时需求的同时增加专题分析时间，协助分析质量，分析角度的把握；

2. 完善数据监控体系、数据分析体系工具，包含分析流程；

--新增日志打印等流程与分析规范化上；

--落地一些业务、数据分析方法加功能上整合的一些数据产品（sample 引入 olap，引入路径，漏斗分析方法论等），提高产品、运营、工程的生产效率；

3. CLM 在运营上的方法论，探索到很好的落地点；

4. -- 围绕 Apps PA 的核心指标从数据运营角度探索一些落地模式；

4.临时需求分流：

--培养新人，进入实习生感兴趣的可以培养数据分析能力，简单分流部分简单需求

备注

①（Muce 2、 MUCE 3（13 年~16 年） 公司日志数据分析平台，也承担数据仓库的角色）

② 图片是我家的猫

松子（李博源），BI& 数据产品领域老司机一枚，漂过几个大厂。 个人公众号： 松子聊数据