誰應該真正擁有您的跟踪計劃？

編者按：本文最初於 2021 年 1 月 11 日發表在 Iteratively 博客上。

“數據是一項團隊運動”是我們堅信並經常在 Amplitude 談論的話題。 分析跟踪計劃沒有什麼不同——跟踪計劃（以及它們的檢測）本質上是協作的。 當相關團隊齊心協力時，他們才能發揮最佳作用。

讓我們以新功能發佈為例。 產品團隊已經為這個新功能定義了目標和指標，並將了解需要哪些事件跟踪來衡量這些指標。 iOS、Android 和 Web 開發團隊負責檢測（最好是測試）代碼中的這些事件，並將對可行的方法發表意見。 分析師或分析工程師負責對數據建模並關心其結構，您可能有多個團隊負責構建報告並使用多種工具分析數據。 簡而言之，在以數據為主導的公司中，分析幾乎涉及到每個人。

該示例說明了分析跟踪的真正複雜性，還說明了協作在定義和捕獲正確事件、準確實施這些事件以及讓數據消費者輕鬆探索數據時的重要性。 也就是說，有這麼多人參與，分析跟踪很容易成為燙手山芋。

如果它為所有人所有，那麼它就不為任何人所有

由於涉及到如此多的利益相關者，跟踪計劃往往成為一項共同的責任，沒有明確的所有者。 分擔責任幾乎沒有問責制。

我們已經與許多想要（重新）創建圍繞分析跟踪的流程的公司進行了交談。 它通常圍繞電子表格或 Confluence 或概念頁面展開。 雖然它主要是手動的，並且沒有辦法在代碼中強制執行跟踪計劃，但它在開始時被證明是有用的，並迫使團隊更多地考慮事件跟踪。

然而，幾個月後，概念頁面或谷歌電子表格變得過時：最新版本的跟踪僅記錄在 Jira 故事中，而對於其他一些功能發布，現在尚不清楚是否實施了跟踪。 沒有人將更新跟踪計劃作為自己的責任。

那麼，您如何更好地改變這種情況以及誰最適合擁有您的分析跟踪？

首先將分析放在首位和中心位置

在深入探討所有權問題之前，我們必須提及分析跟踪成功所需的基礎：事件跟踪很重要，沒有它，您將一無所知。 現實情況是，對於大多數團隊而言，分析是事後才想到的。 這是我們經常看到的一個例子：

• PM 負責發布
• 釋放發生
• CEO 詢問 PM 它的表現如何
• PM：“讓我問問數據團隊”
• 數據團隊：“你從來沒有把我們帶進來——沒有關於這個特徵的數據。”
• PM 回到 CEO 那裡沒有答案
• 數據團隊和 PM 心煩意亂

如果分析沒有成為每個版本不可或缺的一部分，這種情況會一遍又一遍地發生，而您的跟踪計劃是否看起來真的很圓滑並且是最新的也無關緊要。 您需要所有利益相關者（以及您的領導團隊）的支持，即分析跟踪與功能本身一樣重要。 沒有跟踪，沒有發布。

您需要明確的責任、時間和資源來授權相關團隊，然後您需要將事件跟踪和成功指標嵌入到 Jira 票證級別（僅當跟踪代碼與其餘代碼一起交付時才完成）。

我們從對數據和產品專業人士的 400 多次採訪中學到了什麼

在兩年內，我們採訪了 400 多名產品經理、數據團隊和工程師。 我們已經看到了一些東西。

當然，您的跟踪計劃及其相關流程對於您的業務、團隊結構和垂直領域而言是獨一無二的（這可能就是為什麼很難做到正確的原因）。 電子商務公司的跟踪計劃與 B2B SaaS 公司的跟踪計劃看起來非常不同。 他們有不同的利益相關者參與並解決完全不同的現實。 最常見的是，我們可以按公司規模細分我們所看到的內容。

創業公司

對於小公司來說，跟踪過程通常是臨時的。 這是很自然的，因為很少有人參與，並且使復雜性易於管理。 大多數情況下，我們會看到產品負責人或增長負責人在公司發展歷程的這個階段承擔責任。

中小企業

在一家中型公司中，該過程通常落在數據/分析的負責人身上。 現在有更多的利益相關者參與，複雜性很容易成為一個問題。 在這個階段，明確需要所有權來限制損害，並且通常落在數據團隊中的某個人身上。

企業

在較大的公司中，最終擁有跟踪計劃的人通常是產品分析的負責人。 對於電商企業來說，往往會是電商的負責人。 通常他們不會是維護計劃或執行流程的實際日常人員，而是他們團隊中負責的人。

我們已經從這些類型的設置中看到了不同程度的成功。 那麼，我們認為什麼最有效？

什麼有效：產品團隊是最終的所有者

這就是我們所知道的：最好的所有權流程發生在產品團隊充當最終所有者的時候。 產品經理應該是主要驅動力，並確保分析跟踪是每個功能發布的一部分。 根據您的團隊規模，這可能是一名或多名產品經理或一名專門的產品分析師。 作為其角色和 OKR 的一部分，他們應該對分析跟踪負責。

但正如我們之前提到的，數據是一項團隊運動，我們建議團隊聚在一起定義事件命名和分類法等內容。 工程師和數據團隊將擁有重要的觀點，因為這也會影響他們的日常工作。 雖然產品團隊是執行者和最終所有者，但他們不應該在沒有合適的利益相關者參與的情況下孤立地工作或做出重要決策。

建立一個代表所有相關利益相關者的諮詢委員會對我們合作過的公司來說效果很好。 並不是每一個決定都會交給顧問委員會，但他們應該是一開始的驅動力，定義你的分類和流程，並根據隨著時間的推移發生多少重大變化而定期開會。

為了讓產品團隊成功擁有它，您需要一個清晰的流程：

• 作為每個用戶故事的一部分，為定性和定量指標制定明確的成功標準。 這些應該由 PM 定義，並與數據團隊或分析師討論。
• 缺少跟踪？ 構建失敗。 完成的概念需要發展以將分析跟踪作為每個版本的一部分。 這並不意味著在發布之前就阻止發布，而是意味著實施一個從一開始就包含跟踪注意事項的流程。
• 協作是關鍵。 雖然 PM 將擁有事件跟踪規範，但數據團隊或分析師應該可以介入並幫助定義應該跟踪的細節。

讓您的產品經理擁有所有權

對於某些 PM，擁有跟踪計劃對他們來說是很自然的事情。 他們想要控制權並擁有經驗。 他們也不怕在需要時尋求幫助。 但這並非對所有 PM 都是自然而然的。

首先，需要發生文化變革：慶祝新功能或產品發布的性能和成功，而不是它發布的事實！ 令人驚訝的是，對於許多人來說，獲得讚譽的仍然是運輸，而不是產品是否表現出色。

那麼，您如何授權您的產品團隊擁有跟踪計劃呢？ 這不是一個詳盡的清單，但希望是人們開始的地方：

• 定期培訓：正確進行事件跟踪既是一門藝術，也是一門科學（即這並不容易），因此請確保您的團隊擁有輕鬆掌握所有權所需的知識。 培訓可以是午餐和學習風格、研討會或一對一課程（請記住記錄您的課程以供將來僱用）。
• 辦公時間：當數據團隊為其他團隊舉辦定期辦公時間以利用數據團隊的專業知識和知識時，我們已經看到了巨大的成功。 確保團隊準備好議程或具體問題，以避免它變成“支持台式”會議。
• 清晰的流程和檢查點：我們怎麼強調定義流程的重要性都不為過。 確保你有一個每個人都知道、理解和遵循的清晰流程，並包括定期審查點以確保質量，就像軟件開發中的代碼審查和合併請求一樣。
• 嵌入分析師：當然，這並不總是一種選擇，但我們已經看到成功的團隊將數據分析師部分或全職嵌入到產品團隊中，以擁有分析跟踪並幫助 PM 進行數據探索和分析。
• 自助式分析：我們認為最好的做法是讓 PM 和組織中的其他人能夠輕鬆探索數據集并快速獲得問題的答案。 Amplitude 對此非常有用，可確保整個公司的高水平數據素養。

提醒：好的 PM 不需要懂 SQL

如果您無論如何都無法自己探索數據，為什麼還要關心事件跟踪呢？ 為了擴展上面最後一點，我們已經看到擁有中央數據團隊的公司擁有所有報告和數據分析。 它有其優點，但根據我們的經驗，它會限制 PM 和其他人，他們將不太關心分析跟踪或數據質量。

請記住，讓 PM 和其他人訪問 Redash 或其他基於 SQL 的工具並不等於授權 PM 進行自助服務。 不要指望您的 PM 了解（或學習）SQL。 那不是他們的工作。相反，為他們提供易於使用的 UI 和大量培訓，以配合工具和數據集。 當然，SQL 知識有其明顯的優勢，如果您能夠在公司範圍內找到或培訓人才（想想產品、營銷、客戶成功等），您就可以讓它發揮作用，但它也有明顯的缺點和局限性。

如果 PM 能夠自助服務，他們更有可能探索來自最近發布的數據。 當他們探索數據時，他們更可能關心數據的質量、豐富性和可用性。 創建一種授權文化並圍繞分析跟踪構建可靠的流程，您將擁有快樂的 PM、快樂的分析師、快樂的數據團隊，甚至快樂的開發人員。

振幅在這里為您提供幫助

Amplitude 幫助數據團隊、產品經理和工程師定義、檢測、驗證和協作分析跟踪。 我們主動解決因事件命名不一致和跟踪缺失而引起的數據質量問題，並提供用於管理跟踪演變的工作流程。

我們授權產品經理負責跟踪計劃並加強團隊之間的協作。 如果您有興趣為您的公司試用 Amplitude，請立即創建一個帳戶或與我們的團隊一起預訂演示以了解更多信息。