如何將產品使用資料轉化為功能採用報告 (2026)

匯出的使用數據是一長串的事件清單：使用者 ID、事件名稱、時間戳記，可能還有一兩個屬性。而功能採用率報告則是一個百分比。這兩者之間的距離是三個決定，而不是一個公式。

哪些使用者應該歸入分母。怎樣才算使用過該功能。以及您是在什麼時間範圍內進行測量。

只要改變其中任何一項，數字就會變動數十個百分點。報告看起來依然正確，而這正是問題所在。

本指南將介紹需要先確定哪些事項、三種手動評估路徑，以及每種路徑在何處會失效。

開始之前您需要準備的事項

您需要事件層級的資料列，而不是預先彙總的摘要。每一列代表一個事件，並包含使用者識別碼和時間戳記。

您需要實際代表該功能的事件名稱。這很少像聽起來那麼單純，因為大多數功能都會觸發多個事件。功能採用率數字的準確度，完全取決於該對應關係的品質。

您還需要知道誰可以使用它。如果該功能是透過 Feature Flag 僅發布給部分帳戶，那麼其他所有人都不應該包含在分母中。

快速進行合理性檢查可以省去後面一小時的麻煩。計算匯出資料中的不重複使用者人數，並將其與您已知的活躍使用者人數進行比較。如果兩者差異很大，說明匯出資料可能經過了您未注意到的篩選。

改變數字的三個決定

分母。所有註冊使用者、每月活躍使用者，或僅限符合該功能使用資格的使用者。這些會從相同的事件中產生三種不同的百分比。每個功能採用率數據都是一個分數，因此在計算任何內容之前，請先明確定義分子和分母。

對於新發布的功能，選擇「符合資格的使用者」通常是最誠實的做法。而「所有註冊使用者」則是看起來最差、但也最容易被辯護為保守估計的數字。

「使用過」的定義。觸發該事件一次、兩次，還是在兩個不同的工作階段中觸發。在導覽過程中點擊一次並不算是採用，大多數團隊都是在吃過苦頭後才明白這一點。

選擇一個門檻並將其寫在報告上。在兩天內使用兩次是一個常見且合理的規則。

時間範圍。採用率不是一個時間點。它是符合資格的使用者在某個期間內執行該操作的比例，因此該期間是定義的一部分。

在您複製某個工具的方法論之前，這裡有一個記錄在案的細節值得了解。Amplitude's retention documentation解釋了其計算方式。它「透過比較該起始事件的日期與您指定的返回事件的日期來計算留存率數據」。

日期範圍僅適用於第一個事件。Amplitude 明確指出「使用者不需要在該期間內觸發返回事件，即可出現在分析中」。

這是合理的行為，但常讓人感到意外。如果試算表將兩個事件都篩選在同一個時間範圍內，其結果將與該工具不一致，而這兩種方法都沒有錯。

如何手動進行

選項 1：計算不重複使用者人數，然後進行相除

從去重開始，因為原始事件數量並不代表採用者。使用 UNIQUE 函數提取不重複的使用者清單。

然後使用 COUNTIFS 函數（搭配事件名稱和日期範圍），計算這些使用者中有多少人觸發了該功能事件。最後除以您的符合資格使用者人數。

將這兩個計數保留在可見的儲存格中，而不是將它們巢狀合併在一個公式中。因為遲早會有人詢問分母是多少，而您會希望能夠直接指給他們看。

這種方法的局限在於它只給了您一個沒有具體輪廓的數字。您只知道有 18% 的人採用了，卻對這些人是誰一無所知。

選項 2：建立使用者層級的標記表

每個符合資格的使用者佔一列，每個問題佔一欄。他們是否觸發了事件、觸發了多少次，以及在多少個不同的日期觸發。

現在您可以進行交叉分析。按方案、按註冊同期群、按帳戶規模，或按他們是否完成了新手引導來分析採用率。

這就是功能採用率從「僅供報告」轉變為「具備行動指導意義」的關鍵。整體的 18% 隱藏了新使用者採用率為 40%，而去年的老使用者採用率僅為 4% 的事實。

這個差距就是關鍵發現。我們的 cohort analysis 指南介紹了為什麼即使使用者行為沒有改變，只要註冊量發生變化，整體數據就會隨之變動的原因。

限制在於資料量和資料關聯。百萬列的匯出資料加上帳戶資料表，已經超出了公式能流暢運作的範疇。

選項 3：在數字旁邊保留一個定義工作表

記錄下事件名稱、門檻、時間範圍、分母以及誰符合資格。

這能確保下個月的報告具有可比性。但當有人需要在十分鐘內拿到數字時，這個工作表也最容易被忽略。

局限在於，記錄定義並不等於套用定義。每到新的週期，還是會有人重新設定那五個相同的篩選條件。

共同的局限。這三種方法都假設事件名稱是乾淨的。當程式碼重構後，同一個動作在三個不同的名稱下觸發時，在開始任何計算之前，真正的工作是整合這些名稱。

手動路徑在何處會拖慢效率

第一份報告需要花費一個上午。第四份報告花的時間更長，因為到那時，定義已經在不知不覺中發生了偏差。

當產品變更時，事件名稱也會隨之改變。程式碼庫中的重新命名會導致圖表上出現斷崖式下跌，看起來就像是使用者放棄了該功能。這就是為什麼功能採用率圖表最終報告的是程式碼變更，而不是客戶的決策。

發布範圍的變更會破壞分母。當該功能推廣到 100% 的帳戶時，採用率看起來反而下降了，因為符合資格的人口增加了三倍。

還有一個存在最久的計算錯誤：每當少數核心使用者頻繁使用該功能時，加總事件數量（而不是計算不重複使用者人數）就會誇大採用率。

還有一個只有在截止日期臨近時才會顯現的成本。當有人問「這算好嗎？」時，單一的百分比無法回答，而建立對比分析就變成了另一個專案。

如何使用 Powerdrill Bloom 建立報告

步驟 1：上傳您的使用數據匯出資料

上傳事件匯出資料，或將事件和帳戶檔案一起上傳。Powerdrill Bloom 會在匯入時分析欄位，因此在計算任何百分比之前，不一致的事件名稱和缺失的使用者 ID 就會顯現出來。

步驟 2：用自然語言描述定義

直接說明規則，而不是去建構它們。指出事件名稱、門檻、時間範圍以及哪些使用者符合資格。

然後提出能避開陷阱的問題。詢問是否有任何事件名稱看起來幾乎重複。詢問有多少不重複使用者觸發了事件與觸發了多少次事件，以及功能採用率如何因註冊月份而異。

步驟 3：匯出圖表、報告或簡報

匯出採用趨勢、按區隔劃分的表格，或是同時包含數據和定義的投影片。

為什麼這比每個週期重新製作更好

	手動路徑	Powerdrill Bloom
從事件中去重使用者	每個檔案中的輔助欄	要求不重複使用者人數
按同期群或方案進行拆分	關聯並重建資料表	要求提供分析明細
版本發布後重新命名的事件	稍後在圖表中發現	在上傳時顯現
變更符合資格的人口	重新調整分母	說明新規則

第三列是決定準確與否的關鍵。在折線圖中，重新命名的事件和真正的採用率下降看起來完全一樣，但其中只有一個需要產品團隊做出回應。

常見錯誤

計算事件數量而非使用者人數。來自兩百個人的一萬次事件並不等於採用。請務必先進行去重。

在設有 Feature Flag 的功能上，將所有註冊使用者作為分母。如果只有三分之一的帳戶能看到該功能，那麼另外三分之二的人並不是「未採用者」，而是「不符合資格」。

將一次點擊視為採用。在引導過程中的單次事件只是「接觸」。如果您希望這個數字有意義，請要求在不同日期重複使用。

比較跨月份的整體混合率。新使用者和現有使用者的採用率不同，因此使用者結構的變化本身就會影響數字。在得出結論之前，請先按同期群進行拆分。

忽略事件重新命名。程式碼重構會產生看起來像流失的斷崖式下跌。在調查使用者行為之前，請先檢查事件字典。

在未閱讀工具運作方式的情況下直接複製其時間範圍。記錄在案的留存時間範圍通常僅篩選第一個事件，因此篩選兩個事件的試算表將會得出不一致的結果。

在沒有附加定義的情況下報告百分比。如果沒有分母和門檻，這個數字就毫無意義。請將兩者都標註在圖表上，就像一個優秀的 KPI dashboard 標記其指標一樣。

結論

在進行相除之前，先確定符合資格的人口、設定使用門檻、固定時間範圍，並對使用者進行去重。這四個步驟能將功能採用率百分比轉化為產品團隊可以採取行動的依據。

讓這項工作成本高昂的原因在於，定義必須在產品變更中存活下來。重新命名的事件和擴大發布範圍都會在無人修改報告的情況下改變數字。

如果這正是您的報告週期所面臨的困境，請嘗試在您的使用數據匯出上使用 Powerdrill Bloom。另請參閱我們關於建立同期群留存圖表的指南、用於產品分析的最佳 AI 工具總覽，以及 CSV AI 助手頁面。

常見問題

什麼是功能採用率？

它是指在定義的時間範圍內使用某項功能的符合資格使用者比例，以不重複使用者人數而非事件數量來衡量。只有在說明了分母和使用門檻的情況下，該定義才成立。

如何從事件匯出資料中計算它？

計算在您的時間範圍內觸發該功能事件的不重複使用者人數，然後除以符合資格的使用者人數。請務必先進行去重，因為單一使用者可能會產生數百個事件。

分母應該是所有使用者還是活躍使用者？

請使用符合資格的人口，即實際可以接觸到該功能的使用者。使用所有註冊使用者會產生一個保守的數據，並會低估在 Feature Flag 保護下的功能採用率。

測量時間範圍應該多長？

應足夠長以涵蓋正常的使用週期，例如日常使用的產品為每週，定期使用的產品為每月。請在各份報告中保持固定，因為改變時間範圍會改變數字。

為什麼我的數字與分析工具不一致？

通常是因為時間範圍或去重規則。記錄在案的留存率計算通常僅將日期篩選套用於第一個事件，而基於這兩個事件建立的試算表將無法重現該結果。