事件数据上下文中的实体是什么?

已发表: 2022-04-29

这是关于客户数据的五部分系列的第三部分。 这是第一部分第二部分 强烈建议在阅读这篇文章之前先阅读第一部分。

事件数据对于破译产品内部正在发生的事情或某事是如何完成的非常有帮助。 但是,除非您知道谁在执行这些事件,否则您在细分和理解用户角色方面无能为力。

这就是实体数据发挥作用的地方,其中User是主要实体,而user_id是需要与每个事件关联的关键属性。 这样做,您可以通过回答以下问题来了解用户行为:

  • 有多少独立用户执行了活动Campaign Sent
  • 哪些用户执行了此事件?
  • 在第一次执行活动Campaign Sent之前,用户细分执行的平均事件数是多少?
  • 在此事件之前,用户段执行了哪些事件?

但这还不是全部。 将事件与正确的实体相关联是个性化的关键——通过上下文应用内体验更好地入职,通过生命周期消息传递参与和激活,将客户排除在获取活动之外,并从处于风险或扩展的帐户中主动联系正确的用户-准备好。

让我们深入挖掘。

一个事件,多个实体

用户是与用户执行的每个事件相关联的主要实体。 但是,当用户是组或帐户(B2B SaaS 产品上下文中的组织工作区)的一部分时,帐户也是需要关联的实体,以便提供有关事件的更多上下文并跟踪帐户中的用户活动(或组)级别。

由于一个帐户包含多个用户,因此将正确的帐户与用户事件相关联有助于了解帐户的整体健康状况并回答重要问题,例如:

  • 激活了多少个帐户?
  • 活跃账户的平均用户数是多少?
  • 多少个帐户包含 X 个或更多用户?

请记住,帐户中用户的集体行为通常有助于激活,而不是单个用户的行为。

因此,由多个用户协作使用的 SaaS 产品需要将多个实体(用户帐户)与每个事件相关联。

如果将帐户称为组织,则在user_id之上,组织ID 需要与事件相关联,以便了解哪个用户执行了事件,以及在哪个组织下。

一个事件,多个实体

例如,如果用户 John Doe 在具有 10 个用户的 Acme Corp 组织使用的项目管理应用程序中创建了一个新项目,则会生成两条重要信息:

  1. John Doe 创建了一个新项目: John Doe执行了Project Created事件
  2. 在 Acme Corp 组织内创建了一个新项目: Project Created事件发生在Acme Corp组织内

未能将事件与组织相关联将导致第二条信息的丢失。此外,与订阅相关的事件(例如Trial StartedTrial EndedSubscription Canceled )发生在组织级别,与任何特定用户无关。

无论此类事件是自动发生的(无法对存档的卡收费)还是由于用户操作,将这些组织级别的事件与组织中的所有用户相关联都会很有帮助。 这可确保您不仅限于与帐户所有者互动,并且在发生此类事件时可以通知帐户中的其他用户。
未能将事件与帐户相关联将阻碍分析和参与工作,因为您将只有与个人用户的行为有关的数据。 此外,稍后将用户事件与正确的组织结合起来要么是不可能的,要么对您的数据工程师来说是一个巨大的痛苦。

如果您的产品允许用户成为多个帐户的一部分,那么这个问题会成倍地加剧。

一个用户,多个帐户

在 SaaS 工具的上下文中,用户与多个帐户相关联是很常见的。 Notion、ClickUp 和 Integromat 是一些流行的工具,它们允许唯一的用户加入或创建多个组织或工作区,每个组织或工作区都有不同的订阅。

这意味着同一个用户在多个帐户下执行事件,但这些事件是不相关的,因为它们不一定发生在同一个帐户或组织下。

一个用户,多个账户

对于允许一个用户成为多个组织的一部分的产品,要跟踪帐户级别的活动,对于每个用户事件,您需要知道在哪个组织下执行事件。 换句话说,正确的organization_id必须与每个事件相关联。

如果不这样做,将导致数据集出现偏差,您可以在其中查看用户在所有帐户中执行的所有事件,但无法知道哪个事件与哪个帐户相关。 这最终将导致糟糕的业务决策以及由错误数据提供支持的客户体验,其结果可能非常有害。

总之,当一个用户属于多个帐户时,您需要隔离在每个帐户下发生的用户活动,以了解帐户级别发生的情况,这对于 B2B SaaS 来说是关键。

不仅仅是一个标识符

实体数据不仅有助于识别用户(执行事件的人)或组织(执行事件的组织),而且还提供有关用户和组织的更多信息。

将实体数据分类到以下存储桶中会很有帮助:

  • 个人身份信息,例如人口统计信息,例如行业、工作角色目标角色
  • 首选项,例如帐户数据,例如指定实体属性是设置事件跟踪过程中的关键步骤,这将在以后的指南中介绍。

    推进实体和事件数据

    考虑实体属性(有助于对用户进行细分)可能会引发新的想法或提出与用户细分相关的查询,例如当用户注册您的产品时会收集哪些数据。

    您是否提出了正确的问题并为用户提供了相关选项? 您是否需要修改这些问题或提出新问题以更好地理解用户角色? 属性的命名约定或每个属性的数据类型如何?

    虽然仔细考虑所有这些微小的细节似乎有点多,但重要的是尽早而不是稍后提出这些问题,以确保您收集到易于分析和采取行动的干净数据。

    您现在知道实体数据在收集事件数据的过程中所扮演的角色,这意味着现在是探索产品分析平台中事件数据是什么样子的好时机。

    自助服务演示