您需要精益數據分類來擴展自助服務分析

已發表: 2022-08-23

分類設計與產品分析密切相關。 無論您的行業、公司規模、產品組合或數據成熟度如何,如果沒有精益分類法,您就無法建立可擴展的產品分析。 當您考慮到大多數公司需要跟踪跨平台和跨產品的用戶旅程,並以預測未來場景的方式設置他們的產品分析工具時,這一點尤其重要。

換句話說,從推出產品分析解決方案的那一刻起,您就需要確保您的數據分類不會過時。 請遵循以下關鍵原則來設置您的產品分析以取得長期成功。

面向未來的產品分析和數據分類的最佳實踐

1. 大力投資於您的第一個產品的分類

產品分析是一個團隊遊戲,它要求您為參與該過程的人員定義明確的角色和職責。 強大的設置需要兩個關鍵角色的參與:

  • 負責定義產品分析需要涵蓋的核心用例集的業務主管(通常是產品負責人或副總裁)
  • 技術負責人(通常是高級工程角色),將推動分析實施的技術方面

這兩個角色都應該對產品具有跨平台和跨團隊的視圖,以便能夠在產品級別做出決策。 如果有多個產品和工程團隊將參與實施,那麼這兩個角色能夠協調團隊至關重要。 無論涉及的團隊數量如何,這都將確保產品分析的一致性。 讓更廣泛的領導團隊參與進來,通常會為產品分析創造額外的動力和興奮,並有助於提升公司範圍內的工作路線圖。

一旦您的團隊準備好構建產品分類法,您應該在深入了解細節之前確定您的產品所處的位置。 為此,請仔細考慮產品分析將為您的團隊回答的自上而下的問題,例如:

  • 我們產品的基本用戶旅程是什麼?
    • 用戶是否實現了我們期望他們實現的目標?
    • 是否使用了產品的主要功能?
  • 我們的關鍵漏斗是什麼樣的?
    • 用戶在哪一步下車?
    • 他們試圖做什麼?
  • 我們的入職轉換是什麼樣的?
    • 有多少人在入職過程中一路走來?
    • 有多少人達到了“啊哈”的時刻?

如果您在團隊中對這些基本問題達成共識,您將始終能夠擴大產品分析的覆蓋範圍,並深入研究具有最大潛力的領域(例如不明確的使用路徑、最大的下降-關)。

一旦您定義了產品分析的用例,就該定義您的數據分類了。 即,這包括:

  • 活動
  • 事件屬性(事件的上下文)
  • 用戶屬性(用戶的上下文)。

您在此階段的目標是使分類法盡可能精簡,並與上述問題保持一致。 根據我們的經驗,僅檢測 20-30 個事件就足以回答團隊一貫提出的大約 90% 的問題。

通常,只有少數事件會為常見的業務問題提供可靠的答案。 這將使您的公司了解真實的(不僅僅是預期的)用戶旅程,並獲得新的見解,例如:

  • 產品的真實角色
  • 用戶旅程中的摩擦點
  • 為什麼有些用戶轉換而其他用戶沒有
  • 應在下車時刻進行哪些 UI 改進

您可以在 Amplitude 的數據分類手冊中了解有關記錄事件、事件屬性和用戶屬性的更多信息。 關鍵點包括保持分類精簡、使用一致的命名約定以及在檢測事件和屬性之間取得適當的平衡。

2. 遠離跟踪低級 UI 元素

根據我們在 Amplitude 專業服務團隊的經驗,跟踪低級和不重要的 UI 元素是不可擴展產品分析的第一標誌。 通常,它反映了一種混合了事件和事件屬性定義的檢測方法。

例如,您的產品團隊可能正在下注以改善產品的結帳流程。 當他們在這個賭注上工作時,他們可能會測試一些添加或刪除 UI 元素的迭代。 在嘗試衡量每個測試的性能時,可能會有一種自然的趨勢來跟踪以下事件:

  • 複選框被點擊
  • 按鈕點擊
  • 切換滑動
  • 單擊的字段文本

如果您的初始分類充滿了上述 UI 元素,那麼可能是時候退後一步重新組合了。 是的,團隊一直在努力改進結帳流程並一直在調整這些元素,但請記住:此流程的目標仍然是用戶能夠無縫地通過它。 企業希望在分析中看到的用戶旅程可能是“結帳開始”→“選擇的付款方式”→“選擇的付款詳細信息”→“提交的交易”。 這種類型的流程比類似的流程更具信息性和可擴展性:“單擊按鈕”→“選中復選框”→“單擊字段文本”。 如果您在評估步驟之間的轉換時仍在尋求粒度,您可以使用兩種替代方法來解決這個問題:

  1. 在事件的事件屬性中檢測 UI 元素。 例如,“Transaction Submitted”事件可以有一個屬性來指示用戶是否使用複選框、按鈕單擊或其他 UI 元素執行了該操作。
  2. 使用 A/B 測試來提高掉率較高的步驟的轉化率。 例如,如果您在第 1 步和第 2 步之間觀察到較高的下降,則使用修改後的 UI 運行 A/B 測試並觀察樣本上的客觀結果通常會更有效,而不是在迭代過程中檢測多個元素。

3. 建立與業務成果的聯繫

最終,您的產品分析設置應揭示您的數字產品如何推動您的業務。

借助完善的數據分類,您的團隊可以在用戶旅程中探索許多因素,例如:

  • 人物角色
  • 公共路徑
  • 發布對關鍵指標的影響
  • 轉換驅動程序
  • 用戶旅程
  • 和更多

我們看到,在產品分析方面取得成功的團隊總是在他們跟踪的事件、他們所從事的業務以及他們的產品所玩的“參與遊戲”之間建立起閉環。

(參與遊戲是指您的產品驅動的三個主要“遊戲”之一:交易、注意力或生產力。在 Amplitude 的掌握參與劇本中閱讀有關這些方法的更多信息。)

例如,如果您的產品屬於“生產力遊戲”,您可能會有一個很棒的入職漏斗,但這個出色的入職漏斗不足以匹配您的業務目標。 您的產品最終必須實現生產力承諾; 這意味著用戶應該返回使用為他們帶來價值(生產力)的核心功能。 除了跟踪您的入職流程是否成功,請務必利用產品分析來評估用戶如何重複關鍵操作。

4. 不要一次跟踪所有內容

如今,大多數數字公司都認為跟踪數據是必須的,而科技行業使收集、存儲和處理大量數據變得越來越容易。 從產品分析開始並且已經擁有 CDP 或數據倉庫的公司通常傾向於跳過分類設計步驟,而只是開始流式傳輸他們已經收集的所有寶貴數據。

Amplitude 的專業服務實踐回到了舊的原則:少即是多。 向您的 Amplitude 用戶顯示一組 10 個相關且不言自明的事件總是比向只需要了解有多少活躍用戶的人顯示 600 個事件的列表(通常具有重複且沒有關鍵事件屬性)更好。或關鍵轉化率是多少。

驅動自助式可擴展產品分析的精益和簡潔分類法完全掌握在您的手中——您的同事將樂於在日常任務中使用這種分析類型。

從一種產品到跨產品分析

提供產品分析的精益初始實施可為每個數字團隊解鎖洞察力:營銷、產品、工程等。 有了這些可靠的洞察力,您還可以將組織拉向以數據為基礎的文化。 團隊開始從數據瓶頸轉向自助分析,並將洞察週期從幾週縮短到幾分鐘。

第一個產品的精益分類為公司的產品分析設定了標準,並允許其他團隊效仿。 只有當每個產品都具有與公司希望實現的業務成果相關的完善分類法時,才有可能成功進行跨產品分析。

產品指標 CTA