作者：Crystal Widjaja

翻译：殷之涵

校对：王可汗

一个好的事件跟踪字典是什么样的？

你的字典可能有一套和上述模板不同的字段。但这里提供几个关键点，能使其成为一项能够帮助团队协同的良好资产。

1）简单

字典至少得简单、容易被理解。诸如明确的命名规则，这些是最基本的东西。但真正的考验是，第一次进入公司的人能否通过事件追踪器迅速将事件映射到他们在产品中的行动中去，而不需要阅读每个事件的定义。

2）可操作性

事件追踪器的商业用户需要实现从表格到数据再到决策的过程，而这一过程不需要数据分析师的大量参与——很多时候这被称为正确的全面性水平（comprehensiveness）。追踪的事件太少，所收集信息的完整性不足以支持做出决策；追踪的事件太多，则会让人不知所措。

3）可视化

每一个被追踪的事件都应该有屏幕截图。虽然人们可以用很多不同的方式来解释事件的名称和描述，但视觉上的表现依旧非常重要。

1、商业用户的心态

正如我前面提到的，大多数分析系统的终端用户是商业用户。我们需要建立一些能与这些终端用户产生共鸣的东西，而这意味着将数据和分析过程变得更加人性化。这影响到我们如何选择使用的工具、追踪的事件、如何命名事件、以及需要什么样的属性。上述这些事项值得投入大量的时间，就像我们对一个新产品进行客户研究一样。

为了理解商业用户的心态，我经历了四个层次的问题。对于每个问题，我都提供了一些来自我最近合作的产品的例子，该产品名为Honeydu，提供能让公司免费在线发送和接收****的服务。

1. 业务目标是什么？

业务和执行团队正在优化的关键结果和指标是什么？这些信息的来源是当前和历史上的OKR、季度和年度规划文件、以及董事会的文件。

例子一：到2020年第四季度末，有X个新用户收到/发出****。

例子二：向新用户发送的****中，有X%导致了新用户的注册。

例子三：到2020年第4季度末，有X张周期性****呈现活跃状态。

2. 每个团队的目标是什么？

仅仅是公司层面的目标是不够的。每个团队通常都会有一套目标，层层递进以达到公司层面的指标。为了了解这些目标，你可以寻找每个团队的OKR、与团队领导交谈等。在这里，你既要了解历史上不同时间段的目标，又要了解团队领导对未来不同时期对目标的看法。

例子一：（新用户增长）在前7天内发出2张****。

例子二：（支付整合）85%的新增支付方式被成功验证。

例子三：（NUX）新用户中开始使用****模板的百分比。

3. 围绕这些目标的产品体验是什么？

接下来，对于每个目标，我都会确认并驱动与这些目标相对应的产品体验。重要的是，不仅要确定产品或预订渠道的具体屏幕展示是什么，还要确定可能影响目标或行动体验的背景。例如，在像Uber这样的乘车共享产品中，如果产品体验是预订乘车，那么除了预订乘车的渠道之外，我可能还想了解地图上有多少司机、或者估计的时间是多少。

第一步：有很多不同的因素可能导致Honeydu用户发送他们的第一张****，这些因素就意味着我们的核心行动。我们会问自己以下问题：

当用户选择一个联系人来发送****时、当一个联系人在用户的历史业务列表中可用时还是当他们需要搜索时，他们更有可能成功？

有哪些支持性的操作可以帮助用户创建和发送他们的第一张****？****模板是加快寄送时间的好方法吗?还是先导入他们的联系人更重要？

第二步：下一步是思考那些可能阻碍用户达到我们的目标的经验。在Honeydu的案例中，我会问：为什么一个新用户没有成功创建他们的第一张****？他们是否查看了不同的模板，却没有找到与自己相关的模板？他们是否尝试从头开始创建一个****、却发现回到我们的模板目录太难了？我们的激活用户进行了哪些非激活用户无权执行的操作？

第三步：最后，想象一下，任何事件都可能是我们在产品中跟踪用户的最后一个事件。我们想知道关于这次经历的哪些内容？我们需要知道他们在搜索联系人后是否出现了"无结果"的页面，或者在添加新的支付方式时出现了错误，并根据这些事件的高发程度对用户体验中的问题进行分流。

4. 围绕这些目标和产品体验，我/他们可能想要回答的问题/假设是什么？

接下来，我思考他们（或我）围绕这些目标可能存在哪些问题或假设。同样，我们需要与团队中的相关人员谈谈他们面临哪些问题。但也要通过自己的思考提出问题的假设，并与该团队验证这些问题的重要程度。

例子一：Honeydu上的一个关键目标和产品体验是用户“首次发送****”。我会问这样一个问题，需要发生什么样的体验才能让人愿意给企业发送****？像"用户需要用到一个行业标准模板"或“他们看到业务已经在Honeydu网络中列出”这样的假设，表明我们需要能够被跟踪的经验，以便量化分析并将假设推广至相关性/因果关系。

例子二：通过Honeydu付费的用户越多，我们产生的收入就越多。我们应该跟踪用户在什么时候最可能支付****，问自己 "用户什么时候最可能通过Honeydu支付****？当它今天或者明天到期时？" 通过追踪“支付****成功”这一事件的到期日剩余天数（daysTillDueDate） 属性，我们可以在不过度打扰用户的前提下，为那些没有注意到****到期日的用户提供推送通知和电子邮件提醒服务。

2、是旅程而不是指标

我在前文讨论的关键之一是要在事件中达到正确的抽象水平，其基础是追踪旅程，而不是指标。

虽然我们使用第一步中提到的那些目标作为追踪过程的输入，但仅仅停在那里并不能避开糟糕的事件追踪。糟糕的事件追踪就好像一个人问自己 "我可以用这些指标来计算我所有的OKR吗"，例如，#用户点击注册，#完成订单，注册和完成之间的转换。这样做的问题是，它会带我们走进死胡同——你只能知道"50%的用户注册了"，但却无法知道为什么。

要回答 "为什么？"的问题，你首先需要了解旅程的意图、其成功和失败意味着什么，然后了解旅程中每个事件的背景（我们将在第三步用属性来跟踪）。

举几个简单的例子来说明意图→成功→失败的事件历程。

例子一：

意图。选择了新的付款方式和提交了新的付款细节。

成功。添加新的付款方式 成功。

失败。添加新的付款方式失败。

例子二：

意图：选择创建**** → 开始填写新**** → 搜索联系人。

成功：收件人被添加到****上 → 发送****。

失败：****草稿已保存（默认动作）。

2A-成功事件

我首先思考的是成功事件，一个成功事件是指产品中的一个动作已经成功完成，这些事件源于我在第一步收集的业务目标。成功事件的例子可能包括以下这些：

付款成功

注册成功

发出****

预订完成

为了不过度追踪所有的事情，我用一个问题对每个事件进行压力测试。"如果我确实跟踪了这个，而且99%的用户都做了这个，我会怎么做？它能告诉我什么？" 如果我无法在上述这种极端的情况下找到可操作的东西，那么追踪这个事件很可能是无益的。

2b-意图事件

对于每一个成功的事件，我都会考虑到意图事件。意图事件通常是作为任何成功事件的前驱。跟踪意图事件对于理解事件成功的"原因"至关重要。

意图事件告诉我，用户是如何"被教育"和"被激励"来完成我希望他们完成的行动的某个步骤的。每件事实际上都是其下一个事件的意图事件——但我们往往只把它们当作 "目标"，这使我们无法准确地跟踪它们。例如，在一个搭车应用中，选择目的地是一个目标，但需要一个“选择搭车类型”的意图/设置事件（在旧的Lyft/Uber流程中）。然后，预订实际的旅程成为目标，但需要从搜索/历史中找到目的地的意图/设置事件等。

为了找到意图事件，我会问：为了完成成功事件，我必须完成哪些步骤？常见的例子如下：

在我们的第一个旅程例子中，我们注意到了"选择添加新的付款方式"和"提交新的付款细节"的意图事件。

请注意，我们在这里有两个级别的意图——高的意图，即用户主动提交他们的付款细节；以及低的、但具有指示性的意图，即用户正在选择是否通过****或****添加他们的支付详情。这些事件之间的延迟会导致团队采取可操作的后续步骤:用户要么觉得要输入的字段太多太麻烦，要么当时手头上并没有这些信息。我们既然知道他们是否选择了****或****支付方式，那么就可以提供更多的信息和个性化的内容，帮助用户完成这一步骤。

我还使用 "意图事件 "来确定用户在完成一个动作时的自然路径。例如，在我们的****和账单支付应用中，用户是先导入联系人，还是先创建并发送****？随着我们账单支付网络的发展，这种行为是如何变化的？

同样，在Gojek的外卖产品中，早期时我们注意到最“成功”的用户是那些已经知道他们想吃什么的人，他们来Gojek只是为了完成配送服务。这些用户的意图是搜索一个特定的餐馆，找到他们想要的餐品，最后设置他们的收货信息。然而，随着这些用户逐渐成熟，我们注意到最普遍的用户意图旅程发生了变化，用户开始使用Gojek来探索新餐馆，而不是仅仅满足于他们已经知道的餐馆。现在的意图事件是用户浏览他们朋友的美食打卡/测评记录和餐馆折扣，或使用“附近”功能。

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

2c - 失败事件

失败事件是发生在意图事件和成功事件之间的事情，它使用户无法获得“成功”。在意图事件和成功事件之间，存在着一些用户可能遇到的失败路径。理解失败路径对于理解成功路径同样重要，因为它们为我们提供了关于如何改进成功事件的可操作信息。为了找出失败事件，我会问自己：有哪些可能的事情会阻止用户完成目标？有两种类型的失败事件，隐性失败与显性失败。

隐性失败是指在成功完成目标之前的放弃行为。用户就这样从我们的流程中 "消失 "了。在前文的例子二中，事件的跟踪方式提供了两个隐性失败指标。

用户如果执行了 "选择创建****"，但没有在5分钟内执行 "开始新****"，表示激活过程中失败。

用户如果搜索了联系人，但没有在5分钟内将收件人添加到****中，表明我们的搜索结果或搜索历史失败。用户可能觉得没有足够的动力去新建一个联系人，或者没看明白搜索结果。

显性失败是指预期体验出错的事件。

像Lyft的"Ride Cancelled"（取消行程）或在订购食品快递时的"Order Cancelled - Restaurant Closed"（取消订单-餐馆打烊）等事件都是明确失败的例子。

在Honeydu中，"添加新的付款方式失败 "和 "支付****失败 "是两个事件的例子，它们经常在事件追踪工作中被遗忘，因为它们是对用户行为的反应，而不是在产品中采取的实际行动。然而，如果你的网络/移动应用程序收到错误并显示给你的用户，这些应该很容易跟踪和记录，以便监测。将这些错误响应信息存储为事件属性，是快速诊断用户旅程突然失败的原因的简单方法。

3、属性

一旦我们有了成功、意图和失败的事件，下一步就是弄清楚我们想要与事件相关联的属性。属性是实现我们以下两个主要目标的关键——“提供正确的抽象水平”和“使数据可操作”。

属性的本质是我们分割事件的潜在方式。一个典型的错误是把“分割”作为一个事件本身来追踪，例如：

好做法：选定的注册（事件），来源（属性），Facebook（属性值）。

坏做法：选择Facebook为注册方式。

可以把你在第一步中发现的问题和假设作为起点，了解你可能需要跟踪哪些属性，例如：

问题：用户更喜欢以什么样的方式添加联系人？

属性举例：来源→历史/导入/手动输入。

假设：新用户更倾向于使用模板来入门，与选择自定义****的老用户相比，他们需要更多的新手培训才能充分利用****工具。

属性示例：模板名称 → (null)/基础****模板/其他。

我喜欢问自己一些宏观层面的问题来确定哪些才是重要的属性：

我该如何区分那些失望和不感兴趣的用户？

我怎么才能识别成熟用户与临时用户使用APP时的不同路径？

这是否给了我足够细致的数据来比较和对比成功用户和掉线用户?？

如果这是我从一个用户那里追踪到的最后一个事件，我想知道用户在这个屏幕上的体验是什么？

属性往往会落入几个常见的分桶中。为了确保这个流程没有遗漏，我使用以下这些分桶来查看我是否遗漏了什么：

用户档案属性

最常见的属性集是那些与用户基本情况有关的属性。这可能是人口统计学或公司统计学信息，举例如下：

城市

年龄

公司规模

职位

产品层级

通常情况下，上述这些属性几乎能够永久地对用户和事件进行细分（基础信息通常很稳定），直到属性被改变。一些平台（如Mixpanel）会包含一个“超级属性”的功能，可以让你轻松做到这一点，所以关键是要弄清楚哪些属性需要被追踪。可以问如下问题：

如果我是这个用户的个人助理，那么我需要了解他们的哪些偏好，以便为其提供帮助？

哪些人口统计信息可能会影响用户的行为？

营销属性

第二组最常见的属性是那些与营销有关的属性，可能会影响到或影响用户的行为，例如：

来源

活动

进入页面

用户操作动属性

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

首次订单日期。

首次服务类型。

总订单数。

区分以下两种类型的属性很重要：

设置并忘记（Set and Forget）型属性：这些属性一经设置就不再改变。例如首次购买日期、首次注册类型和出生日期。

附加/增加（Append/Increment）型属性：这些是你用来细分和创建相关的、个性化的用户体验的属性，如总购买量、总收入等。添加（和删除）用户属性可以让团队快速识别相关用户的促销活动、信息更新，以及他们已经表示感兴趣的体验。具体地，例如已消费餐厅的列表(外卖)、喜欢/收藏过的商店列表、或用户使用过的功能。

操作属性的类型

大多数事件都有一个与之相关的类型，区分类型对于获得可操作的数据很重要，例如：

取消乘车-用户发起/系统发起。

选择付款-****/电汇。

上传的照片-拍照上传/从相册选择。

登录成功-谷歌/Facebook/电子邮件/手机号。

为了弄清这些类型，我会考虑如下这些问题：

谁应该对这一转换（或失败）负责？

是什么原因导致了这种转换（或失败）？

这个用户在完成这个动作时有什么偏好？

如何描述这个行动的最重要的用户旅程路径？

有哪些额外的信息来预测这个用户基于此行动的未来行动？

情境属性

情景属性是那些可能影响用户是否能完成目标的动机的属性，例如：

屏幕上的司机数量。

显示的商户类型。

搜索结果的数量。

我发现有助于发现情景属性的问题可能包括：

什么会影响用户完成目标的积极性？

我怎样才能区分动机的增加或减少？

想象一下，这是我们从用户那里追踪到的最后一个事件，那么关于这次经历我们想要了解些什么？

4、压力测试

一旦你定义了你的一组事件和属性，你应该对理解和可操作性进行压力测试。

测试理解程度

一个事件或属性对我们来说可能是有意义的，但问题是它对你的最终受众有意义吗？如果人们不理解基础知识（比如“事件”是什么），那么实际的分析就无从谈起。这里的关键是，你应该和商业用户而非开发者的达成共识。

在Gojek，一开始所有的东西都是由移动应用开发者构建的。他们为我们的移动应用程序创建了事件名称，如"注册处理程序（Signup Handler）"或"缓存结果反馈（Cached Result Feed）"。这些事件命名方式对他们来说很合理，但对商业用户来说却是十分陌生的语言。由于其晦涩难懂，因此没有人愿意使用我们的分析工具。

为了便于理解，我建议测试以下几个受众:

1. 接近产品开发的商业用户

你应该测试的第一个群体是接近产品开发的商业用户——通常是产品经理。那些接近产品开发的人往往对产品的工作原理有更多的了解。因此，如果他们都不太理解产品的使用逻辑，那么那些对产品了解更少的人就更难以理解了。

2. 离产品开发较远的商业用户

下一个群体是离产品开发较远的商业用户——通常是市场营销人员或客户支持人员。他们通常对产品的工作原理没有那么细致的了解，但应该能够理解所有的事件和属性意味着什么。

3. 新员工

下一个群体是新员工。新员工还没有习惯于公司的内部术语或特定缩写，但我们希望这些新员工能够在没有大量实践培训的情况下理解事件和数据。

在Gojek，我为用户搭建了一个"快速测试"，以获得对我们分析工具的访问。如果用户无法"通过"测验，这就意味着我们的事件跟踪十分混乱。因此，我建议如果能把新员工的"入职测试"换成"内部事件工具产品测试"就再好不过了!

在任何情况下，如果你发现一些让终端用户感到困惑的东西，只需一个简单的问题就可以帮助你找到合适的命名办法，那就是 "当客户在[产品的某个部分]上[做某个动作]时，你会怎么填入方括号中的内容？"

测试可操作性

了解数据只是第一步，我们仍需要对数据是否可操作进行压力测试。在这里，我们应该回顾一下第一步中生成的“问题和假设”清单，选择其中的一个样本，并就我们可能如何回答这些问题和假设进行压力测试。

在Gojek，产品、运营、财务和研究团队共同提出的一个问题是："是什么让一个司机变成了一个[最好的/最快乐的/最具生产力的]司机？"这里的关键是，对于财务团队和司机福利团队来说，“快乐”的定义是不一样的；同理，对于运输团队和视频配送团队来说，“最具生产力”的定义也是不一样的。

因此，我们需要测试这些团队和用例的可操作性，提出我们如何从不同角度分析问题的不同假设。我们是否可以将司机分成易于常人理解的群体，如五星级司机、长途司机，或者按服务类型划分等。

5、追踪 "没有数据而做出的决策"

无论你关于上述过程的工作做得有多详尽，总会有一些变化需要额外工作来应对。业务、目标和产品都在不断变化、产生新的需求。你永远无法预料到所有需要回答的问题和假设。

我建议数据团队定期进行一项简单的练习——"无数据决策"。每个季度，我们都会把更多的团队在没有数据的情况下所做的决策列出来。

例如，在Gojek的时候，“更快地支付给司机是否能促进司机留存”是我们所关注的一个问题。当时，我们并没有跟踪合适的数据来回答这个问题，因此有人根据自己的直觉和推理得出了相关论证以支撑决策。发现这个没有数据支撑的决策后，我们开始追踪一些新的数据，这样我们就能确认支付速度确实能促进司机留存，并围绕它制定具体的产品和营销措施。

这个练习可以帮助你发现那些被你忽略的、没有预料到的、或在业务中改变的东西。要明确的是，我并不是说一切决策都必须在有数据的情况下才能被做出。任何快速发展的公司都面临一个现实——有些决策就是需要在没有数据的情况下被做出。但是，这个清单有助于我们发现“缺乏数据支撑”的情况，而这些数据本可以对关键决策有所帮助。

成功的持续信号

在一个组织中创建一个优秀的数据系统需要持续迭代的努力。当你在内部工具和系统上工作时，你的客户是另一组员工而不是公司的最终客户，此时并没有收入或其他指标的直观反馈来告诉你，你做得算是糟糕、良好还是优秀。下面列出的一些信号将有助于你了解事情的进展：

糟糕信号

只有一个人知道如何进行数据追踪——没有人知道如何编写事件规范。

即使是非常基本的分析也需要数据分析师亲自进行。

事件名称和属性名称出现多处重复（例如，Sign up和Sign Up）。

每季度的非数据驱动型决策的数量不断增加。

分析工具的使用率很低。

当新的功能和产品被添加时，事件追踪并没有更新以反映新的路径。

出现了违反逻辑的漏斗数据（例如，做步骤2的用户比做步骤1的还多） 。 

良好信号

很多团队都在使用事件追踪表和分析工具（要像追踪你的产品使用情况那样追踪分析工具的使用情况）。

其他团队也为分析工具做出了贡献，并努力跟上产品的新进展。

随着应用中新功能、新方法的实现，事件追踪表也被同步更新。

对于业务团队来说，相比写交易相关的查询，在分析平台上直接提取数据更易于寻找问题的答案。

优秀信号

事件追踪被嵌入到你的常规目标设置中，以确保各团队拥有合适的信息。

离开发过程更远的团队（例如最远端的客户支持团队）也经常使用这些工具，同时不需要经过大量的培训。

即使产品出现了重大的改版，事件追踪也能沿用原有的事件名称和属性逻辑。

团队可以将资金投入其中——可以信任事件跟踪来细分用户并分配用户奖励(如推荐、折扣、促销)。

本文作者Crystal Widjaja是东南亚最大的超级应用之一Gojek的前增长和商业智能高级副总裁。Crystal帮助Gojek从每天2万份订单扩大到500万份。

原文标题：

Why Most Analytics Efforts Fail

原文链接：

https://www.reforge.com/blog/why-most-analytics-efforts-fail

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。