事件數據的組成部分是什麼？

這是關於客戶數據的五部分系列的第四部分。 以下是第一、二、三部分。

客戶數據包括事件數據和實體數據——如果您已經閱讀過第一部分（什麼是客戶數據？），您已經知道這一點。

在本指南中，您將了解事件數據的組件、定義事件的首選命名約定、實體數據的類別以及兩種主要的實體類型。

事件數據

既然您可能已經在網上購買過東西，那麼讓我們從一個電子商務示例開始。

與電子商務應用程序（網絡或移動）交互時，您通常通過將產品添加到購物車、進行結帳和完成付款來購買產品——這些是您在完成購買商品過程中執行的事件應用程序。

然而，買家旅程並不是那麼簡單，還可能發生其他一些事件，例如：

• 產品被查看
• 購物車已查看
• 產品從購物車中移除
• 已應用優惠券
• 選擇了一個地址
• 選擇了一種付款方式
• 訂單完成

等等。

立即想到添加到購物車、進行結帳和付款等常見事件，但要了解用戶行為，還需要跟踪上述其他事件。

確定要跟踪哪些事件並使用適當的命名約定命名事件是收集事件數據過程中的前兩個步驟。

接下來的兩個步驟是什麼？

很高興你問！

每個事件都伴隨著事件屬性（或事件屬性），這些屬性提供了有關事件的更多上下文。 確定與事件關聯的屬性並命名這些屬性是收集事件數據過程中的接下來的兩個步驟。

名字裡有什麼？

談到數據，一切。

正確的命名約定或分類法可以使好數據從壞數據中脫穎而出，並使利益相關者能夠了解他們正在查看的內容。 另一方面，不維護標準化分類法是導致數據集因冗餘而傾斜或膨脹的主要原因之一。

此外，在處理客戶數據時，在命名事件和事件屬性時不保持統一的大小寫是您可能犯的最大錯誤之一——可能會產生長期影響。 一個好的命名約定應該始終伴隨著嚴格的大小寫指南。

原因如下：

添加到購物車、added_to_cart、productAdded、添加到購物車、添加到購物車、產品添加是定義同一事件的不同方式。

雖然這些本身都沒有錯，並且在命名事件和屬性時沒有固定的規則，但應該考慮遵循一些最佳實踐。

對象-動作命名約定幾乎已成為行業標準，並且有充分的理由——它清楚地描述了已經發生的動作。 產品添加絕對意味著一個對象（產品）後面跟著一個動作（添加）。

了解有關為您的活動設置一致分類的更多信息。

事件數據的組成部分

事件有兩個關鍵組成部分——實體（一個或多個）和事件屬性。

將諸如user_id之類的實體數據與事件相關聯可提供有關執行該事件的用戶的信息。

在沒有像user_id這樣的唯一標識符的情況下，事件數據將保持匿名，並且無法知道誰執行了所述事件。 同樣，在 B2B SaaS 的上下文中，用戶可能是多個組織的一部分， organization_id需要與事件相關聯，以了解事件發生的位置。

除了實體之外，還可以收集其他信息，以便在事件發生時進行分析和分割。

回到電子商務的例子，當一個產品被購買時，除了知道誰購買了，最起碼你還需要知道什麼產品是什麼價格，什麼時候購買的。

這些附加信息以事件屬性的形式收集。

在本系列的第一部分中，提到了事件數據包含三個關鍵元素：

• 發生的動作或事件
• 事件發生的時間戳或準確日期和時間
• 與事件相關的狀態或所有其他屬性（稱為事件屬性）

讓我們看一下Product added事件（根據事件Add to Cart的對象-操作框架的正確案例名稱），並假設它是由用戶在2020 年 1 月 1 日上午 10 點 UTC 執行的。 事件發生時收集的數據包括以下內容：

• 行動：添加產品
• 時間戳： 1577872800 （ ABZ 7.99 ( 狀態： 0123 ABZ 7.99 （2 根據此示例，與事件Product added 關聯的屬性是user_id、product_id、price和quantity ，每個屬性都提供有關事件的更多信息。 時間戳與事件相關聯以了解它何時發生。

  為本質上是事件屬性的時間戳指定名稱也很有用。 這樣做不是強制性的，因為標準做法是在向第三方工具發送數據時將時間戳作為時間戳與每個事件相關聯； 但是，從長遠來看，當您需要處理歷史事件數據時，為存儲時間戳的屬性指定一個不同的名稱會很有幫助。

  時間戳的推薦分類是事件名稱後跟“at”： product_added_at事件產品添加。

  您可能已經註意到， snake_case被用於定義事件屬性，這使得區分事件名稱和事件屬性變得容易。 也就是說，請記住這裡沒有預定義的規則，您應該選擇最適合您和您的團隊的規則。

  下面是與事件 Product added 關聯的屬性以及每個屬性的數據類型的最終視圖：

  

  為每個屬性指定數據類型可確保數據的一致性並使檢測過程更容易。

  旁注：最好記住現在應該清楚，收集事件數據包括以下步驟：

  • 確定要跟踪的事件
  • 使用適當的命名約定命名這些事件
  • 決定與每個事件關聯的屬性
  • 使用適當的命名約定命名這些屬性

  本系列的下一部分（也是最後一部分）介紹了決定跟踪哪些事件以及收集哪些數據的過程。

  

  但是，您應該對查看事件數據時的預期有一個很好的了解（無論是在檢測之前的跟踪計劃中，還是在產品分析工具等數據目標內部）。

  一些常見事件及其屬性

  在繼續之前，請看一下大多數科技產品跟踪的一些常見事件和屬性。

  

  實體類型

  現在是深入研究不同實體及其屬性的時候了。 如果您還沒有，請閱讀本指南以了解實體數據與事件數據的關係。

  在本系列的第一部分中，提到了用戶共享的數據屬於實體數據。 雖然這是真的，但並非所有實體數據都由用戶自己共享——也可以生成實體數據。

  實體數據包含與實體關聯的屬性——如果用戶是實體，則有關用戶的所有信息都以用戶屬性的形式收集。

  默認情況下為每個用戶生成User_id以識別用戶（並充當事件的標識符。）

  也就是說，暫時忘記事件並考慮與用戶相關的不同信息，並告訴您他們的特徵。

  實體數據的類型

  實體數據可以分為以下幾類（也在本系列的第 3 部分中提到）：

  • 個人身份信息，例如人口統計信息，例如角色，如偏好，例如特定於產品的數據，例如每個桶下的數據片段屬於用戶屬性。 換句話說，用戶屬性存儲有關用戶的各種詳細信息和特徵，使您能夠識別他們並了解更多關於他們的信息。

    雖然大部分信息直接來自用戶，但某些用戶屬性是隨著時間的推移由於產品使用而自動生成的。

    但是，不也是由於產品使用而產生的事件數據嗎？

    確實如此——用戶屬性是與事件發生時收集的事件相關的附加詳細信息。 讓我們看一下Signed Up事件及其屬性：

    

    如您所見，與此事件關聯的所有屬性都提供了有關用戶的詳細信息——由用戶自己共享的詳細信息（ first_name、last_name、email、phone、country ）或自動生成的詳細信息（ signed_up_at、user_id ）。

    記住以下幾點很有幫助：

    • 某些事件（例如已註冊或大多數禁止時間戳和標識符的用戶屬性可能會發生變化。 用戶可以更改其姓名、電子郵件、電話、位置、行業、工作角色等。但用戶不能更改註冊時間 (signed_up_at) 或唯一標識符 (user_id)。

    用戶屬性與組織屬性

    對於消費者應用程序，花費的時間、購買的產品、播放的歌曲或觀看的視頻是與用戶相關的屬性，存儲為用戶屬性，其值隨著使用量的增加而不斷更新。

    在 B2B SaaS 的上下文中，用戶和組織是主要實體，收集的事件與用戶或組織（或兩者）相關聯。

    可能還有其他團體實體，例如團隊或項目，與某些數據相關聯，就像大多數生產力工具一樣——收集組織數據的過程也適用於這種情況。

    讓我們看一下與 B2B SaaS 產品相關的一些常見用戶屬性：

    

    當用戶是組織的一部分時，許多重要信息都與組織相關聯，而不是與用戶相關聯。

    一些常見的組織屬性（也稱為組屬性）如下：

    

    重要的是要記住， organization_id也充當標識符，並且應該與事件相關聯，以了解某個事件發生在哪個組織下。

    牢記以下陳述有助於區分用戶屬性和組織屬性：

    • 每一條有助於定義用戶群組的信息——他們來自哪裡、他們是誰、他們的目標是什麼，或者他們在產品中做什麼——都被存儲為一個用戶屬性。
    • 每一條有助於細分賬戶或組織的信息——賬戶類型、它產生的收入、它使用的產品或功能、它消耗的資源，或者它的一部分的用戶數量——都被存儲為一個組織屬性（或組屬性）。

    一旦您能夠區分上述內容，就很容易將新實體（例如團隊或項目）納入組合中。

    下一步

    您現在應該清楚地了解如何定義事件及其相關屬性，以及指定每個實體（用戶和組織）的屬性。

    要立即開始定義事件和組織數據，請先使用免費的 Amplitude 帳戶。