您需要精益数据分类来扩展自助服务分析

已发表: 2022-08-23

分类设计与产品分析密切相关。 无论您的行业、公司规模、产品组合或数据成熟度如何,如果没有精益分类法,您就无法建立可扩展的产品分析。 当您考虑到大多数公司需要跟踪跨平台和跨产品的用户旅程,并以预测未来场景的方式设置他们的产品分析工具时,这一点尤其重要。

换句话说,从推出产品分析解决方案的那一刻起,您就需要确保您的数据分类不会过时。 请遵循以下关键原则来设置您的产品分析以取得长期成功。

面向未来的产品分析和数据分类的最佳实践

1. 大力投资于您的第一个产品的分类

产品分析是一个团队游戏,它要求您为参与该过程的人员定义明确的角色和职责。 强大的设置需要两个关键角色的参与:

  • 负责定义产品分析需要涵盖的核心用例集的业务主管(通常是产品负责人或副总裁)
  • 技术负责人(通常是高级工程角色),将推动分析实施的技术方面

这两个角色都应该对产品具有跨平台和跨团队的视图,以便能够在产品级别做出决策。 如果有多个产品和工程团队将参与实施,那么这两个角色能够协调团队至关重要。 无论涉及的团队数量如何,这都将确保产品分析的一致性。 让更广泛的领导团队参与进来,通常会为产品分析创造额外的动力和兴奋,并有助于提升公司范围内的工作路线图。

一旦您的团队准备好构建产品分类法,您应该在深入了解细节之前确定您的产品所处的位置。 为此,请仔细考虑产品分析将为您的团队回答的自上而下的问题,例如:

  • 我们产品的基本用户旅程是什么?
    • 用户是否实现了我们期望他们实现的目标?
    • 是否使用了产品的主要功能?
  • 我们的关键漏斗是什么样的?
    • 用户在哪一步下车?
    • 他们试图做什么?
  • 我们的入职转换是什么样的?
    • 有多少人在入职过程中一路走来?
    • 有多少人达到了“啊哈”的时刻?

如果您在团队中对这些基本问题达成共识,您将始终能够扩大产品分析的覆盖范围,并深入研究具有最大潜力的领域(例如不明确的使用路径、最大的下降-关)。

一旦您定义了产品分析的用例,就该定义您的数据分类了。 即,这包括:

  • 活动
  • 事件属性(事件的上下文)
  • 用户属性(用户的上下文)。

您在此阶段的目标是使分类法尽可能精简,并与上述问题保持一致。 根据我们的经验,仅检测 20-30 个事件就足以回答团队一贯提出的大约 90% 的问题。

通常,只有少数事件会为常见的业务问题提供可靠的答案。 这将使您的公司了解真实的(不仅仅是预期的)用户旅程,并获得新的见解,例如:

  • 产品的真实角色
  • 用户旅程中的摩擦点
  • 为什么有些用户转换而其他用户没有
  • 应在下车时刻进行哪些 UI 改进

您可以在 Amplitude 的数据分类手册中了解有关记录事件、事件属性和用户属性的更多信息。 关键点包括保持分类精简、使用一致的命名约定以及在检测事件和属性之间取得适当的平衡。

2. 远离跟踪低级 UI 元素

根据我们在 Amplitude 专业服务团队的经验,跟踪低级和不重要的 UI 元素是不可扩展产品分析的第一标志。 通常,它反映了一种混合了事件和事件属性定义的检测方法。

例如,您的产品团队可能正在下注以改善产品的结帐流程。 当他们在这个赌注上工作时,他们可能会测试一些添加或删除 UI 元素的迭代。 在尝试衡量每个测试的性能时,可能会有一种自然的趋势来跟踪以下事件:

  • 复选框被点击
  • 按钮点击
  • 切换滑动
  • 单击的字段文本

如果您的初始分类充满了上述 UI 元素,那么可能是时候退后一步重新组合了。 是的,团队一直在努力改进结帐流程并一直在调整这些元素,但请记住:此流程的目标仍然是用户能够无缝地通过它。 企业希望在分析中看到的用户旅程可能是“开始结账”→“选择付款方式”→“选择付款详情”→“提交交易”。 这种类型的流程比类似的流程更具信息性和可扩展性:“单击按钮”→“选中复选框”→“单击字段文本”。 如果您在评估步骤之间的转换时仍在寻求粒度,您可以使用两种替代方法来解决这个问题:

  1. 在事件的事件属性中检测 UI 元素。 例如,“Transaction Submitted”事件可以有一个属性来指示用户是否使用复选框、按钮单击或其他 UI 元素执行了该操作。
  2. 使用 A/B 测试来提高掉率较高的步骤的转化率。 例如,如果您在第 1 步和第 2 步之间观察到较高的下降,则使用修改后的 UI 运行 A/B 测试并观察样本上的客观结果通常会更有效,而不是在迭代过程中检测多个元素。

3. 建立与业务成果的联系

最终,您的产品分析设置应揭示您的数字产品如何推动您的业务。

借助完善的数据分类,您的团队可以在用户旅程中探索许多因素,例如:

  • 人物角色
  • 公共路径
  • 发布对关键指标的影响
  • 转换驱动程序
  • 用户旅程
  • 和更多

我们看到,在产品分析方面取得成功的团队总是在他们跟踪的事件、他们所从事的业务以及他们的产品所玩的“参与游戏”之间建立起闭环。

(参与游戏是指您的产品驱动的三个主要“游戏”之一:交易、注意力或生产力。在 Amplitude 的Mastering Engagement剧本中阅读有关这些方法的更多信息。)

例如,如果您的产品属于“生产力游戏”,您可能会有一个很棒的入职漏斗,但这个出色的入职漏斗不足以匹配您的业务目标。 您的产品最终必须实现生产力承诺; 这意味着用户应该返回使用为他们带来价值(生产力)的核心功能。 除了跟踪您的入职流程是否成功,请务必利用产品分析来评估用户如何重复关键操作。

4. 不要一次跟踪所有内容

如今,大多数数字公司都认为跟踪数据是必须的,而科技行业使收集、存储和处理大量数据变得越来越容易。 从产品分析开始并且已经拥有 CDP 或数据仓库的公司通常倾向于跳过分类设计步骤,而只是开始流式传输他们已经收集的所有宝贵数据。

Amplitude 的专业服务实践回到了旧的原则:少即是多。 向您的 Amplitude 用户显示一组 10 个相关且不言自明的事件总是比向只需要了解有多少活跃用户的人显示 600 个事件的列表(通常具有重复且没有关键事件属性)更好。或关键转化率是多少。

驱动自助式可扩展产品分析的精益和简洁分类法完全掌握在您的手中——您的同事将乐于在日常任务中使用这种分析类型。

从一种产品到跨产品分析

提供产品分析的精益初始实施可为每个数字团队解锁洞察力:营销、产品、工程等。 有了这些可靠的洞察力,您还可以将组织拉向以数据为基础的文化。 团队开始从数据瓶颈转向自助分析,并将洞察周期从几周缩短到几分钟。

第一个产品的精益分类为公司的产品分析设定了标准,并允许其他团队效仿。 只有当每个产品都具有与公司希望实现的业务成果相关的完善分类法时,才有可能成功进行跨产品分析。

产品指标 CTA