当前位置：网站首页>干货分享-作为Lead 接手一个新的数据团队一问题盘点与Insights的发现

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

2022-07-22 09:54:00 【InfoQ】

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

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

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

Stage One 问题汇总：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Stage Two Insights：

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

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

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

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

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

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

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

Stage Three To Do List：

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

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

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

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

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

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

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

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

4.临时需求分流：

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

备注

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

② 图片是我家的猫

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

版权声明
本文为[InfoQ]所创，转载请带上原文链接，感谢
https://xie.infoq.cn/article/6858b49b2a8ce135a27e7fc00

边栏推荐

猜你喜欢

随机推荐