酷应用

推荐：为什么大多数分析工作都以失败告终

百家作者：数据分析 2022-01-14 08:56:16

作者：Crystal Widjaja 翻译：殷之涵校对：王可汗


本文约5400字，建议阅读11分钟
本文将从作者的亲身经历循序渐进地带你定位大多数事件分析出错的根本原因并给出解决策略。

日均订单量从两万提高到五百万；商业智能部门从无到有，如今已有100位员工；增长部门完成从8人到85人的发展。所有这些都在4年半内完成。这是一次疯狂的旅程，但并不是美国创业界许多人所熟悉的那样。这不是Uber或Lyft，而是Gojek，东南亚最大的超级APP。

对于那些不熟悉Gojek或“超级APP”概念的人来说，简而言之，这个产品可以满足你所有的需求：订餐、交通、数字支付、社区送货，以及其他十几种服务。从服务规模上看，Gojek每天完成的订餐量比Grubhub、Uber Eats和DoorDash的总和还要多，每天的出行订单数也比Lyft多。

我很幸运有机会在Gojek只有30位员工的时候就加入，并在4年半的时间里领导了公司的商业智能和增长部门的发展，帮助它成为东南亚最大的消费交易技术集团。Gojek成功的关键之一是通过健全而简单的数据系统为其赋能，以快速做出基于数据的决策。

但一开始的时候并非如此。在我刚加入公司的时候，"IT "人员正在运行SQL查询。仅仅一周的时间，我就意识到这些查询中的大多数都是非常不准确的，而且大多数人压根就不明白数据到底是什么。有人给了我一张便利贴，上面写着已完成订单的确认方法（flag_booking=2，booking_status=4）。没有数据基础设施，所有的查询结果都被复制粘贴到excel报告中，并通过电子邮件手动发送给领导。

于是我招了3个数据仓库团队成员，我们把所有的数据都放到了一个带有Pentaho ETL功能的Postgres数据仓库中。但由于我们的规模迅速增长，这个方法在8个月内就变得毫无用处了。之后我们就迁移到了谷歌云平台，并开始使用BigQuery、BigTable、Data Flow、Airflow等。

我们也经历了对各种可视化工具的应用探索。从Tableau开始，接着是Metabase，第3年开始使用公司的内部工具。我们的实验平台从手动上传CSV到BigQuery表格，再到类似Airbnb的ERF那样的内部系统。

毋庸置疑，我在Gojek开始了我的数据之路，并且一直在帮助像Carousell、Cashdrop、CRED、Celo、红杉资本投资的一系列公司以及其他的初创公司走过这个迷宫。除了所有的工具之外，有一个基础性的前提决定了公司内任何数据计划的成败——你得考虑好到底要追踪什么、如何追踪，以及如何随着时间的推移管理追踪到的结果。

如果把这些事情都搞错了，即使是世界上最好的工具也救不了你。

这篇文章可以被拆解为如下3个主题：

1. 数据症状：面对数据问题，团队会经历的一系列常见“症状”

2. 数据问题的根本原因：产生这些症状的实际根源

3. 循序渐进的解决方案：我的循序渐进的过程，我认为什么要跟踪，如何跟踪它。随着时间的推移来管理它，并使用Event Tracker模板来帮助指导这个过程。

"我们的数据一团糟！"

我帮助过的一个团队认为他们对入职流程进行了6个多月的追踪，但从未"使用"和分析过这些数据，最初做这项工作的人决定离开公司。对团队进行了调研后，我就发现基本没有任何数据是被正确记录的。例如，数据显示，在入职培训中做了某个动作的人比点击"注册"的人多，这压根是不可能的。这些数据最后都是没有用的。

这个故事和我的便利贴故事都很常见，大多数公司可能都会自述他们的数据一团糟。当他们这样说的时候，情况通常指向以下几个常见症状之一：

1. 缺乏统一语言/鸡同鸭讲

2. 知识转移缓慢

3. 缺少信任

4. 无法迅速对数据采取行动

缺乏统一语言/鸡同鸭讲

在一个APP中，有大量的不同方法来描述相同的体验。如果你问你的团队"用户是如何结账的"，在很多情况下，没有人会给出同样的步骤、使用同样的术语。

这主要因为在一个APP中有多种方法做同样的事情，或者导航标签（Navigation Tabs）里面有未命名的图标。比如，“价格页面”既可以指价格概览页面，也可以指价格详情页面；又比如，某个页面到底叫做“个人资料”还是“账户设置”？这些可能听起来是同一个东西，但在很多产品中又是不同的。

统一语言的缺乏让数据变得无用。我们需要花更多的时间和其他团队就数据进行深入的讨论，或者对数据的实际含义达成共识。更糟糕的是，团队可能认为他们有一个共同的理解，但实际上并没有。这种阻力通常会导致人们的挫败感，以及从根本上避免对数据的使用。

知识转移缓慢

当新人加入团队、员工转换团队或者有人离开公司时，在接替者"完全有生产力"之前，都需要进行知识转移。特别是在当下每个人平均每隔18个月就换一次工作、甚至以更频繁的节奏转换团队的就业环境下，知识转移尤为关键。

许多团队通过大量的入职培训来弥补他们糟糕的数据产品所造成的问题，但这最终只起到“创可贴”的作用。这就跟试图用大量的新用户指导、规则解释和培训来弥补一个非常糟糕的产品是一样的。随着时间的推移，这些东西变得昂贵而无效。

站在内部员工的角度看待培训，这一点更加真实——员工更希望把他们的时间花在工作上，而不是在无休止的培训里浪费时间。

缺少信任

当你查看或展示数据时，有多少次会在心里怀疑："这数据真的是对的吗？"大多数数据的一个常见症状是，组织中的人就是不信任它。有时候这是因为数据质量确实糟糕，但也可能是因为人们对某个事件或特性的含义本来就存在误解。

无法迅速对数据采取行动

上述所有问题其实都指向一个宏观的症状——无法迅速对数据采取行动。在一个充满季度OKR和市场高速竞争的世界里，团队永远受到时间和资源的限制。当面临以下权衡时：A.花费大量时间来获取他们信任和理解的数据、B.跳过这一步直接推进工作，很多团队都会选择后者。

根本原因

解决上述问题的挑战在于它们只是“症状”。许多团队试图用一些方法来解决这些症状，例如：

新的工具
更好/更多的培训
提高招聘中对候选人技术能力、分析能力的要求
但通常这些方法可能只是浪费时间和金钱，因为你没有找到根本原因和真正的问题所在。根本原因通常源于以下一个或多个方面：
以追踪指标为目标vs分析指标
开发者思维/数据思维 vs 商业用户思维
错误的抽象水平
书面交流 vs 视觉交流
数据仅作为一个项目 vs 持续倡议

理解它们对于区分成功和失败的团队非常重要，我们将逐一展开解释。

以追踪指标为目标vs分析指标

许多团队认为数据计划的目标是追踪指标，但真正的目标是分析这些指标——这两件事是非常不同的，后者指的是我们如何使信息具有“可操作性”。使信息具有可操作性并不是报告完成了某件事情的人数，而是我们如何区分在某个事件（例如完成订单）上“成功”的用户和“失败”的用户在我们的产品中分别做了什么，以便我们能够采取步骤进行改进。这一细微差别通常被忽略，但正如你将看到的那样，它从根本上改变了我们如何对待我们所追踪的东西以及追踪它的方式。

开发者思维/数据思维 vs 商业用户思维

构建任何优秀产品都有一个核心原则——深入了解你的目标用户/客户、体会他们的感受。在建立数据系统时，许多团队都忽略了他们的客户是谁，或者根本就没有考虑到他们的客户是“商业用户（business user）”这一事实。

构建优秀的分析系统，首先要深刻理解业务用户的问题和能力，就像你对产品的目标客户那样。以Gojek为例，我们的大多数商业用户并非SQL分析员，而是非技术岗位的产品经理、营销人员或运营经理。

他们是我们的最终用户，我们专门为他们构建，目标是使数据和分析过程人性化。这影响了我们思考所有事情的方式，从使用什么工具，跟踪什么事件，如何给事件命名，到需要什么属性。

对我们来说，真正的考验是——我们的运营/客户服务团队成员能否在没有完整的入职培训的情况下访问事件追踪工具和用户界面平台并独立使用它吗？运营/客服团队对市场的了解最少，与产品开发过程的距离也最远。如果他们都能够使用我们搭建的分析系统去分析问题，那么团队的其他成员就更可能做到这一点。

错误的抽象水平

追踪工作中最难做好的事情之一是对追踪内容的正确抽象程度。坏（Bad）的追踪是指我们的事件过于广泛，一般（OK）的追踪是指我们的事件过于具体，而很好（Great）的追踪是指我们平衡了这两者。让我们来看一个例子。

以“注册”这个常见的事件为例。

坏的追踪："Facebook注册 "或 "Google注册"。在这种情况下，我们将事件命名为 "Facebook注册 "和 "Google注册"，取决于"来源"，然而这也太宽泛了。这是否意味着用户已经选择了一种注册方式？注册成功了吗？如果尝试了注册失败了呢？只看事件的名称，我们无法得知上述问题的答案。此外，如果我们想知道有多少这样的注册发生，则需要单独添加所有这些独特的事件，这就使得任何潜在的分析都很繁琐，而且对任何产品经理来说都是不可能的。

一般的追踪："点击注册"。在这种情况下，我们已经对事件进行了非常具体的分析。在这里，我们至少知道当事件发生时它意味着什么。但是挑战在于，当想查看所有被选中的注册来源的时候，我们并不知道有哪些来源存在，而且很难做出实际的决策。虽然我们通过事件掌握了行为的 "症状"，但我们没有能力通过参数值进行 "诊断"。

很好的追踪："选择了注册"。在这个例子中，我们有正确的抽象层次。事件是明确的——一个注册方法被选中了，而且它拥有“事件来源”这一属性，这样我们就可以在需要时通过注册来源来划分用户进行分析。

让情况变得更加复杂的是，我经常发现团队将不同的抽象水平混在一起。或者，由于用户旅程和产品重新设计不可避免地导致了新的产品流，不同的实现“时代”使得抽象水平更加混乱。这使得系统变得更加混乱和难以理解。我们会在下文中如何达到正确的抽象水平这一步骤中谈及更多。

书面交流 vs 视觉交流

对于分析事件是什么和意味着什么，有一个共同的"真相"来源是至关重要的。糟糕的数据团队不会有任何类型的事件字典或书面文件来说明被追踪的内容，而是让团队有自己的定义和解释；好的团队至少会有一个共享且持续更新的字典；而更好的团队则会把视觉交流与书面交流相结合。

无论我们如何命名或定义事件和属性，没有什么比与事件相对应的视觉更清楚了。当你在讨论一个事件、用户旅程或其他数据时，人们会在脑海中想象出与之对应的屏幕和产品的各个部分。通过使分析事件变得清晰和显而易见，这一过程可以被大大缩短。正如我将在下文所展示的那样，我会从两个方面来考虑这个问题：第一，事件触发时产品中正在发生的事情的屏幕截图；第二，将事件映射到客户旅程的可视化表示。

数据仅作为一个项目 vs 持续倡议

最后，我们来谈谈是将数据仅视为一个项目还是一个持续进行的核心计划。你必须把数据系统当作一个不断迭代的产品。随着时间的推移，产品会改变，目标会改变，业务也会改变。因此，如果你没有不断地迭代数据系统，就会面临Brian Balfour所说的 "数据死亡之轮"。

循序渐进的过程

工具——事件追踪词典

在我们深入到流程的各个步骤之前，关键是要有一个 "工具 "来帮助组织、协调和沟通决策。为此，我使用了一个事件追踪字典，它定义了我们正在追踪的数据和它的一些重要方面。在共同创建这些规范的过程中，关于产品内各个部分的跨团队共享语言被创造了出来。

我们提供了一个模板和一个例子，点击下方链接获取：

https://docs.google.com/spreadsheets/d/1UmAU9aNvGOPNY0vG-LKE5Ka2VEbbNtTSgVlob2irb-4/edit?usp=sharing

事件追踪字典中的字段

字典中的基本字段如下：

Event Name-事件名：行动的名称。最好使用一个成熟用户可能用来描述其行为的特定短语来命名
Triggers when...-触发机制：一个特定的API响应、用户操作或事件，这个事件的快照和它的属性被发送到我们的日志里去
Screen-屏幕：用户在行动被触发时所处位置的屏幕截图或图像
Properties-属性：和此事件一起被追踪的属性名称的列表（例如来源、是否登录等）
Example Property Value-属性值示例：最好是详尽、无遗漏地列出上述每个属性下的潜在值。在潜在值有限的情况下（例如潜在的注册来源有Facebook、Email、Google等），最好全部列出它们。
Data/Property Type-数据/属性类型 - 每个属性应该限制为一种数据类型，如布尔值、字符串、数字、经纬度或浮点数
Description-描述：你将如何向从未使用过该产品的人描述这个被捕获的事件？使用这个字段来消除未来接手的业务团队和实施这些规范的工程团队之间产生误解的可能性。
Technical Comments-技术评论：OAuth、API和内部服务可能有自己的特殊习惯，因此要在这里详细说明，例如像将多个响应结果聚合成一个单一的 "success"值的规范等。
Testing Comments-测试注释：这是一个活生生的文档。当新功能发布时，最好是通过QA，确保必要的事件发生。在这里沟通更改和问题将有助于快速解决问题。