事件數據上下文中的實體是什麼？

這是關於客戶數據的五部分系列的第三部分。 這是第一部分和第二部分。 強烈建議在閱讀這篇文章之前先閱讀第一部分。

事件數據對於破譯產品內部正在發生的事情或某事是如何完成的非常有幫助。 但是，除非您知道誰在執行這些事件，否則您在細分和理解用戶角色方面無能為力。

這就是實體數據發揮作用的地方，其中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 Started 、 Trial Ended和Subscription Canceled ）發生在組織級別，與任何特定用戶無關。

無論此類事件是自動發生的（無法對存檔的卡收費）還是作為用戶操作的結果，將這些組織級別的事件與組織中的所有用戶相關聯都會很有幫助。 這可確保您不僅限於與帳戶所有者互動，並且在發生此類事件時可以通知帳戶中的其他用戶。
未能將事件與帳戶相關聯將阻礙分析和參與工作，因為您將只有與個人用戶的行為有關的數據。 此外，稍後將用戶事件與正確的組織結合起來要么是不可能的，要么對您的數據工程師來說是一個巨大的痛苦。

如果您的產品允許​​用戶成為多個帳戶的一部分，那麼這個問題會成倍地加劇。

一個用戶，多個帳戶

在 SaaS 工具的上下文中，用戶與多個帳戶相關聯是很常見的。 Notion、ClickUp 和 Integromat 是一些流行的工具，它們允許唯一的用戶加入或創建多個組織或工作區，每個組織或工作區都有不同的訂閱。

這意味著同一個用戶在多個帳戶下執行事件，但這些事件是不相關的，因為它們不一定發生在同一個帳戶或組織下。

對於允許一個用戶成為多個組織的一部分的產品，要跟踪帳戶級別的活動，對於每個用戶事件，您需要知道在哪個組織下執行事件。 換句話說，正確的organization_id必須與每個事件相關聯。

如果不這樣做，將導致數據集出現偏差，您可以在其中查看用戶在所有帳戶中執行的所有事件，但無法知道哪個事件與哪個帳戶相關。 這最終將導致糟糕的業務決策以及由錯誤數據提供支持的客戶體驗，其結果可能非常有害。

總之，當一個用戶是多個帳戶的一部分時，您需要隔離在每個帳戶下發生的用戶活動，以了解帳戶級別發生的情況，這對於 B2B SaaS 來說是關鍵。

不僅僅是一個標識符

實體數據不僅有助於識別用戶（執行事件的人）或組織（執行事件的組織），而且還提供有關用戶和組織的更多信息。

將實體數據分類到以下存儲桶中會很有幫助：

• 個人身份信息，例如人口統計信息，例如行業、工作角色和目標等角色
• 首選項，例如帳戶數據，例如指定實體屬性是設置事件跟踪過程中的關鍵步驟，這將在以後的指南中介紹。

  推進實體和事件數據

  考慮實體屬性（有助於對用戶進行細分）可能會引發新的想法或提出與用戶細分相關的查詢，例如當用戶註冊您的產品時會收集哪些數據。

  您是否提出了正確的問題並為用戶提供了相關選項？ 您是否需要修改這些問題或提出新問題以更好地理解用戶角色？ 屬性的命名約定或每個屬性的數據類型如何？

  雖然仔細考慮所有這些微小的細節似乎有點多，但重要的是儘早而不是稍後提出這些問題，以確保您收集到易於分析和採取行動的干淨數據。

  您現在知道實體數據在收集事件數據的過程中所扮演的角色，這意味著現在是探索產品分析平台中事件數據是什麼樣子的好時機。