如何創建跟踪計劃？

數據跟踪計劃（通常簡稱為跟踪計劃）是一個文檔，可作為事件數據的真實來源——它是一個動態文檔，其中包含與您在客戶互動時收集的數據相關的所有信息與您的產品。

本指南涵蓋了創建跟踪計劃的過程和最佳實踐，並提供了一個需要多次迭代和 100 多個小時才能創建的跟踪計劃模板。

創建跟踪計劃的好處

實際上，每次您希望執行以下任何操作時都會更新跟踪計劃：

• 收集新事件、事件屬性或實體屬性
• 修改事件名稱
• 修改屬性的名稱或數據類型
• 停止跟踪事件或屬性

任何不在您的跟踪計劃中的數據都不應被跟踪，對您的跟踪計劃進行定期審計可以防止出現如下所述的代價高昂的錯誤：

• 數據冗餘：多次收集同一條數據
• 數據不准確：收集不一致或不正確的數據
• 數據混亂：冗餘和不准確數據的組合

除了避免關鍵問題外，保持最新的跟踪計劃還有很多好處； 下面討論三個主要的。

易於實施

收集數據是一項持續的工作，需要各個團隊定期協調和執行新任務。

跟踪計劃不僅維護需要跟踪哪些數據的存儲庫，還指定數據的來源（數據源）、數據需要發送到的工具和系統（數據目的地）以及誰是負責實施。

與多個利益相關者合作時，提及每個事件或財產的目的可以加快實施過程，尤其是當一個或多個人需要批准對每個事件或財產的跟踪時。

快速參考

實施後，不同的團隊開始跨目的地消費和利用數據——發送跟踪數據的工具和系統。 更新的跟踪計劃使這些團隊能夠了解每個事件或財產的意義和目的，從而使他們能夠輕鬆地分析這些數據並採取行動。

例如，當產品團隊想要進行漏斗分析時，必須有人根據工具中提供的事件在產品分析工具中創建漏斗。

同樣，當增長團隊想要針對特定用戶群運行新的電子郵件實驗時，他們可以參考跟踪計劃，以便根據參與工具中的可用事件和用戶屬性輕鬆設置該群。

知識傳輸

儘管重要性很高，但對於大多數公司來說，知識轉移通常是事後才想到的，尤其是在設置事件跟踪的早期階段。

但是，通過維護適當和更新的跟踪計劃，公司可以避免項目交接或員工入職帶來的許多挑戰。

使新團隊成員能夠快速了解已實施的與事件跟踪有關的一切，可以節省新老團隊成員之間來回的數週甚至數月（取決於被跟踪的數據量）。

創建跟踪計劃的最佳實踐

關於跟踪計劃的內容已經說得夠多了； 現在讓我們關注跟踪計劃應該是什麼樣子。

終極跟踪計劃模板

下面的跟踪計劃模板是經過大量研究和多次迭代創建的 Google 表格電子表格，以適應幾乎所有行業。 它還附帶了一些示例事件和屬性，讓您搶占先機。

該模板包含說明和術語表。 瀏覽完各個選項卡後，轉到標記為“事件”和“事件屬性”的選項卡以開始使用。

下面的前 3 個步驟適用於所有類型的產品，而第四個步驟僅適用於需要跟踪帳戶級別活動的產品，例如 B2B SaaS 產品。

1. 活動
2. 事件屬性
3. 用戶屬性
4. 組織屬性

以下是創建您自己的跟踪計劃的分步過程。 在繼續之前，請確保您在另一個窗口中打開了跟踪計劃模板。 讓我們直接跳進去。

活動

在繼續之前，強烈建議您列出有關您的用戶及其產品使用情況的迫切問題。 理想情況下，緊迫的問題應該集中在理解用戶行為和用戶進入激活事件的路徑上。

如果您還沒有，您可能需要查看本指南，該指南更詳細地涉及急需解決的問題，並將幫助您決定要跟踪哪些事件以及要收集哪些數據。

請記住，在列出向下事件時可能會出現有關您的產品的其他問題 - 例如，您可能不確定是否應該將事件跟踪為點擊或流程完成。

如果出現此類問題，請務必在標記為“討論”的工作表下將它們列在您的跟踪計劃中——這樣做將確保您不會忘記與您的團隊討論從一開始就定義事件和屬性的最合適方式.

列出事件

在“事件”和“事件屬性”下，列出您需要跟踪以回答緊迫問題的核心事件。

該工作表包含示例事件Signed Up和現在，忽略屬性，只關注事件。

例如，這兩個事件可以回答“有多少百分比的新用戶創建了一個項目”這個問題，並且由於每個事件都帶有一個時間戳，您可以向下鑽取以僅從特定時期（例如過去 7 天）獲取數據。

在上面的例子中， Project Created是激活事件，要達到可以執行激活事件的地步，必須先註冊（執行Signed Up事件）。

記住這個例子，關注你的激活事件並列出用戶必須執行的關鍵事件才能到達激活點。 確保您只列出可以告訴您有關用戶旅程的關鍵事件。

通過列出太多事件，例如導致執行激活事件的每次單擊（示例中正在創建項目），您最終會遇到許多不必要的事件，這些事件會延長實施時間並讓您不知所措。

最佳實踐：首先列出一些有助於了解用戶行為和激活路徑的關鍵事件——暫時忽略其他所有內容。

如果您仍然需要跟踪什麼的想法，請查看 Amplitude 的實施指南，其中包含電子商務、金融科技、流媒體、印刷媒體和 B2B SaaS 的建議分類法。 即使您的產品屬於另一個行業，您也可以從這些或其他行業特定的分類法中獲得一些靈感。

添加來源和所有者

提及跟踪事件的來源非常有幫助。 這樣做甚至可以很容易地分配所有者——負責執行該事件的人。

正如您在跟踪計劃模板中看到的那樣，註冊是一個客戶端事件，因為一旦成功提交註冊表單，它就會在客戶端上發生。

另一方面， Project Created是一個服務器端事件，它依賴於服務器上發生的過程的完成。 如果該過程由於某種原因失敗，即使用戶可能已完成創建項目的所有步驟，該事件也可能不會執行。

在客戶端或服務器端跟踪事件完全取決於您的產品架構和它使用的技術——在跟踪計劃中指定它可能需要您的工程團隊的幫助。

此外，您可能還想跟踪連接到您的產品的外部系統上發生的事件。 例如，如果您想跟踪創建的事件支持票證並使用第三方票務工具（例如 Zendesk），則數據源將是 Zendesk，因為那是事件發生的地方。

最佳實踐：在檢測的第二階段從外部來源引入數據。

事件屬性

在添加一些事件之後定義事件屬性是一個更好的過程，因為您可以在精神上從考慮事件切換到考慮應該與每個事件關聯的屬性。

為每個事件添加屬性

一次處理一個事件，並考慮為您提供有關該事件的更多上下文的屬性。

請記住，用戶只執行一次Signed Up事件（在創建帳戶時），這是生成唯一標識符user_id的時間。如果組屬性適用於您的產品，則在用戶註冊新帳戶時還會生成組標識符organization_id 。 如果邀請用戶加入現有組織，則不會為該用戶生成新的除了系統生成的標識符之外， Signed Up還為事件發生時從用戶收集的每條信息（名字、姓氏、電子郵件等）提供了一個屬性。

屬性user_type有助於區分那些自然註冊的人與那些被邀請加入現有帳戶（已邀請）或被某人推薦以創建自己的帳戶（已推薦）的人。

有趣的注意事項：與因此，這些屬性也充當用戶屬性，並添加到用戶屬性表下。

其他事件（如Project Created ）可以執行多次，並且與事件關聯的屬性應僅限於提供有關該事件一次發生的上下文的屬性。

除了項目 ID (project_id)和時間戳(project_created_at) 之外，屬性project_name和project_user_count會在每次創建項目時提供附加信息（執行項目創建事件）。

此外， user_id需要與每個事件相關聯，以了解誰執行了該事件。 如果您的產品需要跟踪帳戶級別的活動，則還需要將諸如organization_id之類的組標識符與每個事件相關聯。

指定數據類型和期望值

本指南簡要介紹了為每個屬性指定數據類型的重要性。 這樣做對檢測過程有很大幫助，並且是保持數據一致性的關鍵步驟。

指定屬性的預期值對於那些負責實施的人也非常有幫助，並且當屬性應該包含預定義的值時，還可以使每個人都在同一頁面上。

數據類型為enum或array的屬性應始終指定預期值——精確值（如user_type所做的那樣）或對特定值列表的引用（如country 所做的那樣）。

提及目的地

術語目的地是指您希望將跟踪數據發送到的工具和系統。 重要的是要記住，數據只應發送到使用或操作數據的目的地，並非所有數據都必鬚髮送到套件中的所有工具。

個人身份信息 (PII) 應極其謹慎地處理，因為如果它落入壞人之手，可能會被濫用，並且只能發送到需要 PII 的工具（例如姓名和電子郵件）——用於基於事件的消息傳遞的參與工具（應用內或電子郵件）當然需要此信息。

因此，最好的做法是提及每個屬性的所有目的地，即使大多數屬性都發送到相同的目的地。

用戶屬性

您可能已經知道，用戶屬性存儲有關用戶的各種詳細信息和特徵，使您能夠識別它們並根據這些屬性對它們進行細分。

此外，如上所述，在註冊時從用戶收集的數據被添加為用戶屬性，因為這些屬性本質上是包含用戶特徵並反映其當前狀態的用戶屬性。

其中一些屬性保持不變，而其他屬性可能會發生變化。 如果用戶更改了他們在文件中的姓名或註冊的電子郵件地址，則相應的屬性將使用新值進行更新。

請注意，更改電子郵件時屬性is_email_verified的值會更改為 false，並且一旦驗證了新電子郵件， is_email_verified會更改回 true。

通過調查從用戶那裡收集的其他信息，例如他們所屬的行業或他們的工作角色，也被存儲為用戶屬性——它們有助於創建用戶細分以進行分析和激活。

繼續並在標有“用戶屬性”的工作表中列出所有用戶屬性、它們的數據類型、預期值和目的地。

組織屬性

組織屬性或組屬性僅適用於需要在帳戶級別跟踪用戶活動的產品。

與用戶屬性一樣，組織屬性存儲有關組織或帳戶的詳細信息。 任何不與特定用戶關聯並提供有關用戶所屬帳戶的上下文的數據都存儲為組織屬性。

您可能已經知道，組屬性對於 B2B SaaS 產品很常見，其中用戶是具有多個用戶的帳戶或組織的一部分。 帳戶名稱(organization_name)及其訂閱計劃(subscription_plan_name)是適用於大多數企業的通用組屬性。

但是，根據您的產品，可能有更多屬性與帳戶或組織相關聯，而不是與用戶相關聯。 在決定屬性應該是用戶屬性還是組織屬性時，您必須仔細考慮這一點，甚至可能讓您的工程團隊參與進來。

確定後，繼續並在標有“組織（組）屬性”的工作表中列出所有組織屬性、它們的數據類型、預期值和目的地。

就是這樣 - 您的跟踪計劃的第一個版本現在應該已經準備好了，所以請繼續與您的隊友分享它以開始協作。

開始跟踪

無論您是要實施客戶數據平台、產品分析工具還是客戶參與工具，第一步都是製定跟踪計劃。

既然您知道該流程是什麼樣的，您就有能力對您的客戶數據基礎設施產生重大影響。

也就是說，您可以使用 Amplitude 的數據治理功能更進一步的跟踪工作，以創建一個智能跟踪計劃，準確地檢測每個事件。 立即免費開始使用 Amplitude。

快樂追踪！