东南亚最大消费App:大数据分析为什么大多数会失败?

22-02-12 banq

东南亚最大消费app的商业智能副总裁的BI经验证明:没有业务领域深入挖掘,就得不到大数据分析带来的业绩提升,只会导致大数据杀熟敲诈。
本帖由东南亚最大的超级应用程序之一Gojek的前商业智能BI高级副总裁Crystal撰写,本文虽然没有提到DDD领域驱动设计,但是其数据分析的轨迹恰好与DDD、事件风暴等理论概念符合,首先她发现没有DDD统一通用语言,因此她创建了事件字典,这种类似汉语字典的业务本体语言表达,统一了团队业务用词与术语,然后,针对事件提出了抽象和详细的设计意见,虽然这些事件基本是界面相关事件,有可能和“核心业务逻辑”无关,但是也是属于事件风暴领域事件设计范畴,因为所谓“核心业务逻辑”是由领域事件派生出来的,文章中大量有关领域事件设计细节对事件风暴、事件建模等DDD战略分析设计都有帮助,包括事件旅程的追踪和追溯,可以直接落地为事件溯源eventsourcing,以下是摘要,原文点击标题:
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、红杉投资组合公司和其他公司等初创企业在迷宫中导航。
除了所有工具外,还有一个基础的事情可以促成或破坏公司内部的任何数据倡议:您如何思考跟踪什么,如何跟踪它,以及如何随着时间的推移对其进行管理。
如果你把这些原则方法弄错了,世界上最好的工具不会拯救你。
 
在本帖中,我分析了:
  1. 数据症状 - 团队在数据问题方面最常见的症状。
  2. 数据问题的根本原因 - 这些症状的实际根本原因。
  3. 分步流程-我逐步了解如何思考要跟踪的内容,如何跟踪它,以及如何随着时间的推移对其进行管理,并配有事件跟踪器模板,以帮助指导流程。


 
大多数公司可能会将自己的数据描述为“混乱”。当他们这么说时,他们通常指的是少数常见症状之一:
  1. 缺乏共享语言
  2. 知识转让缓慢
  3. 缺乏信任
  4. 无法快速处理数据

缺乏领域共享通用统一语言
在应用程序中描述相同体验的方法有很多。如果您问您的团队“用户如何结账?”——在许多情况下,没有人会使用相同的术语说出相同的步骤集。
当应用程序中有多种方法做同样的事情时,或者当导航选项卡是未命名的图标时,这主要是个问题。例如定价页面可以是定价概览或详细定价。是描述文件还是帐户设置?这些听起来可能相同,但在许多产品中有所不同。
缺乏共享语言开始使数据变得无用。与其他团队就数据进行深思熟虑的讨论或对数据的实际含义达成共识需要花费更多时间。更糟糕的是,当团队真的不理解时,他们可能会认为他们有一个共同的理解。这种摩擦通常会导致沮丧和完全避免使用数据。

 
上述挑战在于它们只是症状。许多团队试图通过以下方法解决症状:
  • 新工具
  • 更好的/更多的培训
  • 要求更高的技术/分析标准来招聘

但通常,这些事情可能会浪费时间和金钱,因为你没有解决根本原因和实际问题。相反,根本原因通常源于以下一个或多个:
  1. 分析指标,而不是如何跟踪指标。
  2. 开发者/数据思维与业务用户思维。
  3. 抽象程度错误。
  4. 仅书面与视觉沟通
  5. 数据作为一个项目与正在进行的倡议

了解它们对于成功团队和失败团队分开很重要,所以让我们单独检查每个团队。
 
许多团队认为,数据分析的目标是跟踪指标。然而,真正的数据分析目标是分析这些指标。
这两件事非常不同。
后者是我们如何使信息可操作。使信息可操作性不是报告做某事的人数,而是我们如何区分成功人士和失败者在我们的产品中做什么,以便我们能够采取措施进行改进。这种细微差别通常会消失,但正如您将看到的那样,我们如何处理跟踪的内容和跟踪它的方式发生了根本变化。
 
跟踪最难做的事情之一是正确地抽象了跟踪的内容。糟糕的跟踪是指当我们的领域或界面事件过于抽象宽泛具有普遍性,良好的跟踪是指当我们的领域或界面事件比较具体,出色的领域或界面事件设计是指当我们平衡这两者。
 

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

   

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

 
团队拓扑与产品管理:
大多数分析系统的最终用户都是业务用户。我们需要构建一些与该最终用户产生共鸣的东西。这意味着使数据和分析过程人性化。这会影响我们如何选择要使用的工具、要跟踪的事件、如何命名事件以及需要什么属性。在这里花费有意义的时间是值得的,就像我们在新产品的客户研究中一样。
为了进入业务用户的心态,我经历了四个层次的问题。对于每个问题,我都提供了我最近合作过的一个名为Honeydu的产品中的一些示例,Honeydu是公司在线免费发送和接收发票的一种方式。
  1. 业务目标和目的是什么?业务和执行团队正在优化哪些关键结果和指标?这些信息的来源将是当前和历史的OKR、季度和年度规划文件以及董事会甲板。示例一:X个新用户在2020年第四季度末之前收到/发送发票示例二:发送给新用户的发票的X%会导致新用户注册示例三:2020年第四季度末活跃的X张经常性发票
  2. 每个团队的目标和目的是什么?公司的高水平目标是不够的。每个团队通常都有一套目标和目的,这些目标和目的可以提升到公司级别的指标。要了解这些目标和目的,您可以找出每个团队的 OKR,与团队领导交谈等。在这里,您想了解他们在历史上的几个时间段时间段,以及团队领导在将来的几个时间段时间里的想法。示例一:(新用户增长)前7天内发送2张发票示例二:(付款集成)85%的新付款方式已成功验证示例三:(NUX)以发票模板开头的新用户百分比
  3. 围绕这些目标和目的,产品体验有哪些?接下来,对于每个目标/目标,我确定与推动这些目标/目标对应的产品体验。重要的是,不仅要识别产品或漏斗的特定屏幕,还要识别可能影响目标或行动的体验背景。例如,在优步这样的拼车产品中,如果产品体验是预订拼车,除了预订拼车的漏斗外,我可能还想知道地图上有多少司机?或者,预计时间是多少?第1步:在Honeydu中,许多不同的因素可能导致用户发送他们的第一张发票,这是我们的核心行动。我们会问自己:
    • 当用户选择要向其发送发票的联系人时,当用户的历史业务列表中有联系人时,或者当他们需要搜索时,他们更有可能成功吗?
    • 哪些支持操作可以帮助用户创建和发送他们的第一张发票?发票模板是加快发送时间的好方法吗?还是更重要的是,他们的联系人首先导入?

第2步:下一步是思考可能阻止用户实现我们的目标和目的的经验。在Honeydu的案例中,我会问:为什么新用户没有成功创建他们的第一张发票?他们是否查看了不同的模板,但没有找到与他们相关的模板?他们是否尝试从头开始创建发票,发现回到我们的模板目录太难了?我们已激活的用户执行了哪些操作,而未激活的用户没有执行?
第3步:最后,想象一下,任何事件都可能是我们在产品中从用户那里跟踪的最后一个事件。关于这次经历,我们想知道什么?我们需要知道他们在联系搜索后是否获得了“未找到结果”页面,或者在添加新付款方式时出错,并利用这些活动的受欢迎程度开始对我们用户体验中的问题进行分类诊断。
  • 我/他们可能想围绕这些目标和产品体验回答哪些问题/假设?
    接下来,我想一想他们(或我)在这些目标或目的周围可能有什么问题或假设。同样,在这里,与团队领导或团队中的个人贡献者讨论他们面临的问题。但也请自己思考,提出问题的假设,并与该团队验证这些问题的重要性水平。
    示例一:Honeydu上的关键目标和产品体验之一是有人发送他们的第一张发票。我想问一个问题,我认为需要哪些经验才能有人对向企业发送发票有信心?像“他们需要使用我们行业批准的模板之一”或“他们看到Honeydu网络中已经列出的业务”这样的假设表明,我们需要能够跟踪经验,以便量化并从假设转向对相关性/因果关系的信心。
    示例二:通过Honeydu支付发票的用户越多,我们产生的收入就越多。我们应该跟踪用户最有可能在什么时候支付发票,问问自己“用户什么时候最有可能通过Honeydu支付发票?今天什么时候到期?明天?”通过跟踪Pay Invoice Success事件上的 daysTillDueDate属性,我们可以为那些没有自然地看到发票到期日而不在自然倾向之外发送垃圾邮件的用户提供信息并构建我们的推送通知和电子邮件策略。


    后续见下:

  • 3
    猜你喜欢