东南亚最大消费app的商业智能副总裁的BI经验证明:没有业务领域深入挖掘,就得不到大数据分析带来的业绩提升,只会导致大数据杀熟敲诈。
上篇点击标题,本文是续篇,有关领域事件的详细设计,没有良好的DDD设计,就没有良好的大数据结果,就没有良好的数据工程,这也是大多数数据分析都是失败的原因,以下是原文摘要,主要是有关领域事件如何设计的要点,同样适用于事件风暴等DDD战略建模阶段:
下面是几个快速示例显示了意图→成功→失败的事件旅程:
- 示例一
- 意图:添加新付款方式并添加已提交的新付款详细信息
- 成功:添加新付款方式成功
- 失败:添加新付款方式失败
- 示例二
- 意图:创建已选中的发票→新发票已启动→联系人搜索
- 成功:收件人已添加到发票→发票已发送
- 失败:已保存发票草稿(默认操作)
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),或用户使用的功能。
行为属性类型
大多数事件都有与它们相关的类型。区分类型对获取可操作数据很重要。一些例子:
- 骑行已取消:用户发起与系统发起
- 已选择付款:信用卡与电汇
- 上传的照片:相机与画廊
- 登录成功:谷歌对脸书对电子邮件对电话
为了弄清楚我问的问题类型,例如:
- 谁负责这种转换(或失败)?
- 什么原因导致了这种转换(或失败)?
- 这个用户在完成此操作时有哪些偏好?
- 我如何描述此操作最重要的用户旅程路径?
- 我还可以使用哪些其他信息来预测此用户基于此操作的未来操作?
上下文属性
上下文属性是那些帮助我理解哪些因素可能会影响用户完成或不完成目标的动机。一些例子:
- 屏幕上的驱动程序数量
- 显示的商家类型
- 搜索结果的编号
我发现有助于发现上下文属性的问题可能包括:
- 什么因素会影响用户完成目标的动力?
- 我如何区分动机的增减?
- 想象一下,这是我们从用户那里跟踪的最后一个事件。关于这次经历,我们想知道什么?