本帖由东南亚最大的超级应用程序之一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、红杉投资组合公司和其他公司等初创企业在迷宫中导航。
除了所有工具外，还有一个基础的事情可以促成或破坏公司内部的任何数据倡议：您如何思考跟踪什么，如何跟踪它，以及如何随着时间的推移对其进行管理。
如果你把这些原则方法弄错了，世界上最好的工具不会拯救你。
在本帖中，我分析了：
大多数公司可能会将自己的数据描述为“混乱”。当他们这么说时，他们通常指的是少数常见症状之一：
缺乏领域共享通用统一语言：
在应用程序中描述相同体验的方法有很多。如果您问您的团队“用户如何结账？”——在许多情况下，没有人会使用相同的术语说出相同的步骤集。
当应用程序中有多种方法做同样的事情时，或者当导航选项卡是未命名的图标时，这主要是个问题。例如定价页面可以是定价概览或详细定价。是描述文件还是帐户设置？这些听起来可能相同，但在许多产品中有所不同。
缺乏共享语言开始使数据变得无用。与其他团队就数据进行深思熟虑的讨论或对数据的实际含义达成共识需要花费更多时间。更糟糕的是，当团队真的不理解时，他们可能会认为他们有一个共同的理解。这种摩擦通常会导致沮丧和完全避免使用数据。
上述挑战在于它们只是症状。许多团队试图通过以下方法解决症状：
但通常，这些事情可能会浪费时间和金钱，因为你没有解决根本原因和实际问题。相反，根本原因通常源于以下一个或多个：
了解它们对于成功团队和失败团队分开很重要，所以让我们单独检查每个团队。
许多团队认为，数据分析的目标是跟踪指标。然而，真正的数据分析目标是分析这些指标。
这两件事非常不同。
后者是我们如何使信息可操作。使信息可操作性不是报告做某事的人数，而是我们如何区分成功人士和失败者在我们的产品中做什么，以便我们能够采取措施进行改进。这种细微差别通常会消失，但正如您将看到的那样，我们如何处理跟踪的内容和跟踪它的方式发生了根本变化。
跟踪最难做的事情之一是正确地抽象了跟踪的内容。糟糕的跟踪是指当我们的领域或界面事件过于抽象宽泛具有普遍性，良好的跟踪是指当我们的领域或界面事件比较具体，出色的领域或界面事件设计是指当我们平衡这两者。
让我们考虑一个常见的用户注册事件。
通过设计事件字典统一领域语言：
事件跟踪词典中的字段属性有专门规定，像一部字典一样，字典中的基础字段是：
团队拓扑与产品管理：
大多数分析系统的最终用户都是业务用户。我们需要构建一些与该最终用户产生共鸣的东西。这意味着使数据和分析过程人性化。这会影响我们如何选择要使用的工具、要跟踪的事件、如何命名事件以及需要什么属性。在这里花费有意义的时间是值得的，就像我们在新产品的客户研究中一样。
为了进入业务用户的心态，我经历了四个层次的问题。对于每个问题，我都提供了我最近合作过的一个名为Honeydu的产品中的一些示例，Honeydu是公司在线免费发送和接收发票的一种方式。
第2步：下一步是思考可能阻止用户实现我们的目标和目的的经验。在Honeydu的案例中，我会问：为什么新用户没有成功创建他们的第一张发票？他们是否查看了不同的模板，但没有找到与他们相关的模板？他们是否尝试从头开始创建发票，发现回到我们的模板目录太难了？我们已激活的用户执行了哪些操作，而未激活的用户没有执行？
第3步：最后，想象一下，任何事件都可能是我们在产品中从用户那里跟踪的最后一个事件。关于这次经历，我们想知道什么？我们需要知道他们在联系搜索后是否获得了“未找到结果”页面，或者在添加新付款方式时出错，并利用这些活动的受欢迎程度开始对我们用户体验中的问题进行分类诊断。
下面是几个快速示例显示了意图→成功→失败的事件旅程：
2A - 成功事件
我首先仔细考虑成功事件。成功事件是指产品中的操作已成功完成。这些事件源于我在第一步中收集的业务目标。成功事件的示例可能包括：
为了不过度跟踪所有内容，我用一个问题对每个事件进行压力测试。“想象一下，我确实跟踪了这个，99%的用户做到了，我会怎么做？它告诉我什么？”如果我无法找到可以极端操作的东西，那么这个事件可能没有帮助。
2B - 意向性事件
然后，对于每个成功事件，我都会仔细考虑意图事件。意向性事件通常是任何成功事件的前身所需的一步。跟踪意向事件对于理解围绕成功事件的“原因”至关重要。
意向事件告诉我，用户如何“受过教育”和“有动力”完成我希望他们完成的操作的一些步骤。实际上，一切都是下一个事件的故意事件——但我们通常只认为它们是“目标”，这阻碍了我们准确跟踪它们。例如，在骑行共享应用程序中，选择目的地是一个目标，但需要选择骑行类型的意图/设置事件（在旧的Lyft/Uber流程中）。然后，预订某个骑行成为目标，但需要从搜索/历史等中找到目的地的意图/设置事件......
为了想出有意图的事件，我问——为了完成成功事件，我必须完成哪些步骤？常见的示例包括：
我还使用Intent Events意图事件来识别用户在完成操作时自然采取的路径。例如，使用我们的发票和账单支付应用程序，用户是先导入联系人还是先创建发票来发送发票？随着我们的账单支付网络的增长，这种行为会有什么变化？
同样，在Gojek的食品配送产品中，我们注意到我们最成功的用户是那些已经知道自己想吃什么的人，他们来Gojek只是为了完成送货服务。这些用户的意图是搜索特定的餐厅，找到他们想要的菜单项，最后设置他们的送货详细信息。然而，随着这些用户的成熟，我们注意到，随着用户开始更多地使用Gojek作为发现新餐厅的手段，而不是满足他们已经认识的餐厅，最普遍的用户意向之旅发生了变化。现在，意向性活动包括滚动浏览朋友的食物提要、浏览折扣交易或使用“附近”功能。
这些意向性事件对于理解Bangaly Kaba（Reforge EIR，Instagram前增长主管）所谓的相邻用户至关重要。随着用户的成熟和市场的扩张，这些旅程会随着时间的推移而演变，我们的产品也应该通过匹配新用户的意图和成熟的用户的意图来实现。
2C - 故障事件
失败事件是指发生在意图事件和成功事件之间，阻止用户取得成功。在意图事件和成功事件之间存在许多用户可能会遇到的故障路径。了解失败路径对于理解成功路径同样至关重要，因为它们为我们提供了关于如何改进成功事件的可操作信息。要想出故障事件，我问-哪些可能阻止用户完成目标？有两种类型的故障事件：
3 - 属性
一旦我们成功、意图和失败事件，下一步就是找出我们要与事件关联的属性。属性再次成为实现我们两个主要目标的关键，即提供正确的抽象水平并使数据可操作。
属性本质上是我想分割事件的方式。一个关键错误是将分割跟踪为事件本身。例如：
了解您可能需要跟踪哪些属性的一个关键来源是您在第一步中发现的问题和假设。
我喜欢问一些高级问题，以确定哪些属性很重要：
属性往往落入少数常见的桶之一。为了确保我彻底，我使用这些桶来查看我是否遗漏了什么：
用户配置文件属性
最常见的属性集是与用户配置文件相关的属性集。这可能是人口统计或公司信息。一些例子：
通常情况下，这些都是您希望能够从属性更改之前永久分割用户和事件的东西。一些平台，如Mixpanel，包含超级属性等功能，允许您轻松做到这一点。要问的问题，以弄清楚要跟踪以下哪些属性：
营销属性
第二组最常见的属性是那些可能影响或影响用户行为的与营销相关的属性。这可能包括以下内容：
用户操作属性
另一组属性是与用户操作相关的属性。例如：
在这里，区分两种类型的属性很重要：
行为属性类型
大多数事件都有与它们相关的类型。区分类型对获取可操作数据很重要。一些例子：
为了弄清楚我问的问题类型，例如：
上下文属性
上下文属性是那些帮助我理解哪些因素可能会影响用户完成或不完成目标的动机。一些例子：
我发现有助于发现上下文属性的问题可能包括：
京公网安备 11010802035086号