要结构化而非散点化地工作。
——写在最前面
要盖城堡而不是搬砖头。
在教学服务部，我兼负责业务数据分析团队三年的时间，非常庆幸能够有这段经历，因为从个人成长方面，它锻炼了我的数据敏感度、基于数据去发现解决问题的能力，启蒙了我经营的思维；从工作方面，因为有数据这个有力的抓手，我能更顺利地推动产品需求落地，讲清产品的价值从而实现正向循环。
虽说我的主业是产品化，自己非数据科班出身，但是也在数据方向投入了一半的精力，并且负责辅导老师每月计薪工作三年之久。所以，希望能够停下来回首看看走过的路，思考如何可以在数据方面做的更好，并将这些思考记录下来让自己能温故知新并将经验分享给伙伴们。
基于以上的背景，本文会以“反思”的心态+“笔记”的形式呈现，由以下几部分组成：
- 困境及理想
- 了解业务——工作基石
- 数据字典——搭好框架
- 数据看板——清晰呈现
- 数据需求池——有序工作
- 数据分析——助力业务
1 困境及理想
数据分析团队太容易在工作中处于每天很忙但是不知道在忙些什么、甚至是被动背锅的境地了。我亲身经历过或者看到过的问题有：
- 太多任务，太少思考：日复一日地在提数、做报表，只是个”导数的“，且是非常辛苦天天埋头导数的。
- 太多重复，太少积累：代码没能形成很好的积累和复用，做了很多重复工作，非常低效。
- 太多产出，太少收益：数据给出去之后没有持续追踪如何使用、产生了什么收益。
- 太多数据，太少信息：给出了数据，但是没有说明这个数据说明了什么业务问题，没有观点。
- 太多变更：交付结果后发现导出来的数、做出来的报表并不是业务团队想要的，于是又要改需求改口径。
- 太不了解业务：做出来的数据脱离业务场景，缺失业务逻辑，没法用，没有办法和业务形成合力。
- 同一个指标，数据团队内部、数据团队与业务部门、本业务部门与其他业务部门的口径不一样，各说各话。
- 先有结果，后拿数据圆故事。
- 数据出错，对业务产生影响，好事不出名，坏事传千里。
之所以将以上现象称之为”问题“，是我心目中健康的数据分析团队不应该是这样的，它应该是：
- 对于业务负责人：能够随时告知业务负责人业务健康程度，及存在的问题、风险点。
- 对于业务团队Manager：能够告知各团队负责人要如何做才能够达标，
- 对于业务中台：能够告诉业务中台如何帮助业务团队达标。
它的价值：
- 准确描述现状：找到合适的切入点，客观准确地描述出业务现状。
- 深入寻找规律：找到深层的规律，而不是大家都知道的类似于”1+1=2“这种的common sense。
- 有效推动改进：找到影响北极星指标的关键要素、关键动作，能够对政策、流程、产品提出改进建议并正向影响业务数据。
它的团队成员：
- 成长：能够在工作中有横向的广泛拓展及纵向的深入思考，有成长。
- 成就：能够看到自己工作产出对业务带来的实际的正向贡献度，有成就感。
那么如何从现实的困境中走出来，达到理想中的状态呢？
2 了解业务——挖好地基
我面试过大几十名数据分析的候选人，非常有意思的一点是：在谈到“一个优秀数据分析师拥有的特质”的时候，绝大部分人都会提到一个词“了解业务”。那么什么叫“业务”，如何才叫“了解业务”，为什么要了解业务，怎样能够做到了解业务呢？
“业务”这个词没有明确/规范的定义，在我来看，业务就是企业的Who、Why、What和How：
- Who：企业的用户是谁？企业内部价值链由哪些角色组成？
- Why：企业给用户带来的价值是什么？整个行业是怎样的？和竞品相比的优劣势是什么？
- What：企业给用户的交付物都有哪些？
- How：企业的产品是如何生产出来的？服务是如何传递出来的？如何找到用户并与其建立信任产生关系？
“了解业务”，是指对以上问题在宏观层面有自己的认知，在微观层面知晓流程、规则。宏观层面强调的是“自己的认知”，因为这些问题都没有标准答案，每个人的理解是不一样的，所以重要的是要有过思考，而不是连想都没想过。
为什么需要了解业务呢？一方面，了解业务可以让我们更好地开展工作；另一方面，了解业务也能加强工作的成就感和价值认同。
从知乎上看到一个说法：优秀数据分析师的三板斧：
- 硬实力：工具：如Python/SQL等数据分析工具。
- 软实力：思维：数据分析思维、结构化思维、数据分析方法、沟通能力等。
- 业务经验：使数据分析软硬实力落地的催化剂。
如果脱离了业务，就相当于化学反应脱离了催化剂，那么你的软思维硬工具都是纸上谈兵，产出的分析报告很容易被业务一线diss：没有用、不需要、无法落地。
如何做到了解业务呢？
多问：
- 当接到新需求的时候，问这个需求的目的是什么？拿到数据后准备怎么用？每个数据的口径定义是什么？为什么这么定义而不是用别的口径定义？这个数据背后的业务逻辑是怎样的？业务流程是怎样的？业务流程为什么这么设计？….
- 问自己这个业务的北极星指标是什么？成功关键要素是什么？当前困难点是什么？
- 多问上下游及一线同事：你们的重点工作是什么？OKR是什么？
多做：
- 尝试自己去体验业务中的每个环节，亲身经历要比光听别人说印象深刻。
- 尝试去体验系统内的每个功能。
3 数据字典——搭好框架
我见过的几个数据分析团队中，无论是leader还是员工，都有提到过要搭建数据字典，大都认为数据字典是一个好东西，但是能够搭建成功并帮助到实际工作的却比较少。我觉得有如下几个原因：
- 数据字典的框架设计，需要有业务全局视角+结构化思维，这种人才比较少，而且一般会忙于各种项目。
- 数据字典每个模块的内容，需要与各业务团队、财务团队进行探讨达成一致，而这种偏强沟通的能力往往是数据团队所欠缺的。
- 数据字典各个指标的细节口径梳理，需要投入很多的精力，反复地推敲迭代，要有很强的毅力。
- 数据字典很难凭借一人之力搭建、持续维护，这需要团队协作、项目管理，建立完善的机制。
- 数据字典属于文火慢工，很难在短时间内产生较大收益。
不过当我们克服以上困难，成功完成数据字典的建设后，就能够尝到它的甜头：
一致：业务一线、业务中台，其他stackholders共用同一套口径，理解一致，避免自说自话。
提效：
- 中台伙伴可以通过口径及关键字，快速查询到需要的指标及其存储位置，避免重复劳动。
- 经常有人问某个指标的口径是什么，所有的指标口径在此留档，避免重复解释。
接下来聊一下如何搭建数据字典，数据字典应该包含如下内容：
| 序号 | 内容 | 说明 |
|---|---|---|
| 1 | 基本业务概念 | 原子定义/原子概念，或者是容易被混淆的概念，比如用户状态的分类、业务线的定义、订阅/直购等。 |
| 2 | 规范 | 如指标命名规范、指标口径规范。 |
| 3 | 指标清单 | 经营指标、财务指标、运营指标三者互有重叠，但是它们的交集形成了整体的业务数据指标体系。 1. 关键经营指标：Top→Down的，对企业利润的因素分解，找到与经济效益最相关的结果/过程杠杆指标。 2. 关键财务指标：财务人员关注的数据。 3. 运营指标：Bottom→Up的，将业务流程进行拆解，在运营管理过程中需要关注的细节指标。 这三类指标共同组成了业务数据指标体系。 |
| 4 | 指标属性定义 | 每个指标都有它的业务属性及技术属性： 1. 业务属性：指标分类、指标名称、指标口径、指标单位、分析维度、下级指标。 2. 技术属性：数据来源、数据更新频次 |
除了以上内容，还有一点非常关键，就是数据字典持续更新维护的SOP，因为在前面有提到过数据字典很难凭借一人之力搭建、持续维护，所以必须要有完善的机制保证其能够自迭代。SOP包含（不限于）如下几部分内容：
- 负责人：数据字典的每一部分都有一个明确的负责人，他为这一部分内容的完整性及质量负责。
- 使用：在搭建数据看板、拉报表、做分析时，在指标字典内查看自己要看的指标是否已经有相关记录：
- 如果有相关记录，且原口径符合需求，保持口径一致，避免差异；
- 如果有相关记录，但是原口径不符合需求，考虑新增口径or修改原口径；
- 新增：新增指标前，要先查看字典内已有相关记录。
- 如果有相关记录，需要考虑是否可以复用原指标。
- 如果能复用，那么不必新增指标。
- 如果不能复用，要能够说明不能复用的原因，并新增指标。
- 如果没有相关记录，那么直接新增指标。
- 需要记录清楚指标的业务属性和技术属性，并在备注栏记录上修改日志（修改人、修改时间、修改内容描述）
- 如果有相关记录，需要考虑是否可以复用原指标。
- 修改：
- 修改指标前，需要与该模块的负责人进行沟通，确认影响范围后进行修改。
- 修改后，需要记录清楚指标的业务属性和技术属性，并在备注栏记录上修改日志（修改人、修改时间、修改内容描述）
- 定期review：以双周为频次召开数据字典review会，各个模块负责人讲自己模块在上个周期内的修改点、数据字典使用过程中遇到的问题，并进行一些专题讨论。
4 数据看板——清晰呈现
搭建数据看板是数据团队最基本的工作内容之一，不过经常发生的状况是：业务团队提了非常多的需求，数据团队辛辛苦苦搭建看板，搭建完成后，没有人去看。提需人不去看的原因如下：
过度冗余：假如想看在读学员量，那么相关的数据有：当前时间点的在读学员量、在读学员量按月的变化趋势、在读学员量按日的变化趋势、不同年级的在读学员量；不同渠道的在读学员量。在读学员的状态又可以分为：在班/不在班，不在班又可以分为：在排队等待进班/不在排队。假设我们把这些数据都放到数据看板上，那么内容会非常全。但是，看的人真的有时间、有耐心看完这些信息吗？有可能只会在内心赞叹：“想得真全，等我有时间再来细看”，接下来看板链接就永远沉睡在收藏夹内了。
数据不准：在非计算错误的前提下，数据不准有两种表现形式：
- 形式1：A看板和B看板内，相同名称指标的数据不相同。
- 形式2：看板内数据的口径与需求方脑海中的理解不同，需求方拿到后认为数据不准。
呈现混乱：有些看板看起来非常混乱，让人没有看的欲望，可能有如下问题：
- 结构不合理，一个看板内放了很多报表，但是报表之间的层次、分类、顺序，没有经过仔细地设计。
- 图表类型选择不合理，都用表格会信息密度太大；都用图形又信息密度太低。
- 配色不合理：配色杂乱，看起来花里胡哨。
那么如何做出一个理想的数据看板呢？
4.1 了解本质
首先，需求评审环节非常关键。需求评审的目的是了解需求的本质：业务方是谁？谁要看这个看板？看的目的是什么？希望通过看板解决什么问题？看的人关心哪些指标？看的频次是什么？相关的产品是什么？产品的业务流程是怎样的？
4.2 保持克制
有了以上问题的答案，才能够聚焦于核心诉求。接下来，我们需要做到的就是：克制，有效利用看板的空间，做到不冗余，不误解。一个看板由很多个图表组成，每个图表都应该对应需求评审时挖掘出的核心问题。
4.3 结构清晰
接下来，要做到结构清晰：看板内内容的布局、排序、配色会直接影响阅读者的阅读欲望。所以看板内数据的布局应该有设计，思考清楚：整个看板分为几个模块，每个模块内按照阅读者从上到下从左到右的阅读习惯要依次放哪些内容；应该先整体，再局部，先聚焦，再发散。借用Shneiderman关于可视化信息查询的一句话：Overview First, Zoom and Filter, Then Details-on-Demand，更多的方法可以参考格式塔设计原理。
4.4 内容清晰
最后，还要做到内容清晰：选择合适的图表，利用好图被的元素。
根据目的选择合适的图表展现形式，一般来说，我们期望通过图表表示如下9类关系：比较、分布、流程、占比、区间、关联、趋势、时间、地图
不同图表的详细介绍可以参照此文档的说明：https://antv-2018.alipay.com/zh-cn/vis/chart/index.html
图内的元素包含：标题、坐标轴、图例、标签、参考线、提示信息等。这篇文章对于如何利用好图内元素进行了详细的描述：https://www.woshipm.com/pd/4123232.html
我看到了一个很有趣的指标，叫数据油墨比（Data-ink Ratio），它是Edward Tufte在《The Visual Display of Quantitative Information》中提出来的：
数据油墨比=图表中用于数据的墨水量/总的油墨量
一副图中绝大部分的墨水应该用于展示数据信息，而其他一些辅助性的元素如果没有合理使用就会产生冗余，影响我们的信息传递效果。
最后想借用AntV的4条设计原则结束这一章的内容：
一个好的数据看板，可以做到：准确、清晰、有效、美。
5 数据需求池——有序工作
看到一个很有趣的说法：“执行最大的敌人就是：日常工作”。
我和身边的同事沟通，发现很多人都有过类似的体验：埋头工作忙了一周，突然停下来问自己：你在忙什么？发现都是一些琐事，很难说清楚明确的产出。
我们的工作就像是一搜小船在大海中航行，各种风浪、暗流（日常琐事、紧急事物）都会影响到你航行的方向，如果没有明确的路线图，特别容易在原地画圈圈。所以我们应该把日常工作管理起来，将事情分为：重点工作、常规工作、紧急工作。我个人观点，认为三者占用的比例应该为6:3:1。
另外可能发生的事情是，某个业务方提了需求后，因为我们手头还有其他的事情需要先处理，业务方就会认为数据团队支持的速度太慢了，所以需要讲明白手头的事情，时间都花在哪里了。
推荐大家用起数据需求池这个工具，它能够帮助我们列清手头的工作，做好分类、排序。
建议需求池包含如下字段：
| 序号 | 字段 | 说明 |
| 1 | 需求名称 | 简洁、清晰易懂 |
| 2 | 模块 | 对业务进行拆分的模块，如：市场、销售、服务 |
| 3 | 类型 | 提数；分析；看板 |
| 4 | 提出人 | |
| 5 | 处理人 | |
| 6 | 提出日期 | |
| 7 | 开始日期 | |
| 8 | 完成日期 | |
| 9 | 状态 | 已提需未开始；已开始未完成；已完成未验收；已验收 |
| 10 | 优先级 | 已提需未开始；已开始未完成；已完成未验收；已验收 |
| 11 | 需求描述 | 由提需人填写，写明白点数据需求的目的、预期交付物 |
| 12 | 预期收益 | 做有意义的事情 |
| 13 | 备注 |
6 数据分析——助力业务
通过以上数据字典、数据看板的搭建，我们已经拿到了业务关注的数据，而业务数据分析就是对以上数据的规律、变化、异常进行解读。
当我们在做业务数据分析的时候，我们到底想要得到什么呢？
- 感知业务现状：我们业务体量如何？发展趋势如何？
- 挖掘问题原因：根据数据找到问题可能的原因，并用数据进一步验证假设。
- 寻找业务机会：找到数据波动的规律或者是原因，进而顺势而为制定策略。
一般来说，数据分析工作包含如下步骤：
- 明确问题
- 理清业务逻辑
- 做出假设
- 获取数据（数据探查+数据清洗）
- 给出观点和方案
- 跟踪执行结果
在本小节接下来的部分，我会以一个实战分析案例对数据分析的6个步骤分别进行阐述。
6.1 明确问题
“做正确的事情比把事情做正确更重要”，要想做好一个专项的数据分析，需要投入很多的精力去假设、提数、验证，因此，为了避免浪费精力做无用工，务必要在项目的最开始明确清楚问题：谁需要这个分析的结果？他为什么需要这个分析？他会拿分析结果做什么？这个分析理想的交付物是什么？他希望解答哪几个问题？
案例时间
销售团队新上线了一个产品功能：新线索的分配由指针分配变为抢新分配。 指针分配是指：将新生成的用户线索1by1地分配给销售人员。 抢新分配是指：将新生成的用户线索放到一个待分配池子内，员工点击【我要抢新】button后，将1个线索分配给这名点击button的员工。 现在产品leader想请数据分析的同事帮忙分析一下抢新分配的使用数据。 基于以上的信息，如何进一步明确问题呢？ 于是数据分析师就进一步追问： - 为什么要把线索分配的模式由指针分配变为抢新分配呢？ Answer：希望缩短线索的首次触达时间，因为指针分配时，一个销售拿到线索时并不一定是这个销售Ready的时候，所以中间可能会耽搁一段时间；而新线索的首次触达时间越短，它的转化率就会越高。 - 为什么产品leader要看这个数据呢？ Answer：产品leader希望看到这个功能上线后是否达到了预期的目的；同时他想了解这个产品功能是否还有迭代的需要；第三他希望知道辛辛苦苦做出来的功能业务团队有没有充分利用起来；另外还有一个导火索是有一些线索一直没有被分下去，想知道哪里出现了问题。 根据以上追问得到的答案，就可以总结出这个研究的目的了： - 感知业务现状：验证抢新上线后的效果：新线索首联时长是否有缩短？新线索触达率是否有提升？ - 挖掘问题原因：为什么会有线索长时间没有被分下去？ - 寻找业务机会：产品如何迭代？业务动作如何改进？
6.2 理清业务逻辑
前面的第2章节有提到过，了解业务才能让我们避免纸上谈兵。在实际进行数据分析的时候，我就更应该搞清楚要分析的产品，它实际的运行流程是怎样的，否则都不知道如何提数。
案例时间
以抢新分析举例： 【基本概念：线索池】 供员工抢新的线索池，由3部分组成，按照优先级从高到低排序为： - 新线索 - A类老线索 - B类老线索 【抢新锁定】 员工点击“我要抢新”后，会锁定抢新线索池内的一个线索。 【抢新外呼】 锁定之后，系统自动给这个线索拨打电话 如果电话拨打通了，线索会被分配给这名销售 【冷冻】 如果电话没有接通而是外呼失败，线索会重新回到线索池内，并被置为冷冻状态。 冷冻状态的线索不能被抢新；当冷冻线索超过了设定的冷冻时间后，会被置为正常状态，可以被抢新；如果一个线索连续x次被抢新外呼时均无法拨通电话，线索会从抢新线索池内移除到灰名单内。
6.3 做出假设
前面有提到数据分析按照目的分为3类：感知业务现状、挖掘问题原因、寻找业务机会。在挖掘问题原因的时候，我们需要基于前面理清的业务逻辑，再加上更多的信息输入做出假设。
案例时间
以抢新分析举例： 为什么会有部分线索没有被分配出去呢？ - 有可能是因为员工不积极，没有多少人点“我要抢新”。 - 也可能是线索质量低，这些线索的电话本身就打不通。 - 还可能是产品功能有bug，有些线索没有被触达到。
6.4 获取数据
明确了问题，理清了业务逻辑，接下来就要获取数据了。获取数据的四件事：
- 明确统计口径
- 列出数据清单
- 数据探查+数据清洗
- 数据清洗
确认正确的数据口径太重要了，错误的口径会给你引入错误的方向，得出相反的结论，比如如下案例：
在抢新分析中，有个分析目的是：验证抢新上线后的效果：新线索首联时长是否有缩短？ 那么如何定义新线索的首联时长呢？这里至少有2个需要考虑的点，分别是：以用户注册即线索生成的时间为起点还是以线索分配给销售的时间为起点？以销售尝试触达用户为终点还是以销售真实触达到用户为终点？那么就有4种可能的指标口径： A. 首次尝试触达时间与注册时间的间隔 B. 首次尝试触达时间与分配时间的间隔 C. 首次触达到时间与注册时间的间隔 D. 首次触达到时间与分配时间的间隔 之所以要分析新线索的首联时长是否有缩短，是想要了解用户注册后是否被更快地联系到了，所以应该以注册时间为起点，以首次触达到时间为终点，也就是C口径。 如果拿B或D口径去出数，那么数字就会非常高，但是没有回答上面的问题。因为很明显，抢新分配中，员工只有在ready时才回去点击”我要抢新“，抢到线索后会马上联系用户；而指针分配中，员工不一定随时ready，那么以分配时间为起点的指标自然偏高。
在确认统计口径的时候，还需要考虑取数的周期，一定是apple to apple的对比。事物永远是发展、变化、运动的，不同的取数周期取出来的数字也是大相径庭。
案例时间：
在抢新分析中，需要对比抢新上线前后的数据，那么拿哪两个时间段的数据进行对比呢？需要考虑如下因素： a. 前后两个时间段，线索来源的比例分布应该基本一致，避免因线索质量影响结果。 b. 时间段不能过短，否则样本量不够。 c. 触达动作需要一定的时间，所以要考虑数据发酵的时间。
基于问题、业务逻辑、假设、统计口径后，就可以列出需要数据的清单，这是一个先发散再收敛的过程。
以抢新分析举例，最终抽象出了两个源数据清单，分别是：新线索明细、抢新动作日志明细。
在列出了需要的数据清单后，就要进行数据探查及数据清洗。如果完成了前文中的数据字典搭建，那么数据探查会简单很多。
数据清洗是为了解决数据的完整性、唯一性、合法性等问题，一般分为如下步骤：
- 重复数据，看有没有数据是重复的，如果有，删除重复数据。
- 不相关数据，剔除与分析不相关的数据。
- 异常值，包含极大极小值、空值。
以抢新分析举例
关于重复数据： 在数仓内提取新线索明细后，发现同一线索有很多行数据，进一步探究后，发现是在join时的一个代码逻辑错误导致的，修正后再次验证，确保了每条线索只有1行数据。 关于异常值： 在新线索明细表中，有一部分线索的被抢新次数为空，但是却被分配出去了。在业务系统内查询，发现这些线索是被手动分配下去的，那么在接下来的分析中就要考虑这种场景。
6.5 给出结论和观点
在开篇的数据分析团队工作痛点中有提到，一个常见的问题是“太多数据，太少信息”，往往是给出了数据，但是没有说明这个数据放映了什么业务问题，没有观点。我们必须要深刻意识到：前面做的一切工作，都是为了最后这一步产出结论和观点。
这时需要做的就是以终为始：回顾这次数据分析最初的问题是什么？通过上面拿到的数据是否可以回答上面的问题？答案是什么？
以抢新分析举例（以下数字为虚拟）
问题1 感知业务现状：验证抢新上线后的效果：新线索首联时长是否有缩短？新线索触达率是否有提升？ 答：抢新上线后效果不理想。 实验组的触达率为48.6%，对照组的触达率为52.1%，所以触达率没有提升反而下降了。 观察实验组和对照组不同首联时长区间的线索占比分布，发现新线索的首联时长增加了。 问题2 挖掘问题原因：为什么会有线索长时间没有被分下去？ 答： 假设1：员工没有积极点击抢新按钮 数字验证：每个人每天点击抢新按钮的次数较低；公休日点击抢新按钮次数少；早上和晚上的时候点击抢新按钮次数少，所以员工积极性确实不高。 假设2：线索质量低，本身电话就不好打通。 数字验证：发现没打通电话的线索来源集中在几个特定渠道，所以确实与线索质量有一定关系，需要去和渠道负责人沟通，提升这几个渠道线索的质量。 假设3：产品逻辑有漏洞，有些线索始终没有被触达。 数字验证：看线索漏斗：创建 → 抢新 → 接通 → 冷冻 →再次被抢新…的分布，发现没有异常，所以产品逻辑没有发现明显漏洞。 问题3 寻找业务机会：产品如何迭代？业务动作如何改进？ 答： todo1: 如何提升员工积极性？给员工明确每天抢新按钮点击次数的要求。 todo2: 如何做好未被抢新线索的兜底？做一个数据报警，有线索超过48h没被抢新过就手动分配。 todo3: 提升低质量渠道的下所质量。
6.6 跟踪执行结果
业务数据分析的结果最终要作用到实际业务执行上面，所以并不是给出建议就行了，而是要和key person聊清楚，让他理解你的观点，并让业务切实按照结论去行动。
当业务动作改变了一段时间后，需要去进行下一轮数据分析，通过过程数据看执行力度怎么样，通过结果数据看执行效果怎么样，并发现新问题，探寻新机遇。
以抢新分析举例
在以上分析结论产出2周之后，我们进行了进一步的数据分析，希望回答以下问题：
- 销售的动作是否有优化？
- 每人每天点击抢新的次数是否变多？
- 抢新动作的时间分布是否均匀？
- 手动兜底策略是否生效？
- 数据是否有改进？
- 首联时长是否有缩短？
- Reach Rate是否有提升？
- 首次抢新时长是否有缩短？
得到了如下结论：
- 销售动作：
- 销售的动作有明显进步，抢新的次数是之前的1.5倍。
- 不过销售抢新动作分布非常不均匀，每天9am PST抢新，这时候点的次数最多；到下午3pm PST之后，就很少抢新了，会让3pm之后注册的用户等待过长时间。
- 部分员工抢新功能用得少。
- 周日没人抢新
- 手动兜底策略生效了，触发次数明显减少，这点与EC动作次数增多是因果关系。
- 结果指标：
- 首次触达到时长的分布，相对之前有进步，我们Reach到用户的时间变短了。不过仍有提升空间。
- 虽然EC的抢新动作变多，联系到用户的时间变短了，但是整体的Reached Rate没有提升。
- 过程指标：
- 首次抢新距离线索创建的时间间隔显著缩短，但相信还有提升空间。
并有了进一步的动作计划：
1. 优化销售抢新动作的时间分布，下午/晚上的时段最好也多一些，这样预计会提升触达率，进一步缩短首次触达时长。
2. 研究不同销售间抢新动作的差异，找到best practice。
3. 建议周日也要安排抢新动作。
4. 制定首次抢新距线索创建时间间隔的明确目标，并考虑进一步动作。
7 结语
以上内容来源于我工作中遇到的问题，对它们的反思、及在网上的学习，但限于有限的资源精力，很难看的全面深入，记录下来抛砖引玉。
在岩瑞的文章中，提到数据对业务团队的价值有5个阶段：
数据响应 → 数据支持 → 数据渗透 → 数据驱动 → 数据引领
- 数据响应：能够及时响应业务提出的各种数据需求
- 数据支持：根据业务流程，帮助业务开发报表，定制个性化报表
- 数据渗透：基于战略目标、业务场景和业务讨论问题，从数据中帮助业务发现问题，定位问题 ，最理想的是一同解决问题。
- 数据驱动：在理解业务、对业务现状、未来有思考和判断的前置条件下，主动从数据中发现业务策略，优化机会点，理想的做法是可以以产品化的方式去解决某个业务环节，业务场景问题。
- 数据引领：通过数据中的洞察结合业务洞察，把业务的流程或者策略进行优化，让业务的经营更智能。
那么你当前处于哪个阶段呢？希望本文中的内容可以帮助伙伴们往前走得更远。
https://tech.meituan.com/2022/05/12/business-data-governance.html