原文链接：https://www.reforge.com/blog/why-most-analytics-efforts-fail

逐步解决大多数事件分析错误的根本因素

当我第一次加入时，“IT”人员正在运行SQL查询。 在第一周内，我意识到其中大多数都不准确，并且大多数人不了解实际数据是什么。 实际上，有人给了我一个便利贴，告诉我如何确定已完成的订单（flag_booking = 2，booking_status = 4）。 没有数据基础架构，所有查询结果都被复制/粘贴到excel报告中，然后通过电子邮件手动发送给主管。

我聘请了3名数据仓库团队成员，实施了一种策略，即使用Pentaho ETL将所有内容放入单个Postgres数据仓库中。但是鉴于我们的规模和增长，这在8个月内变得无用。然后，我们迁移到Google Cloud Platform，并实现了BigQuery，BigTable，Data Flow，Airflow等。

我们还经历了相当一部分的可视化工具的变迁。我们从Tableau开始，然后是Metabase，然后在大约3年的时间移到内部工具。我们的实验平台从手动CSV上传到BigQuery表到更靠近Airbnb ERF的内部系统。

不用说，我在Gojek尽心尽力地研究数据，并且从那以后一直在帮助诸如Carousell，Cashdrop，CRED，Celo，Sequoia投资组合公司之类的初创公司。除了所有工具之外，还有一项基本的事情会影响公司内的任何数据计划，即您如何考虑要跟踪的内容，如何进行跟踪以及如何随时间进行管理。如果您这些东西还不清楚，那么世界上最好的工具也无用。

在这篇文章中，我细分了：

  1. 数据症状——团队在处理数据问题时遇到的最常见症状。
  2. 数据问题的根本原因——这些症状的实际根本原因。
  3. 循序渐进的过程——有关如何思考要跟踪的内容，如何跟踪它以及如何随时间进行管理的逐步过程，并配有事件跟踪器模板来帮助指导过程。

“我们的数据一团糟！”

我协助建议的一个团队认为，他们的入职流程已跟踪了6个月以上，但从未回过头来“使用”和分析数据。 最初这样做的人决定离开公司。团队进行数据调查后，一无所获。 例如，数据表明，更多的人在入职时在界面操作中某操作比单击“注册”要多，这是不可能的。 数据最终无用。

这个故事和我的便利贴故事很普遍。大多数公司可能会将自己的数据描述为“混乱”，当他们这么说时，通常是指以下几种常见症状之一：

  1. 缺乏统一语言
  2. 知识交接障碍
  3. 缺乏信任
  4. 无法快速处理数据

缺乏统一语言

描述应用程序中相同体验的方法有很多种。 如果您问您的团队“用户如何结帐？” ——很少有人会使用相同的术语描述相同的步骤。

当有多种方法可在应用程序中执行相同操作或“导航”标签为未命名图标时，这通常是一个问题。例如，定价页面可以是概览定价或明细定价。个人页面是个人资料还是帐户设置？这些听起来像是同一件事，但是在许多产品中却有所不同。

缺乏统一语言会开始使数据无用。与其他团队就数据进行深入讨论或对数据实际含义达成共识需要花费更多的时间。更糟糕的是，团队可能会认为自己确实没有共识。这种摩擦通常会导致挫败感，甚至完全避免使用数据。
**

知识交接障碍

新人加入团队，现有人员更换团队，或其他人离开公司。每当这些事情之一发生时，就需要在该同志“走人”之前进行知识的转移。在这样的环境中，通常每18个月要有人更换工作，甚至要更频繁地更换团队，这时知识交接就成为关键。

许多团队通过大量的入门和培训来弥补不良数据产品的不足，但这最终只能是隔靴搔痒。这与尝试通过大量的入门，解释和客户培训来补偿真正的不良产品是一样的。随着时间的流逝，它变得成本昂贵且无效。

对于内部员工和培训来说更是如此。团队成员希望把时间花在完成工作上，而不是进行无休止的培训。

缺乏信任

在查看或显示数据时，您会获得多少次“是真的吗？” 大多数数据的常见症状是组织中的人们只是不信任它。 有时，这源于不良数据，但也可能源于人们误解了某个事件或财产的含义。

无法快速处理数据

所有这些阶梯上升到一种宏观症状——无法快速处理数据。在每个季度的OKR和快速变化的竞争性市场中，团队总是会受到时间和资源的限制。如果要在花很多时间来获取他们信任和可以理解的数据，以及跳过这一步以继续前进中进行权衡，很多团队就会选择后者。

根源

上面的挑战仅仅是症状。许多团队尝试通过以下方式解决症状：

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

但是通常这些事情会浪费更多时间和金钱，因为您没有解决根本原因和实际问题。而根本原因通常是以下一种或多种原因：

  1. 以跟踪指标为目标 vs 分析它们
  2. 开发人员/数据心态 vs 业务用户心态
  3. 错误的抽象级别
  4. 只书写 vs 视觉交流
  5. 数据作为项目 vs 正在进行的举措

了解他们对于团队的成败至关重要，因此让我们逐一逐一介绍一下。

以跟踪指标为目标 vs 分析它们

许多团队认为数据举措的目标是跟踪指标。不过，真正的目标是分析这些指标。这两件事是非常不同的。后者是我们如何使信息具有可行性。使信息具有可行性不是要报告做某事的人数，而是要如何区分产品中成功人士和失败人员的行为，以便我们可以采取措施进行改进。这种细微差别通常会丢失，但是正如您将看到的，从根本上改变了我们处理跟踪方式和跟踪方式的方式。

译者评：其实就是不要仅仅停留在描述性分析

开发人员/数据心态 vs 业务用户心态

构建任何优质产品的核心原则是对目标用户/客户的深刻理解和共情。在构建数据系统时，许多团队会忽略他们的客户是谁，或者根本不考虑客户——业务用户。

建立出色的分析系统首先要深刻理解业务的用户痛点，问题和能力，就像您对产品的目标客户一样。在Gojek，关键之一是我们大多数业务用户都不是SQL分析人员。相反，他们是非技术产品经理，营销人员或运营经理。

我们把他们当做最终客户进行了专门打造，以实现数据和分析流程的人性化。这影响了我们如何思考一切，从使用哪种工具，跟踪哪些事件，如何命名这些事件，到需要什么属性。

与我们在深入思考如何对产品中面向用户的功能或导航命名，以保持清晰和易用性一样，我们需要仔细考虑如何为分析产品中的事件，属性等命名。

对我们而言，这是真正的考验——我们的运营/客服团队中的某人是否可以访问事件跟踪工具和UI平台并独立使用它，而无需进行完整的入门培训？运营/客服团队在市场上受教育程度最低，并且离产品开发过程最远。如果他们能够分析问题，那么团队的其他成员也可能也会分析。

错误的抽象级别

要进行有效跟踪，最困难的事情之一就是确定要跟踪对象的正确抽象级别。糟糕的（Bad）跟踪是当我们的事件过于宽泛时，一般的（OK）跟踪是当我们的事件过于具体时，而好的（Great）跟踪则是我们在两者之间取得了平衡。让我们看一个例子：
image.png
举个栗子🌰，注册。

  • （Bad）“ Facebook注册”或“ Google注册”——在这种情况下，我们根据“源”将事件命名为“ Facebook注册”和“ Google注册”。但是它太宽泛了。这是否意味着已选择一种注册方法？注册成功完成？如果尝试注册但失败怎么办？仅查看事件的名称，我不知道任何这些问题的答案。另外，如果我想知道发生了多少这些注册，则需要单独添加所有这些独特的事件，从而使任何潜在的分析对于任何PM来说都是乏味且令人望而却步的。
  • （OK）“已点击注册”——在这种情况下，我们对事件非常具体。在这里，我至少知道事件发生时的确切含义。挑战将在于我是否要查看所选的所有注册来源。我不知道存在什么来源，因此很难做出实际的决定。虽然我们通过事件具有行为的“症状”，但我们无法通过参数值“诊断”。
  • （Great）“已选择注册”——在此示例中，我们具有正确的抽象级别。该事件很明显，已经选择了一种注册方法，并且对源事件具有相应属性，因此可以根据需要按某种方法进行细分。

为了使这种情况更加复杂，我经常发现团队将不同级别的抽象混合在一起。或者，因为用户行径和重新设计不可避免地引导新产品的流向，随着时间的流逝，抽象与实现的不同“时代”发生冲突。这使系统更加混乱，难以理解。我们将在逐步过程中详细讨论如何达到正确的抽象级别。

只书写 vs 视觉交流

共享有关分析事件的含义和含义的“真相”是至关重要的。不良数据团队不会有任何类型的事件字典或书面文档来跟踪所追踪的内容，而由团队自行决定和解释。好的团队至少将拥有一个共享字典，该字典会进行一致性更新。但是优秀的团队将视觉交流与书面文字相结合。

无论我们如何命名或定义事件和属性，没有什么比与事件相对应的视觉（如截图）更为清晰。 当您讨论事件，用户行径或其他数据时，人们会在头脑中可视化相应产品的屏幕和部件。通过使其清晰可见来简化此过程。正如我将在后面展示的那样，我有两种思考方式：第一，包括事件触发时产品中发生的情况的屏幕截图。 第二，将事件映射到客户旅程的视觉表示。

数据作为项目 vs 核心举措

最后但并非最不重要的一点是，将数据视为项目而不是正在进行的核心举措。您必须将数据系统视为不断迭代的产品。随着时间的流逝，您的产品将会改变，您的目标也会改变，并且业务也会改变。如果您不经常迭代，结果就会导致Brian Balfour所说的死亡数据轮：
image.png
source: brianbalfour.com

步骤

工具——事件跟踪字典

在我们深入到流程的各个步骤之前，关键之一是要有一个“工具”来帮助组织，调整和传达决策。为此，我使用了事件跟踪字典，该字典定义了我们正在跟踪的数据及其重要方面。共同执行此规范的过程将在团队和产品的不同部分之间创建共享的上下文和语言。

我们提供了模板以及示例，您可以在此处获得：
image.png

事件跟踪字典中的字段

字典中的基线字段是：

  • 事件名称——调用的动作。以特定的词组命名，高级用户可能会用这些词组来描述他们的行为
  • 在……情况下触发——特定的API响应，用户操作或事件，充当此事件的快照，并将其属性发送到我们的日志
  • 屏幕——屏幕截图或图像，用于说明触发操作时用户所在的位置
  • 属性——将与此事件一起跟踪的属性名称列表（例如源，isLoggedIn）
  • 属性值示例——详尽完成后的最佳值，属于上述每个属性下的潜在值列表。如果潜在值集有限（例如潜在的注册来源，如Facebook，Email，Google），则最好在此处列出
  • 数据/属性类型——每个属性都应限制为一种数据类型，例如布尔，字符串，数字，纬度和经度或浮点数
  • 描述——您如何描述此事件被以前从未使用过的人捕获？使用此字段可以消除将来使用此业务的业务团队与实施这些规范的工程团队之间可能出现的错位情况
  • 技术注释——OAuth，API和内部服务可以具有自己的怪癖，您需要在此处进行详细说明。诸如将2XX响应汇总到单个“成功”值之类的规范可以在这里进行
  • 测试注释——这是一个生动的文档。发行新功能时，最好通过质量检查并确保在必要时触发事件。在此交流更改和问题可以快速解决问题

一个好的事件跟踪字典是怎样的

您可能具有与模板不同的字段集。但是我需要寻找一些关键因素，这使它与团队保持一致。
**

  1. 简单

字典至少必须简单易懂。诸如清晰的命名约定之类的东西是基础。但是，真正的考验是，首次进入公司的人是否能够查看“事件跟踪器”，并快速将事件映射到他们在产品中的动作，而无需阅读每个事件的定义。

  1. 可行的

事件跟踪器的业务用户需要能够从工作表（sheet）转移到数据再到决策，而无需数据分析师的大量参与。很多时候，这归结为正确的综合水平。跟踪的事件太少，您将无法获得完整的信息来做出决定。跟踪了太多事件，则会太过。

  1. 视觉呈现

跟踪的每个事件都应具有屏幕截图。人们可以用许多不同的方式来解释事件的名称和描述，但屏幕的视觉表现最终变得更加具体和清晰。

一、业务用户的心态

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

要了解业务用户的心态，我要解决四个级别的问题。对于每个问题，我都提供了一些示例，这些示例来自于我最近与Honeydu合作使用的产品，这是公司免费在线发送和接收发票的一种方式。

1. 业务目标是什么？

业务和执行团队正在优化的主要结果和指标是什么？该信息的来源将是OKR的当前和历史记录，季度和年度计划文件以及面板（board decks）。

示例一：到2020年第四季度末，有X个新用户接收/发送发票

示例二：发送给新用户的发票中有X％导致新用户注册

示例三：到2020年第四季度末，有X张定期发票有效

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

公司的高层目标还不够。每个团队通常都会有一系列达到公司级别指标的目标。要了解这些目标，您可以找出每个团队的OKR，与团队负责人等等。在这里，您既要了解他们在过去一段时间内的状况，又要了解他们在一段时间内的想法未来的时间段。

示例一：（新用户增长）在前7天内发送了2张发票

示例二：（付款集成）已成功验证添加的85％的新付款方式

示例三：以发票模板开头的（NUX）新用户百分比

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

接下来，针对每个目标，我将识别与实现这些目标相对应的产品体验。重要的是，不仅要识别产品或渠道的具体界面，而且要识别可能影响目标或行动的体验背景。例如，在Uber这样的乘车共享产品中，如果产品体验是在预订乘车，除了预订乘车的渠道外，我可能还想了解地图上有多少位驾驶员？或者，估计时间是多少？

步骤1：在Honeydu中，许多不同的因素可能导致用户发送第一张发票，这是我们的核心行动。我们会问自己：

  • 当用户选择要发送发票的联系人时，如果该联系人在用户的历史业务列表中可用，或者需要搜索时，他们更有可能成功吗？
  • 帮助用户创建和发送第一张发票的支持措施是什么？发票模板是加快发送时间的好方法吗？还是首先导入他们的联系人更重要？

步骤2：下一步是仔细考虑可能会阻止用户达到我们目标的体验。在Honeydu的情况下，我会问：为什么新用户没有成功创建他们的第一张发票？他们是否查看了不同的模板，却没有找到与其相关的模板？他们是否尝试从头开始创建发票并发现很难返回到我们的模板目录？我们的激活用户执行了哪些操作而未激活用户未执行哪些操作？

步骤3：最后，假设任何事件都可能是我们从产品中的用户跟踪到的最后一个事件。我们想知道些什么？我们需要知道在联系人搜索之后是否为他们提供了“未找到结果”页面，或者添加新的付款方式时出现错误，并利用这些事件的普遍性开始对用户体验中的问题进行分类。

4. 我/他们可能希望围绕这些目标和产品体验回答哪些问题/假设？

接下来，我考虑他们（或我）可能对这些目标有什么疑问或假设。同样，在这里，与团队负责人或团队中的个人贡献者讨论他们面临的问题。但是也要仔细思考，提出问题的假设，并与该团队一起验证这些问题的重要性。

示例一：Honeydu的主要目标和产品体验之一是何时发送第一张发票。我想问一个问题，什么才能使某人对将发票发送给企业充满信心？诸如“他们需要使用我们行业认可的模板之一”或“他们看到Honeydu网络中已经列出的业务”之类的假设表示我们需要能够跟踪以量化并从假设转变为对信心的经验。相关性/因果关系。

示例二：通过Honeydu支付发票的用户越多，我们产生的收入就越多。 我们应该跟踪用户最有可能支付发票的时间，并问自己：“用户最有可能通过Honeydu支付发票的时间？今天是何时到期？明天？” 通过跟踪“成功付款发票”事件上的daysTillDueDate属性，我们可以为那些无法自然地看到发票到期日而又不会在其自然倾向之外发送垃圾邮件的用户，通知并构建我们的推送通知和电子邮件策略。

二、行径代替指标

我之前讨论的关键之一是在事件中达到正确的抽象级别。其基础是跟踪行径而不是指标。

虽然我们将第一步中的目标用作跟踪目标的输入，但在目标跟踪中停下来最终会导致糟糕的事件跟踪。糟糕的事件跟踪通常看起来像是某人问自己“我可以使用这些指标来计算我的所有OKR”吗？ 例如，＃用户单击注册，＃完成订单，在注册和已完成之间转换。问题在于这将导致死胡同。您将能够知道“50％的用户已注册”，但不会问“为什么？”

回答“为什么”的问题。您首先需要了解意图，成功和失败的过程，然后是过程中每个事件的上下文（我们将在步骤3中使用属性进行跟踪）。

以下是一些简短的示例，显示了意图→成功→失败的事件过程：

  • 例子一
    • 意图：选择添加新的付款方式并添加已提交的新付款明细
    • 成功：成功添加新的付款方式
    • 失败：添加新的付款方式失败
  • 例子二
    • 意图：创建选定的发票→已开始新发票→联系人搜索
    • 成功：收件人已添加到发票→已发送发票
    • 失败：已保存发票草稿（默认操作）

1. 成功事件

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

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

为了不落伍地跟踪所有事件，我对每个事件进行压力测试并提出问题。 “想象一下，我确实跟踪了，有99％的用户做到了，对此我该怎么办？它告诉我什么？”如果我找不到极端可行的东西，那么该事件可能无济于事。

2. 意图事件

对于每个成功事件，我都会仔细考虑意图事件。意图事件通常是任何成功事件的先决条件。跟踪意图事件对于理解成功事件的“原因”至关重要。

意图事件告诉我用户如何“被指导”和“被激励”来完成我希望他们完成操作的某个步骤。一切实际上都是下一个事件的意图事件，但是我们经常只将它们视为“目标”，这使我们无法准确地跟踪它们。例如，在乘车共享应用中，“选择目的地”是一个目标，但需要选择乘车类型的意图/设置事件（在旧的Lyft/Uber流程中）。然后，预订实际乘车就成为目标，但需要从搜索/历史记录中找到目的地的意图/设置事件……等等。

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

  • 在我们的第一个旅程示例中，我们注意到了“选择添加新付款方式”和“提交新添加付款明细”的意图事件。
    • 请注意，此处我们有两种意图：一种是高意图，即用户正在积极提交其付款详细信息；另一种是低度但具有指示性的意图，即用户选择是通过银行还是信用卡添加其付款详细信息。这些事件之间的中断导致团队可以采取可操作的后续步骤：用户发现输入字段令人生畏，或者当时没有可用的此信息。现在，我们知道他们是否选择了银行或信用卡付款方式，并可以跟进更多信息和个性化内容，以帮助用户完成此步骤。

我还使用意图事件来标识用户在完成操作时自然采用的路径。例如，使用我们的发票和账单支付应用程序，用户是否首先通过导入联系人或首先创建发票来开始发送发票？随着我们的账单支付网络的发展，这种行为将如何改变？

同样，在早期的Gojek的食品配送产品中，我们注意到最成功的用户是那些已经知道自己想吃什么的人，他们只是来Gojek来完成配送服务。这些用户的意图事件是搜索特定的餐厅，找到他们想要的菜单项，最后设置他们的送货详细信息。但是，随着这些用户的成熟，我们注意到最普遍的用户意图行径发生了变化，因为用户开始更多地使用Gojek作为发现新餐厅而不是充实他们已经知道的餐厅的手段。现在，意图事件将是诸如滚动浏览朋友的食物，浏览打折交易或使用“附近”功能之类的事件。

这些意图事件对于理解Bangaly Kaba（Reforge EIR，Instagram的前增长负责人）所说的我们的潜在用户（adjacent users）至关重要。随着用户的成熟和市场的扩展，这些行径会随着时间而发展，我们的产品也应通过匹配新老用户的意图来发展。

3. 失败事件

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

  • 隐性失败是指成功完成目标之前发生的失败。用户只是从我们的行径中“消失”了。在上述两个示例中，事件的跟踪方式提供了两个隐式的失败指标：
    • 在5分钟内执行选定的创建发票但未执行新发票启动的用户表示我们的激活过程失败。
    • 在5分钟内执行“联系人搜索”但未执行“收件人添加到发票”的用户表明我们的搜索结果或搜索历史记录失败。用户可能没有足够的动力从头开始创建联系人或发现令人困惑的结果。
  • 显式失败是指预期的体验出现错误的事件。
    • 订购食品时发生的事件例如Lyft上的“ Ride Cancelled”或“ Order Cancels – Restaurant Closes”是显式失败的示例
    • 在Honeydu中，“添加失败的新付款方式”和“支付发票失败”是事件跟踪练习中经常被遗忘的两个事件示例，因为它们是对用户行为的响应，而不是对产品内部采取的实际操作。但是，如果您的网络/移动应用收到错误并向用户显示错误，则应该易于跟踪和记录这些错误以进行监控。将这些错误响应消息存储为事件属性是一种快速诊断为什么普通用户旅程可能突然失败的简便方法。

三、属性

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

属性本质上是我可能想要细分事件的事物方式。一个关键错误是将细分作为事件本身进行跟踪。例如：

  • 优秀：注册选定的事件（事件），源（属性），Facebook（属性值）
  • 糟糕：已选择Facebook注册

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

  • 问题示例：用户如何选择添加联系人？
    • 属性示例：来源→历史记录/导入/手动输入
  • 假设示例：对于自由职业者来说，新用户更倾向于使用模板来开始使用，并且与选择自己创建发票的用户相比，需要更多的入职才能获得核心价值。
    • 属性示例：templateName→（空）/基本发票/等。

我想问一些进阶问题，以确定哪些属性很重要：

  • 我该如何细分那些沮丧和不感兴趣的用户？
  • 如何确定成熟（mature）用户和休闲（casual）用户使用的不同路径？
  • 这是否给我足够的细微差别的数据来比较和对比成功用户和下线用户？
  • 如果这是我从用户处跟踪到的最后一个事件，那么我想知道有关此屏幕上用户体验的什么？

属性倾向于落入几个常见的桶之一。为了确保自己的状态，我使用以下存储桶来查看是否丢失了任何东西：

用户个人资料属性

最常见的属性集是那些与用户的个人资料相关的属性。这可能是人口统计或公司信息。一些例子：

  • 所在城市
  • 年龄
  • 公司规模
  • 角色
  • 产品层级

通常，您希望这些东西能够永久地分割用户和事件，直到属性被更改为止。诸如Mixpanel之类的某些平台包含诸如超级属性之类的功能，可让您轻松地做到这一点。提出以下问题以找出要跟踪的属性：

  • 如果要成为该用户的个人助理，为了帮助您，我需要了解哪些个人偏好设置？
  • 哪些人口统计信息可能会影响用户的行为？

营销属性

第二组最常见的属性是与营销相关的属性，这些属性可能会改变或影响用户的行为。其中可能包括：

  • 源（Source）
  • 活动（Campaign）
  • 进入页面

用户动作属性

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

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

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

  • 设置和忘记——这些是您一次设置的属性，但之后不会更改。例如“首次购买日期”，“首次注册归因”和“生日”之类的东西。
  • 追加和增加——这些属性可用于细分和创建相关的个性化用户体验。递增的属性可能是诸如“总购买”，“总收入”之类的内容。附加（和删除）用户属性使团队可以快速确定相关用户，以获取他们已经表示有兴趣的促销，新更新和体验。例如，您已经购买过的餐馆列表（外卖），您喜欢的商店列表（超本地POI）或用户使用的功能。

作用类型

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

  • 骑行取消：用户启动与系统启动
  • 选择的付款方式：信用卡与电汇
  • 上传的照片：相机与画廊
  • 登录成功：Google，Facebook，电子邮件，电话

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

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

上下文属性

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

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

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

  • 什么会影响用户完成目标的动力？
  • 我如何区分动机的增加或减少？
  • 想象一下，这是我们有史以来从用户跟踪的最后一个事件。我们想知道些什么？

四、压力测试

一旦定义了事件和属性集，就应该对测试的理解和可操作性施加压力。

1. 测试理解

事件或属性对我们来说可能很有意义，但问题是，这对您的最终受众是否有意义？如果人们不了解事件的本质，那么就不会进行实际的分析。这里的关键是您应该让业务用户而不是开发人员提炼。

在Gojek，我们的移动开发人员首次进行了测试。他们为我们的移动应用程序创建了事件名称，例如“Signup Handler”或“Cached Result Feed”。这些事件对他们来说很有意义，但对业务用户而言却是外语。由于晦涩难懂，没有人使用我们已经实施的任何分析工具。

我建议调研一些观众以了解以下内容：

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

您应该与之测试的第一类是接近产品开发的业务用户。这通常是产品经理。那些更接近产品开发的人倾向于对产品的工作原理有更多的了解。因此，如果事情让他们感到困惑，那么它将使那些知识不足的人感到困惑。

  1. 远离产品开发的业务用户

下一组是远离产品开发的业务用户。这通常是营销人员或客服人员。他们通常不太了解产品的工作原理，但应该能够理解所有事件和属性。

  1. 新职员

新员工还不习惯公司的术语或缩写。最终，您正在寻找这些新员工而无需进行大量培训就能够了解事件和数据。

在Gojek，我实施了一个“快速测验”，供用户访问我们的分析工具。我知道，当用户无法“通过”测验时，我们的事件跟踪开始变得一团糟。因此，我建议人们动摇新员工的“入职和测试”，并用它来测试您的“内部事件检测产品”的质量！

在上述任何一种情况下，如果您发现一些令最终用户感到困惑的东西，那么一个简单的问题便会被问到以启发新的命名：“当客户对此产品的[部分] [采取措施]时，您会称呼什么？ ”

2. 测试操作性

理解数据是第一步，但是我们需要对数据是否可行进行压力测试。在这里，我们应该返回到第一步中生成的问题和假设的列表，选择它们的样本，并压力测试我们如何回答这些问题和假设。

在Gojek，产品，运营，财务和研究团队遇到的一个普遍问题是：“什么因素使[最佳/最幸福/最高效]的驱动程序成为驱动力？”关键是财务上的“快乐”可能与驾驶员福利团队的“快乐”不同。或者，运输团队与送餐团队“最有生产力”的区别。

因此，我们需要提出关于如何从各种角度分析问题的假设，以测试这些团队和用例的可操作性。我们能否将驾驶员分为易于理解的人群，例如五星级驾驶员，长途驾驶员，服务类型等等。

五、跟踪“没有数据的决策”

无论您对上述过程有多彻底的了解，始终都会需要进行更改。业务，目标和产品不断变化，创造了新的需求。您永远无法预料到100％需要回答的问题和假设。

我建议数据团队定期运行的一项练习是我所谓的“无数据决策”。很简单每个季度，我们都会保存更广泛的团队在没有数据的情况下做出的决策清单。

例如，在Gojek时，出现了一个问题，即是否更快地付款给司机，以提高司机的保留率。当时我们没有追踪适当的数据来告知这个问题。有人根据自己的直觉和理智提出了一个门槛。发现没有数据的决策后，我们开始跟踪数据中的一些新事物，以便我们可以确认付款速度确实提高了保留率，并围绕此制定了特定的产品和营销计划。

该练习可帮助您发现您在业务中被忽视，无法预料或发生的事情。明确地说，我并不是说必须在数据可用时才决定一切。任何一家快速发展的公司的现实情况都是，某些决策需要在没有数据的情况下做出。但是，该列表有助于发现我们缺少可能对关键决策有用的数据的情况。

持续的成功信号

在组织中创建出色的数据系统始终是不断进行的迭代工作。当您在内部工具和系统上工作时，您的客户是另一组员工，而不是公司的最终客户，那么您就没有收入或其他指标的内在反馈，无法告诉您您做的是坏事，好事，或出色的工作。您可以使用以下信号来了解事情的进展：

糟糕的信号：

  • 只有一个人知道如何进行跟踪——没有人知道如何自己编写事件规范
  • 需要数据分析师对关键目标进行基本分析吗？事件名称和属性名称是否在多个框中重复（例如注册和注册）？
  • 每个季度没有数据的决策数量在增长
  • 分析工具的使用率低
  • 添加新功能和产品后，事件跟踪不会更新以反映新路径
  • 从逻辑上讲，渠道数据是不可能的（例如，执行步骤2的用户多于步骤1）

良好的信号：

  • 许多团队正在使用事件跟踪表和分析工具（像跟踪产品的使用一样跟踪工具的使用情况）
  • 其他团队正在贡献并试图跟踪产品开发的新部分
  • 随着应用中新功能/工作方式的实现，事件跟踪器也会更新
  • 对于业务团队来说，从分析平台提取数据比编写事务性查询来找到问题的答案要容易得多。

出色的信号：

  • 事件跟踪已嵌入您的常规目标和目标设置中，以确保团队拥有适当的信息。
  • 越来越远离开发过程的团队（即客户支持）正在定期使用该工具，而没有大量的详细培训。
  • 即使产品进行了重大的重新设计，事件跟踪也能够利用原始事件名称和属性逻辑。
  • 团队可以投入资金——可以信任事件跟踪以细分用户并分配用户激励措施（例如推荐，折扣，促销）。