实战经验：大数据分析为什么大多数会失败？-轻识

本帖由东南亚最大的超级应用程序之一Gojek的商业智能BI前高级副总裁Crystal撰写。以下是摘要，原文点击标题：

Gojek成为东南亚最大的消费交易技术集团，其超级app应用包括订购食品、交通、数字支付、超本地送货和十几项其他服务。Gojek每天完成的食物订单比Grubhub、Uber Eats和DoorDash的总和还要多，每天的旅行次数也比Lyft多。

Crystal帮助Gojek将订单从每天2万份增加到500万份。商业智能团队从0到100人，全部在4.5年内实现增长。

当我第一次加入时，有个“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的内部系统。

从那以后，我一直在帮助Carousell、Cashdrop、CRED、Celo、红杉投资组合公司和其他公司等初创企业在迷宫中导航。

除了所有工具外，还有一个基础的事情可以促成或破坏公司内部的任何数据倡议：您如何思考跟踪什么，如何跟踪它，以及如何随着时间的推移对其进行管理。

如果你把这些原则方法弄错了，世界上最好的工具不会拯救你。

在本帖中，我分析了：

数据症状 - 团队在数据问题方面最常见的症状。
数据问题的根本原因 - 这些症状的实际根本原因。
分步流程-我逐步了解如何思考要跟踪的内容，如何跟踪它，以及如何随着时间的推移对其进行管理，并配有事件跟踪器模板，以帮助指导流程。

大多数公司可能会将自己的数据描述为“混乱”。当他们这么说时，他们通常指的是少数常见症状之一：

缺乏共享语言
知识转让缓慢
缺乏信任
无法快速处理数据

缺乏领域共享通用统一语言：

在应用程序中描述相同体验的方法有很多。如果您问您的团队“用户如何结账？”——在许多情况下，没有人会使用相同的术语说出相同的步骤集。

当应用程序中有多种方法做同样的事情时，或者当导航选项卡是未命名的图标时，这主要是个问题。例如定价页面可以是定价概览或详细定价。是描述文件还是帐户设置？这些听起来可能相同，但在许多产品中有所不同。

缺乏共享语言开始使数据变得无用。与其他团队就数据进行深思熟虑的讨论或对数据的实际含义达成共识需要花费更多时间。更糟糕的是，当团队真的不理解时，他们可能会认为他们有一个共同的理解。这种摩擦通常会导致沮丧和完全避免使用数据。

上述挑战在于它们只是症状。许多团队试图通过以下方法解决症状：

新工具
更好的/更多的培训
要求更高的技术/分析标准来招聘

但通常，这些事情可能会浪费时间和金钱，因为你没有解决根本原因和实际问题。相反，根本原因通常源于以下一个或多个：

分析指标，而不是如何跟踪指标。
开发者/数据思维与业务用户思维。
抽象程度错误。
仅书面与视觉沟通
数据作为一个项目与正在进行的倡议

了解它们对于成功团队和失败团队分开很重要，所以让我们单独检查每个团队。

许多团队认为，数据分析的目标是跟踪指标。然而，真正的数据分析目标是分析这些指标。

这两件事非常不同。

后者是我们如何使信息可操作。使信息可操作性不是报告做某事的人数，而是我们如何区分成功人士和失败者在我们的产品中做什么，以便我们能够采取措施进行改进。这种细微差别通常会消失，但正如您将看到的那样，我们如何处理跟踪的内容和跟踪它的方式发生了根本变化。

跟踪最难做的事情之一是正确地抽象了跟踪的内容。糟糕的跟踪是指当我们的领域或界面事件过于抽象宽泛具有普遍性，良好的跟踪是指当我们的领域或界面事件比较具体，出色的领域或界面事件设计是指当我们平衡这两者。

让我们考虑一个常见的用户注册事件。

（坏）“Facebook注册”或“谷歌注册”-在这种情况下，我们根据“来源”将事件命名为来自“Facebook注册”和“谷歌注册”。然而，它太宽泛了。这是否意味着只是在界面选择selected注册按钮但是没有点击？或已经是注册成功完成？如果注册尝试却失败了怎么办？仅仅通过查看事件名称，我不知道这些问题的答案。此外，如果我想知道这些注册中有多少次，我需要单独添加所有这些独特的事件，使任何潜在的分析对任何PM来说都乏味和令人望而却步。
（好的）“注册已点击”-在这种情况下，我们对事件非常具体。在这里，我至少确切地知道事件发生时意味着什么。挑战在于，如果我想查看所有选定的注册来源。我不知道存在哪些来源，也很难做出实际决定。虽然我们有通过事件行为行为的“症状”，但我们没有能力通过参数值“诊断”。
（很棒）“注册已选中”-在本例中，我们有正确的抽象水平。事件是明确的，已经选择了注册方法，我对源事件需要设立有一个专门来源属性，以便在需要时可以追溯。

通过设计事件字典统一领域语言：

事件跟踪词典中的字段属性有专门规定，像一部字典一样，字典中的基础字段是：

事件名称 - 操作的名称。最佳使用特定短语命名，这些短语可能由资深用户用来描述他们的行为
当...触发时-作为此事件及其属性发送到我们日志的快照的特定API响应、用户操作或事件。
屏幕 - 显示触发操作时用户位置的截屏或图像
属性-将随此事件一起跟踪的属性名称列表（例如源，isLoggedIn）
属性值示例-最好详尽无遗地完成，上面每个属性下的潜在值列表。在潜在价值集有限的情况下（例如Facebook、电子邮件、Google等潜在的注册来源），最好在这里列出它们。
数据/属性类型-每个属性都应限制为一种数据类型，如布尔值、字符串、数字、纬度和经度或浮点。
描述 - 您如何描述此事件被记录给以前从未使用过该产品的人？使用此字段消除未来使用该字段的业务团队和执行这些规范的工程团队之间任何错位的可能性。
技术评论-OAuth、API和内部服务可以有自己的怪癖，你想在这里详述。像将2XX个响应聚合到单个“成功”值这样的规范可以在这里进行。
测试评论-这是一个活生生的、令人呼吸的文档。当新功能发布时，最好通过QA并确保事件在必要时引发。在这里传达更改和问题可以快速解决问题。

团队拓扑与产品管理：

大多数分析系统的最终用户都是业务用户。我们需要构建一些与该最终用户产生共鸣的东西。这意味着使数据和分析过程人性化。这会影响我们如何选择要使用的工具、要跟踪的事件、如何命名事件以及需要什么属性。在这里花费有意义的时间是值得的，就像我们在新产品的客户研究中一样。

为了进入业务用户的心态，我经历了四个层次的问题。对于每个问题，我都提供了我最近合作过的一个名为Honeydu的产品中的一些示例，Honeydu是公司在线免费发送和接收发票的一种方式。

业务目标和目的是什么？业务和执行团队正在优化哪些关键结果和指标？这些信息的来源将是当前和历史的OKR、季度和年度规划文件以及董事会甲板。示例一：X个新用户在2020年第四季度末之前收到/发送发票示例二：发送给新用户的发票的X%会导致新用户注册示例三：2020年第四季度末活跃的X张经常性发票
每个团队的目标和目的是什么？公司的高水平目标是不够的。每个团队通常都有一套目标和目的，这些目标和目的可以提升到公司级别的指标。要了解这些目标和目的，您可以找出每个团队的 OKR，与团队领导交谈等。在这里，您想了解他们在历史上的几个时间段时间段，以及团队领导在将来的几个时间段时间里的想法。示例一：（新用户增长）前7天内发送2张发票示例二：（付款集成）85%的新付款方式已成功验证示例三：（NUX）以发票模板开头的新用户百分比
围绕这些目标和目的，产品体验有哪些？接下来，对于每个目标/目标，我确定与推动这些目标/目标对应的产品体验。重要的是，不仅要识别产品或漏斗的特定屏幕，还要识别可能影响目标或行动的体验背景。例如，在优步这样的拼车产品中，如果产品体验是预订拼车，除了预订拼车的漏斗外，我可能还想知道地图上有多少司机？或者，预计时间是多少？第1步：在Honeydu中，许多不同的因素可能导致用户发送他们的第一张发票，这是我们的核心行动。我们会问自己：

当用户选择要向其发送发票的联系人时，当用户的历史业务列表中有联系人时，或者当他们需要搜索时，他们更有可能成功吗？
哪些支持操作可以帮助用户创建和发送他们的第一张发票？
发票模板是加快发送时间的好方法吗？
还是更重要的是，他们的联系人首先导入？

第2步：下一步是思考可能阻止用户实现我们的目标和目的的经验。在Honeydu的案例中，我会问：为什么新用户没有成功创建他们的第一张发票？他们是否查看了不同的模板，但没有找到与他们相关的模板？他们是否尝试从头开始创建发票，发现回到我们的模板目录太难了？我们已激活的用户执行了哪些操作，而未激活的用户没有执行？

第3步：最后，想象一下，任何事件都可能是我们在产品中从用户那里跟踪的最后一个事件。关于这次经历，我们想知道什么？我们需要知道他们在联系搜索后是否获得了“未找到结果”页面，或者在添加新付款方式时出错，并利用这些活动的受欢迎程度开始对我们用户体验中的问题进行分类诊断。

我/他们可能想围绕这些目标和产品体验回答哪些问题/假设？
接下来，我想一想他们（或我）在这些目标或目的周围可能有什么问题或假设。同样，在这里，与团队领导或团队中的个人贡献者讨论他们面临的问题。但也请自己思考，提出问题的假设，并与该团队验证这些问题的重要性水平。
示例一：Honeydu上的关键目标和产品体验之一是有人发送他们的第一张发票。我想问一个问题，我认为需要哪些经验才能有人对向企业发送发票有信心？像“他们需要使用我们行业批准的模板之一”或“他们看到Honeydu网络中已经列出的业务”这样的假设表明，我们需要能够跟踪经验，以便量化并从假设转向对相关性/因果关系的信心。
示例二：通过Honeydu支付发票的用户越多，我们产生的收入就越多。我们应该跟踪用户最有可能在什么时候支付发票，问问自己“用户什么时候最有可能通过Honeydu支付发票？今天什么时候到期？明天？”通过跟踪Pay Invoice Success事件上的 daysTillDueDate属性，我们可以为那些没有自然地看到发票到期日而不在自然倾向之外发送垃圾邮件的用户提供信息并构建我们的推送通知和电子邮件策略。

下面是几个快速示例显示了意图→成功→失败的事件旅程：

示例一

意图：
添加新付款方式并添加已提交的新付款详细信息
成功：
添加新付款方式成功
失败：
添加新付款方式失败

示例二

意图：
创建已选中的发票→新发票已启动→联系人搜索
成功：
收件人已添加到发票→发票已发送
失败：
已保存发票草稿（默认操作）

2A - 成功事件

我首先仔细考虑成功事件。成功事件是指产品中的操作已成功完成。这些事件源于我在第一步中收集的业务目标。成功事件的示例可能包括：

付款成功
注册成功
发票已发送
已完成预订

为了不过度跟踪所有内容，我用一个问题对每个事件进行压力测试。“想象一下，我确实跟踪了这个，99%的用户做到了，我会怎么做？它告诉我什么？”如果我无法找到可以极端操作的东西，那么这个事件可能没有帮助。

2B - 意向性事件

然后，对于每个成功事件，我都会仔细考虑意图事件。意向性事件通常是任何成功事件的前身所需的一步。跟踪意向事件对于理解围绕成功事件的“原因”至关重要。

意向事件告诉我，用户如何“受过教育”和“有动力”完成我希望他们完成的操作的一些步骤。实际上，一切都是下一个事件的故意事件——但我们通常只认为它们是“目标”，这阻碍了我们准确跟踪它们。例如，在骑行共享应用程序中，选择目的地是一个目标，但需要选择骑行类型的意图/设置事件（在旧的Lyft/Uber流程中）。然后，预订某个骑行成为目标，但需要从搜索/历史等中找到目的地的意图/设置事件......

为了想出有意图的事件，我问——为了完成成功事件，我必须完成哪些步骤？常见的示例包括：

在我们的第一个旅程示例中，我们注意到了“添加新付款方式已选择”和“添加新付款详细信息已提交”的意图事件

请注意，我们这里有两个层次的意图——高意图，即用户正在积极提交付款详细信息，以及低但指示性的意图，即用户选择是通过银行还是信用卡添加付款详细信息。
在这些事件之间投递会导致团队可以执行的后续步骤：
要么用户发现输入字段令人生畏，要么当时没有这些信息。
我们现在知道他们是否选择了银行或信用卡付款方式，并可以跟进更多信息和个性化内容，以帮助用户完成此步骤。

我还使用Intent Events意图事件来识别用户在完成操作时自然采取的路径。例如，使用我们的发票和账单支付应用程序，用户是先导入联系人还是先创建发票来发送发票？随着我们的账单支付网络的增长，这种行为会有什么变化？

同样，在Gojek的食品配送产品中，我们注意到我们最成功的用户是那些已经知道自己想吃什么的人，他们来Gojek只是为了完成送货服务。这些用户的意图是搜索特定的餐厅，找到他们想要的菜单项，最后设置他们的送货详细信息。然而，随着这些用户的成熟，我们注意到，随着用户开始更多地使用Gojek作为发现新餐厅的手段，而不是满足他们已经认识的餐厅，最普遍的用户意向之旅发生了变化。现在，意向性活动包括滚动浏览朋友的食物提要、浏览折扣交易或使用“附近”功能。

这些意向性事件对于理解Bangaly Kaba（Reforge EIR，Instagram前增长主管）所谓的相邻用户至关重要。随着用户的成熟和市场的扩张，这些旅程会随着时间的推移而演变，我们的产品也应该通过匹配新用户的意图和成熟的用户的意图来实现。

2C - 故障事件

失败事件是指发生在意图事件和成功事件之间，阻止用户取得成功。在意图事件和成功事件之间存在许多用户可能会遇到的故障路径。了解失败路径对于理解成功路径同样至关重要，因为它们为我们提供了关于如何改进成功事件的可操作信息。要想出故障事件，我问-哪些可能阻止用户完成目标？有两种类型的故障事件：

隐含失败是指在成功完成目标之前发生的掉期。用户只是从我们的旅程中“消失”。在我们上面的两个旅程示例中，事件的跟踪方式提供了两个隐含的故障指标

执行Create Invoice Selected但没有在5分钟内执行New Invoice Started的用户表示我们的激活旅程失败。
执行联系人搜索但在5分钟内未执行收件人添加到发票的用户表示我们的搜索结果或搜索历史记录失败。
用户可能没有足够的动力从头开始创建联系人，或发现令人困惑的结果。

显式故障是指预期体验出错的事件。

订购外卖时，Lyft上的“骑行取消”或“订单取消——餐厅关闭”等事件是明显失败的例子
在Honeydu中，添加新付款方式失败和支付发票失败是事件跟踪练习中经常被遗忘的两个例子，因为它们是对用户行为的响应，而不是产品内实际采取的行动。
但是，如果您的网络/移动应用程序收到错误并将其显示给您的用户，这些错误应该易于跟踪和记录以进行监控。
将这些错误响应消息存储为事件属性是快速诊断为什么常见的用户旅程可能突然失败的简单方法。

3 - 属性

一旦我们成功、意图和失败事件，下一步就是找出我们要与事件关联的属性。属性再次成为实现我们两个主要目标的关键，即提供正确的抽象水平并使数据可操作。

属性本质上是我想分割事件的方式。一个关键错误是将分割跟踪为事件本身。例如：

良好：注册选择（事件）、来源（财产）、Facebook（财产价值）
错误：Facebook注册已选择

了解您可能需要跟踪哪些属性的一个关键来源是您在第一步中发现的问题和假设。

问题示例：用户更喜欢如何添加联系人？

属性示例：
来源→历史记录/导入/手动输入

假设示例：与选择构建自己的发票的用户相比，初次自由职业者更有可能使用模板开始使用模板，并且需要更多的入职才能获得核心价值。

属性示例：
模板名称→（空）/基本发票等。

我喜欢问一些高级问题，以确定哪些属性很重要：

我如何细分变得沮丧和无私的用户？
我如何识别成熟用户和临时用户使用的不同路径？
这是否给了我足够的细微数据来比较和对比成功用户和下车用户？
如果这是我最后一次从用户那里跟踪的事件，我想知道关于用户在这个屏幕上的体验吗？

属性往往落入少数常见的桶之一。为了确保我彻底，我使用这些桶来查看我是否遗漏了什么：

用户配置文件属性

最常见的属性集是与用户配置文件相关的属性集。这可能是人口统计或公司信息。一些例子：

城市
年龄
公司规模
角色
产品等级

通常情况下，这些都是您希望能够从属性更改之前永久分割用户和事件的东西。一些平台，如Mixpanel，包含超级属性等功能，允许您轻松做到这一点。要问的问题，以弄清楚要跟踪以下哪些属性：

如果我是这个用户的个人助理，我需要了解哪些关于他们的偏好才能提供帮助？
哪些人口统计信息可能会影响用户的行为？

营销属性

第二组最常见的属性是那些可能影响或影响用户行为的与营销相关的属性。这可能包括以下内容：

来源
竞选活动
条目页面

用户操作属性

另一组属性是与用户操作相关的属性。例如：

首次购买日期
第一种服务类型
订单总数

在这里，区分两种类型的属性很重要：

设置和忘记-这些属性是您设置过一次，但之后不会更改。例如，首次购买日期、首次注册署名和出生日期。
追加/增量-这些属性用于细分和创建相关的个性化用户体验。增量属性可以是购买总量、总收入等。添加（和删除）用户属性使团队能够快速识别他们已经表示感兴趣的促销、新更新和体验的相关用户。例如，例如您已经从中购买的餐厅列表（食品配送）、您最喜欢的商店列表（超本地POI），或用户使用的功能。

行为属性类型

大多数事件都有与它们相关的类型。区分类型对获取可操作数据很重要。一些例子：

骑行已取消：用户发起与系统发起
已选择付款：信用卡与电汇
上传的照片：相机与画廊
登录成功：谷歌对脸书对电子邮件对电话

为了弄清楚我问的问题类型，例如：

谁负责这种转换（或失败）？
什么原因导致了这种转换（或失败）？
这个用户在完成此操作时有哪些偏好？
我如何描述此操作最重要的用户旅程路径？
我还可以使用哪些其他信息来预测此用户基于此操作的未来操作？

上下文属性

上下文属性是那些帮助我理解哪些因素可能会影响用户完成或不完成目标的动机。一些例子：

屏幕上的驱动程序数量
显示的商家类型
搜索结果的编号

我发现有助于发现上下文属性的问题可能包括：

什么因素会影响用户完成目标的动力？
我如何区分动机的增减？
想象一下，这是我们从用户那里跟踪的最后一个事件。关于这次经历，我们想知道什么？