如何將您的分析跟踪轉變為持續的協作過程

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

我們都知道，任何構建數字產品和服務的組織都會收集數據。 我們也知道，僅僅收集數據與實際有效地使用數據是不一樣的。 即使您制定了出色的跟踪計劃並得到強大工具包的支持，但如果您不花時間參與一件關鍵的事情：協作，您的策略也會失敗。

分析觸及數據主導型公司中的每個人

考慮為您的產品構建新功能。 這裡有兩個主要考慮因素：此功能將帶來哪些新數據點，以及這些數據點的受眾是誰？ 好吧，如果你真的想做出數據驅動的決策，或多或少每個人都會成為你的客戶數據的受眾。

參與分析跟踪的主要利益相關者都將把他們獨特的想法和專業知識帶到故事中——領域知識和技術訣竅的健康結合。 我們有：

• 行政人員/領導
• 產品經理
• 分析師/數據團隊
• 開發商

這些團隊中的每一個都有自己不同的任務和目標，但最終他們將根據相同的跟踪計劃開展工作。

提示：擁有太多廚師可能是一場噩夢——閱讀這篇文章以了解更多關於誰應該擁有跟踪計劃的信息。

這些團隊（應該）如何在分析方面相互協作。

行政人員/領導

讓我們從需要最高級別事件跟踪視圖的團隊開始。 在構建新功能時，執行官最關心的是這個新功能的目標是什麼，以及將使用什麼指標來衡量成功。

這意味著在領導下工作的團隊需要具備做一些高質量報告的能力。 一個優秀的領導團隊不會希望根據直覺做出關於公司未來的重要決定——他們會想要確鑿的證據來證明什麼有效，什麼無效。

該團隊的主要協作行為：

• 領導層應該盡最大努力激發整個組織的協作，並培養一種理解數據驅動決策價值的文化。
• 慶祝基於數據做出決策而取得的成功。
• 粗略地說，如果您的經理不關心良好的分析跟踪，那您為什麼要關心？ ‍

產品經理

產品經理非常了解您的產品，以及它在市場/行業中的地位。 他們負責交付這項新功能，因此將尋求將領導層關心的那些指標轉化為他們想要跟踪的實際事件。 為了針對此新功能構建可靠的報告，需要從一開始就內置事件跟踪。

雖然產品經理擁有大量領域專業知識，但他們可能不具備自己定義跟踪計劃所需的技術技能。 這意味著他們必須與其他團隊合作才能完成工作。 一個好的產品經理不太可能指定他們想要跟踪的事件列表，並期望由此產生完美的報告。 相反，他們可能會與分析師和開發人員討論並就可能實現的目標達成一致，因為這些團隊將實施跟踪計劃並構建報告。

因此，產品經理會知道哪些指標很重要，但可能會依賴其他人將這些指標轉化為可跟踪的事件。 他們將有助於提出正確的數據問題，決定何時進行 A/B 測試，並創建適當的反饋循環：查看先前決策的性能，並對這些決策進行迭代。

該團隊的主要協作行為：

• 定期與分析師核實，了解正在跟踪的事件及其原因，並讓每個人都在分類和命名約定的同一頁面上
• 與開發人員合作，確定需要對跟踪計劃進行哪些更改，以及這些更改在給定基礎架構的情況下是否可行以及完成這些更改需要多長時間
• 確保他們通過高質量的報告向領導層提供反饋

分析師

您的數據分析師團隊就像公司的報告中心樞紐。 他們很可能是最先拿到原始數據的人（可能是唯一的）。 他們將致力於連接、建模和可視化數據。 它們有助於將數據轉化為洞察力。

關於分析師團隊的一個重要說明：他們不應該被視為一種組織資源，即當您需要與數據相關的東西時“可以問的人”。 如果是這種情況，分析師可能會發現他們的能力被用於滿足其他團隊的日常要求，而不是實際建立洞察力和生成有意義的報告。

分析師協作過程的一部分是讓其他團隊盡可能地自助服務。 這方面的一個基本示例可能是與產品經理和營銷人員合作，將預定義查詢構建到 Tableau 等工具中，以便單擊按鈕即可回答最常見的問題。 產品和營銷團隊還可以使用 Amplitude 等自助式數字分析平台自行構建圖表並分析客戶行為。

該團隊的主要協作行為：

• 與產品經理合作以更多地了解數據背後的人：他們可以使用抽像數據，而無需對最終用戶了解太多，但如果他們對這些數據的重要性有更深入的了解，將會更加有效
• 促進具有挑戰性的對話，討論哪些問題對數據提出的問題最有幫助，以及其他團隊想要跟踪什麼（例如，如果團隊要求收集的數據比需要的多，知道什麼時候該推遲）

開發商

當然，開發人員是實際構建產品並因此實施您的跟踪計劃的人。 從技術上講，軟件工程師不必非常了解您所從事的行業或最終用戶的行為。 這並非全面如此，並且導致了開發人員不關心分析的假設。

實際上，如果沒有系統化的協作流程，工程團隊可能很難以有意義的方式參與分析。 在構建新功能時，收到要跟踪哪些事件的電子表格可能會令人沮喪，因為這對工作流程造成了巨大的干擾。 在 IDE、電子表格和 Jira 票證之間來回切換很麻煩，而且很容易導致錯誤和不一致。

優秀的開發人員更有可能關心他們構建的產品的性能——他們也比任何人都更了解產品的實際工作原理，因此最有能力以最有效的方式實施跟踪計劃。

該團隊的主要協作行為：

• 確保產品經理了解其產品基礎架構的局限性、何時何地進行跟踪以及實施可能需要多長時間
• 與分析師密切合作以構建數據和分析管道，並確保一切都按預期進行
• 幫助所有其他團隊了解，要有效地跟踪事件，他們需要時間從一開始就將跟踪構建到功能中，而不是事後才想到

促進圍繞分析跟踪的協作

有了對團隊如何在分析跟踪方面協同工作的廣泛理解，開始開發協作流程應該會更容易。 很明顯，如果每個人都致力於構建和維護相同的產品，那麼跨團隊的溝通將非常重要。

開始將您的分析視為產品後端的關鍵設計點。 它不僅僅是您在交付功能後添加的東西，而是 SDLC 的組成部分。

許多公司，尤其是科技行業的公司，已經習慣於使用協作和知識共享工具，例如 Jira、Slack，當然還有 Amplitude。 如果您熱衷於在您的組織中採用更強大的協作流程，我們建議您根據自己的意願構建案例。 獲得新流程的支持通常是最困難的部分。

沒有必要重新發明輪子。 應用已經有效的現有流程。

通常，採用新流程（例如在分析方面有效協作）幾乎與技術無關，而與文化息息相關。 在分析方面，知識不會存在於一個人或一個團隊中——每個人都需要共同努力才能充分利用您的數據。

重要的是要注意，沒有人會採用新流程（無論它有多好），除非他們看到它的意義。 實際上，讓全公司都接受新流程的一個好方法是通過將其與其他現有流程進行比較來證明該流程的價值。 幾個例子：

GitHub：如果我說幾乎每個構建軟件的人/公司/組織都使用 GitHub，我認為我不會誇大其詞。 這是一個非常優雅但硬編碼的過程：編寫的每一段代碼都要進行分支、提交和合併。 所以 Github 實際上不像一個工具，而更像是一個過程：如果每個人都不使用它，它就根本無法工作。

Figma：完美展示無縫跨團隊協作的工具； Figma 使產品設計師能夠將原型交給開發人員，清楚地展示所有元素是如何組合在一起的。 提示：使用 Figma 中的 Amplitude Event Planner。

Amplitude 可幫助您協作

將 Amplitude 的數據治理功能視為分析的 GitHub 很有用。 Amplitude 促進了圍繞活動規劃的透明、可審計的過程，無論技術能力如何，每個關鍵利益相關者都可以參與其中。

最好的流程是您甚至沒有註意到的流程：我們擁有開發人員工具，因此不會中斷任何人的工作流程，使工程師能夠使用類型安全的開源 SDK、CLI 和 CI/CD 輕鬆準確地實施分析跟踪一體化。

Amplitude 首先是一個協作平台，為分析提供可靠的事實來源。 這意味著那些使用數據的人知道他們可以信任它。 如果您已經為新的協作流程獲得了大量支持，Amplitude 肯定可以在支持方面發揮作用。 申請免費演示並立即開始您的探索。