如何建立使用者啟用報告：完整指南
兩個團隊看著相同的產品資料，卻分別回報了 22% 和 61% 的啟用率。
雙方都沒有犯算術錯誤。他們只是選擇了不同的事件、不同的時間窗口和不同的分母。
這正是這個指標最棘手的地方。公式本身只是個除法，但所有的爭論都在於該把什麼資料放進去。
本指南將介紹這份報告必須包含的內容，以及決定該數字的三個關鍵選擇。接著，我們將探討為什麼您的試算表會與分析工具的數據不一致，以及如何透過事件匯出資料來製作這份報告。
啟用報告必須包含哪些內容
標題上的百分比只有一行。而報告則是讓這行數字站得住腳的背景資訊。
有五個要素應該呈現在同一個畫面中：啟用事件、時間窗口、同期群定義、分母數量，以及啟用率本身。
漏掉其中任何一項，這個數字就會變得無法證偽。某人可能會在董事會簡報中引用它，但之後卻沒有人能重現這個數據。
將趨勢作為第六個項目加入。單次讀數只是一個資料點，而在定義不變的情況下連續三次的讀數，才是第一個值得採取行動的依據。
決定該數字的三個選擇
每個選擇都會單獨影響結果，而且在最終的百分比中，這些選擇都是隱形的。
| 選擇 | 決定了什麼 | 改變它會發生什麼事 |
|---|---|---|
| 啟用事件 | 什麼算作成功 | 選擇較晚發生的事件會降低每個同期群的啟用率 |
| 啟用窗口 | 使用者有多少時間 | 較長的窗口會提高啟用率，但會延遲報告產出的時間 |
| 分母 | 衡量對象是誰 | 偏移的同期群可能會使啟用率超過 100% |
選擇 1：啟用事件
這是最關鍵的主觀判斷，而且無法單靠查看匯出資料來解答。
啟用事件應該是能預測使用者會再次造訪的最早行為。便利性並非衡量標準，事件埋點的難易度也不是。
完成註冊幾乎絕非啟用事件。註冊只是進入漏斗的起點，而不是產品對某人產生價值的證據。
請選擇產品首次兌現其承諾的行動。對於報告工具來說，這可能是發布第一份報告；對於通訊工具來說，則是向另一個人發送第一條訊息。
用一行字寫下這個選擇及其原因。這句話能防止下個季度定義發生偏差。
Choice 2: The activation window
每個專業的工具都會將此視為一個參數，這意味著這是一個由您決定的決策。
Mixpanel's funnel documentation 寫得很明確。其轉換窗口「決定了使用者在進入漏斗後，有多少時間可以完成漏斗的所有步驟。」
該工具的預設值是自第一步起算 7 天。最大值為 366 天，若為基於工作階段（session）的窗口，則最多為 12 個工作階段。
有一個細節常讓人出錯。Mixpanel 指出，該窗口「始於每次進入漏斗時，步驟 1 事件的首次觸發。」該事件隨後的觸發並不會重新計算時間。
因此，一個註冊後消失了一個月，然後返回並啟用的使用者，可能會被視為流失。在短窗口的設定下，這是正確的運作方式，但這可能會讓閱讀您報告的人感到驚訝。
選擇 3：分母
分母就是同期群，而同期群是根據人們「何時加入」而非「何時行動」來定義的。
找出在固定期間內註冊的所有人。鎖定該名單，然後衡量其中有多少人在窗口期內觸發了啟用事件。
Mixpanel 的不重複計算方法也是如此，在「所選時間段內首次追蹤到步驟 1」時將使用者納入計算。後續的進入不會重複計入。
這裡的陷阱在於混淆了期間。如果分母是「本月註冊人數」，而分子是「本月啟用人數」，您就會把更早註冊的使用者的啟用次數也算進去。
這種版本的指標可能會超過 100%，這就是破綻所在。我們關於 cohort analysis 的說明文章介紹了為什麼必須先鎖定同期群。
為什麼您的試算表會與分析工具的數據不一致
對大多數團隊來說，做這種對比往往會耗費一整個下午，因此在動手之前先理解原因是非常值得的。
工具內部的三個設定在輸出結果中是看不見的：窗口長度、計算方法和步驟順序。
Mixpanel 預設為特定順序，要求每個步驟必須依序發生。它也提供「任意順序」選項，除非您錨定步驟，否則步驟可以按任何順序計算。
在試算表中重建模型時，會隱性地為這三個設定做出自己的選擇。這會導致兩個正確的計算得出不同的結果，而且雙方都沒有錯。
解決方法很枯燥但很有效：在報告上記錄這三個設定，並且只在基準相同的情況下進行比較，否則就不要比較。
如何手動製作
選項 1：兩次計數與一次除法
列出在該期間內註冊的所有使用者，然後使用 UNIQUE 函數排除重複的識別碼。
使用 COUNTA 計算該名單以得出分母。接著，使用 COUNTIFS 計算同一名單中，在窗口期內有啟用事件的使用者人數。
將這兩個計數保留在可見的儲存格中。最後再進行一次除法，這樣任何人都可以單獨稽核這兩個輸入值。
這種方法的局限性很快就會顯現。您只能得到單一窗口的單一百分比，且無法看出是誰沒有啟用。
選項 2：每位使用者佔用一列
建立一個表格，使同期群中的每位使用者佔用一列。欄位包括：註冊日期、首次啟用事件日期、兩者之間的天數，以及是否在窗口期內的標記。
用較晚的日期減去較早的日期來計算天數差距。微軟官方對 DATEDIF function 的指引警告，該函數「在某些情況下可能會計算出錯誤的結果」，並建議直接使用減法來計算天數。
現在可以對報告進行維度分析了。例如按方案、按獲客管道、按註冊週別或按公司規模。
洞察通常就隱藏在這些維度分析中。單一的綜合啟用率往往會掩蓋「某個管道啟用狀況良好，而另一個管道完全沒有啟用」的真實情況。
限制在於資料關聯（joins）和資料量。當事件匯出資料與使用者資料表比對超過幾十萬列時，過程就會變得非常痛苦。
選項 3：定義分頁
記錄啟用事件、窗口、同期群規則和計算方法。接著記錄您排除的內容，例如內部帳號和測試使用者。
內部流量是無形的干擾因素。一個 30 人的團隊每週測試產品，就可能將一個小同期群的啟用率拉高好幾個百分點。
這種方法的局限在於，寫下規則並不等於執行它。下個月還是會有人重新手動設定相同的篩選條件。
共同的瓶頸。 這三個選項都假設匯出資料包含可靠的使用者識別碼和乾淨的事件名稱。如果事件在季度中途被重新命名，那麼資料對齊才是真正繁重的工作。
手動流程在何處會變慢
第一份報告需要花費一個上午。第四份報告花的時間更長，因為到那時定義已經改變了。
事件重命名是最常見的原因。追蹤機制的清理將一個事件拆分為兩個，導致在使用者行為沒有任何改變的情況下，啟用計數卻下降了。
同期群期間也會發生偏移。有人用本季度的日期篩選條件重新執行上季度的檔案，然後在會議中對這兩個數字進行比較。
接著是每次都會出現的需求：有人要求按管道查看相同的啟用率，於是整套篩選條件又得手動重建。
這篇關於 AI tools for product analytics 的綜述介紹了這個問題的工具層面解決方案。
如何使用 Powerdrill Bloom 建立報告
步驟 1：上傳您的事件匯出資料
上傳事件檔案，或同時上傳事件與使用者檔案。Powerdrill Bloom 會在檔案匯入時分析欄位特徵，因此在計算任何啟用率之前，遺失的使用者識別碼、不一致的事件名稱以及超出範圍的時間戳記都會提前顯現。
步驟 2：用自然語言描述定義
直接說明規則，而不是手動建構它們。指定啟用事件、以天為單位的窗口、同期群期間，以及要排除哪些帳號。
接著提出能揭示邊緣情況的問題。例如詢問有多少使用者在窗口關閉後的一天啟用。詢問哪些事件名稱僅出現在部分期間。然後要求按管道和註冊週別拆分啟用率。
步驟 3：匯出圖表、報告或簡報
匯出包含分母的啟用率、自註冊以來按天計算的啟用曲線，或是將定義標註在數字旁邊的簡報投影片。
常見錯誤
將註冊視為啟用事件。 註冊只是進入漏斗的起點。啟用必須是產品真正提供價值的時刻。
只回報啟用率而沒有分母。 沒有說明基準的百分比只是裝飾。請在旁邊顯示同期群的大小。
混淆同期群期間。 將早期註冊使用者的啟用數計入本月的基準中，會虛增啟用率，甚至可能使其超過 100%。
更改窗口卻未重新標註。 7 天和 30 天的數據是不同的衡量標準。請固定其中一個並在報告上寫明。
將您的數據與公開的基準進行比較。 其他公司會選擇不同的事件和窗口。請先與您自己的趨勢進行比較。
在同期群中保留內部帳號。 員工和測試使用者的啟用率接近 100%。在小同期群中，這會明顯拉高數據。
忽略重命名的事件。 追蹤機制的變更可能會在行為未改變的情況下降低計數。在解釋數據下滑之前，請先檢查事件名稱。
結論
選擇啟用事件、固定窗口、鎖定同期群，並在回報啟用率時附上分母。這四個決策能產生一個讓人們可以據以採取行動的數字。
百分比本身並不是最終的交付成果。按管道和註冊週別拆分的數據，才能告訴您下個月該把預算花在何處。
如果重建這些拆分維度耗盡了您每個週期的精力，不妨試試用 Powerdrill Bloom 來處理您的事件匯出資料。另請參閱我們的指南：如何將產品使用資料轉化為功能採用報告，以及 AI report generator 頁面。
常見問題
啟用率的計算公式是什麼？
計算同期群中在窗口期內達到啟用事件的使用者人數。將該人數除以同期群中的總使用者人數，然後乘以 100。
啟用窗口應該設定多長？
應足夠長以捕捉正常行為，同時又足夠短以具備可操作性。Mixpanel 將其轉換窗口預設為 7 天，並允許最長設定至 366 天。
哪個事件應該算作啟用？
能預測使用者會再次造訪的最早行為。測試候選事件的方法是，觀察執行了這些事件的使用者是否會在隨後的幾週內再次返回。
為什麼我的數據會與我們的分析工具不一致？
通常是因為窗口、計算方法或步驟順序。這三個設定存在於工具內部，不會顯示在匯出的數據中。
啟用率會超過 100% 嗎？
只有在同期群被破壞的情況下才會發生。這種結果意味著早期註冊使用者的啟用數被計入了較晚的分母中。