要用 AI 草擬客戶流失分析，必須先定義流失事件、eligible population、觀察窗口和 denominator，再開始計算。凍結一份已核驗的資料快照，記錄血緣與排除規則，檢查缺失、遲到和修正事件，並在受控工具中計算描述性基線。之後才能讓 AI 整理表格、提出待核問題和草擬審慎假設。相關性不等於因果關係，模型不能把關聯寫成客戶離開的原因。

輸入與審批的一般邊界見 AI 使用指南。如果任務只是核對公式或理解試算表，而不是形成流失專項分析，請使用試算表分析流程。

關鍵要點

先定義事件、合格總體、窗口、分母和排除規則。

凍結可重現快照，記錄血緣和 as-of time。

檢查缺失、重複、遲到、修正和來自未來的資料。

在程式碼或受管試算表中計算比率與 cohort。

把分群差異寫成描述，把驅動因素寫成假設。

尋找反證、混雜因素和其他解釋。

由資料負責人和決策負責人批准行動。

流失分析能說明甚麼，不能說明甚麼？

描述性流失分析說明已定義資料集中發生了甚麼：多少合格客戶符合流失規則、比率如何隨時間變化，以及獲批 cohort 之間有何差異。它可以找出值得調查的關聯，但不能單獨證明客戶為何離開，也不能決定哪項干預能留住客戶。

客戶資料由業務流程產生。計費遷移可能製造表面取消，遲到事件可能把流失歸入錯誤月份，方案調整可能改變合格總體。客戶聯絡支援與流失相關，也可能只是因為已遇到問題的客戶更容易聯絡支援。

報告措辭必須配合證據，例如「存在關聯」、「在本次快照中較高」或「是待檢驗假設」。只有研究設計確實支持時，才使用因果語言。

第 1 步：編寫流失測量契約

查詢資料前，先寫出另一名分析師可以獨立實施的定義。明確業務事件、風險總體、觀察起止時間、寬限期、回流規則，以及多產品或多帳戶如何處理。

契約欄位	需要回答的問題
Churn event	取消、不續期、不活躍，還是其他獲批事件？
Eligible population	窗口內哪些客戶確實可能流失？
Unit	客戶、帳戶、訂閱、合約還是產品？
Observation window	包含哪些事件日期？
Grace period	多晚續期仍視為留存？
Denominator	風險時點上的合格單位
Exclusions	測試、欺詐、遷移、員工帳戶或缺少同意？
Reactivation	回流會撤銷、延後流失，還是建立新生命週期？
As-of time	容許多少遲到資料？
Owner	誰批准定義及其變更？

分子和分母必須使用相同單位、範圍和時間邏輯。如果組織並存多個定義，應為每個定義分配帶版本的指標 ID，而不是混在一起。

英國政府資料質素框架指出，資料質素應結合用途判斷，並貫穿資料生命週期管理。［1］流失契約就是用途聲明，用來判斷每個欄位是否適合本次分析。

第 2 步：凍結資料快照與血緣

轉換前建立分析 manifest，記錄來源表、所選欄、查詢或匯出版本、時區、as-of 時間、行數、主鍵、join、filter，以及可重現計算程式碼的位置。工作應在獲准存取的非生產環境中完成。

Manifest 欄位	合成標識例子
Analysis ID	`CHURN-2026-Q3-V1`
Snapshot	`2026-09-01T00:00Z`
Source	受管訂閱表與事件表
Unit key	`ACCOUNT_TOKEN`
Definition version	`CHURN-RULE-04`
Query version	儲存庫路徑與修訂版本
Expected refresh lag	三個完整日
Data owner	具名分析負責人
Review state	Draft、validated、approved 或 superseded

不要讓模型不受限制地存取資料倉庫。只匯出所需的最少聚合欄位或去識別欄位。確需行級資料時，記錄授權、安全控制、保留期限和刪除路徑。

第 3 步：計算比率前檢查資料質素

執行確定性檢查並保存結果。至少檢查分析單位是否唯一、流失事件是否重複、狀態與日期是否缺失、事件順序是否無效、時區是否不一致、方案組合是否不可能、是否存在孤兒記錄，以及值是否在 as-of time 之後才到達。

區分三類時間：

**Event time：**客戶行為實際發生的時間。
**Processing time：**系統記錄或修改該行為的時間。
**Analysis time：**凍結分析快照的時間。

遲到事件會改變近期 cohort。應標記不完整週期，等待約定成熟窗口，或明確以 provisional 狀態發佈。不能暗中把成熟歷史 cohort 與尚未完整的近期 cohort 比較。

NIST/SEMATECH 工程統計手冊強調圍繞問題選擇統計方法，並理解方法背後的假設。［2］首要假設是資料生成過程和測量定義足夠穩定，能夠進行比較。

第 4 步：在受控工具中計算基線

用 SQL、程式碼或受管試算表計算數量和比率。AI 可以解釋或覆核已提供的公式，但聊天回覆不能充當計算記錄。應保存查詢、輸出、檢查結果和參數。

窗口內已核驗流失事件 / 風險時點上的已核驗合格單位

只有每個術語都已定義，這個公式才有意義。不同業務可能需要生存分析、經常性收入流失、客戶流失、logo churn 或不活躍指標，不能把它們視為可互換口徑。

每個百分比旁都要顯示分子和分母，並包含零計數 cohort 與抑制規則。20% 可能是 10 個中的 2 個，也可能是 10 萬個中的 2 萬個，兩者的不確定性和營運含義不同。

第 5 步：圍繞決策問題建立 cohort

選擇 cohort 是為了檢驗已定義的問題，而不是因為資料集有很多欄。常見維度包括註冊週期、方案、獲客渠道、獲批聚合級別的地區、引導完成情況、使用年期區間或已核驗服務體驗。

欄位	必填內容
Cohort ID	穩定標籤與定義版本
Decision question	為甚麼比較有意義
Inclusion rule	精確、可重現的條件
Time anchor	註冊、續期、事件或日曆日期
Numerator/denominator	比率背後的數量
Completeness	Mature、provisional 或 excluded
Comparison	獲批基線或同類組
Limit	小樣本、缺失、選擇偏差或政策變化

不要不斷切分資料，直到出現醒目的數字。重複探索會提高發現不可重現模式的機會。探索性結果必須標記，並保留後續資料集或週期用於確認。

第 6 步：防止未來資訊洩漏

流失分析可能誤用研究時點尚不可得的資訊，例如關閉後補錄的取消原因、數週後更新的支援處理結果、由取消動作觸發的挽留優惠，或使用未來收入計算的「生命週期價值」。

scikit-learn 的常見陷阱指南指出，使用預測時不可得的資訊會造成 data leakage，並產生不切實際的樂觀結果。［3］即使只做描述性分析，相同的時間順序檢查也能防止把下游事件寫成先前驅動因素。

建立欄位可用性表，記錄來源時間戳、首次已知時間、修正行為，以及欄位是否可用於描述、假設生成或預測。驅動因素分析應排除未來派生欄位，或明確將其標為流失後的描述。

第 7 步：用 AI 草擬客戶流失分析的假設，而非因果結論

向模型提供已批准的 cohort 表、資料質素說明和術語表，並要求按固定結構提出假設。

假設欄位	記錄內容
Hypothesis ID	穩定引用
Observation	已核驗的描述性差異
Proposed explanation	待檢驗的審慎機制
Supporting evidence	表 ID 與指標 ID
Counterevidence	不符合假設的分群或週期
Confounder	可能同時影響兩端的變數
Alternative explanation	測量或流程層面的其他解釋
Additional data	決策前仍需的證據
Test owner	負責分析或實驗的人
Status	Proposed、rejected、supported 或 superseded

例如，「已核驗 cohort 中跳過設定步驟 B 的新帳戶流失率較高」只是觀察。使用年期、獲客渠道、方案組合、事故暴露和產品變更都可能成為混雜因素。

每項假設至少要求一個其他解釋和一個反例。NIST 生成式 AI 風險框架指出，模型可能生成自信但錯誤的內容。［4］無依據的因果敘述即使符合團隊預期，也應拒絕。

第 8 步：審慎連接定性證據

評論主題應使用專門的客戶評論分析流程。只有總體、週期、產品版本和定義可比時，才把獲批主題 ID 連接到流失假設。投訴主題只能說明人們提到了甚麼，不能說明該問題在流失客戶中的普遍程度。

定性和定量證據應放在不同欄中，並記錄來源由誰產生、如何抽樣，以及是否包含留存客戶作為對照。主動尋找不支持結論的意見，不能只挑選符合偏好的例子。

使用訪談證據時，應保留 session 級語境，而不是把孤立引文複製到報告。證據必須在最初收集它的研究授權範圍內保持可覆核。

第 9 步：分層撰寫分析

報告應讓讀者明確區分已核驗事實、假設和決定：

範圍、定義、as-of time 和決策問題。
資料來源、血緣、質素結果、排除與限制。
總體分子、分母、比率和趨勢。
帶計數和不確定性的獲批 cohort 比較。
假設、反證、混雜因素和缺失證據。
擬議分析或實驗及其負責人。
獲授權人員作出的決定和覆核觸發器。

只有分析表獲批後，才能使用指標轉管理層摘要流程。摘要不能刪掉分母、provisional 標記或限制。

第 10 步：把假設轉成可覆核行動矩陣

不能看到高流失 cohort 就直接大規模干預。矩陣應區分資料修復、進一步分析、客戶研究、受控實驗和營運行動，並記錄預期學習、受影響總體、風險、護欄、負責人、批准以及回退或停止條件。

行動欄位	必填內容
Action ID	穩定引用
Linked hypothesis	保留證據與不確定性
Action type	修復、分析、研究、實驗或營運
Intended learning	甚麼結果會更新假設
Population	精確範圍與排除
Guardrails	客戶、法律、公平、成本和可靠性限制
Owner/approver	對執行與決定負責的人
Stop rule	暫停或終止行動的條件
Review date	覆核結果與副作用的時間

資料負責人批准定義與質素，領域負責人批准解釋，決策負責人批准行動。應保留不同意見和未解決問題。

最終覆核要確認甚麼？

流失事件、合格總體、單位、窗口、分母和排除規則均已版本化。
已記錄快照、血緣、查詢、時區、as-of time 和刷新延遲。
缺失、重複、遲到、修正和無效事件都有明確處理方式。
每個比率都顯示分子和分母。
Cohort 回答具名問題，並標出不完整週期或小樣本。
沒有把未來派生欄位寫成先前驅動因素。
每個擬議驅動因素都是帶反證和混雜因素覆核的假設。
定性證據保留自身的抽樣與授權限制。
行動和實驗有具名負責人、批准、護欄與停止規則。

常見問題

甚麼算客戶流失？

取決於獲批業務定義：取消、不續期、不活躍或其他事件。必須說明單位、寬限期、排除和回流規則。

應該使用甚麼分母？

使用在相同範圍和時間規則下確實可能流失的已核驗單位，並記錄風險時點與排除規則。

AI 可以計算客戶流失率嗎？

計算應使用可重現的 SQL、程式碼或受管試算表。AI 可以覆核所給邏輯或整理已批准輸出，但計算記錄必須保持確定性。

分析可以有多新？

取決於資料成熟度。遲到事件或修正仍可能顯著改變結果時，應把近期週期標為 provisional。

某個分群流失率較高就揭示了原因嗎？

不能，這只是描述性關聯。檢驗因果假設前，應覆核選擇、測量、時間順序、混雜因素和其他解釋。

可以把客戶聯絡支援當作流失驅動因素嗎？

沒有進一步證據時不能。客戶可能因為已遇到問題才聯絡支援，而且聯絡可能發生在相關風險開始之後。

應該加入客戶評論主題嗎？

可以，但必須確保授權、總體、週期和產品版本一致。定性證據應獨立呈現，不能當作發生率估計。

應該多久更新一次流失分析？

按決策節奏和資料成熟度更新。系統或政策變化後，應重新核驗定義、血緣、質素和 cohort 可比性。

誰批准最終行動計劃？

具名資料負責人批准測量，領域負責人覆核解釋，獲授權決策負責人批准實驗或營運變更。

來源

UK Government — The Government Data Quality Framework — https://www.gov.uk/government/publications/the-government-data-quality-framework/the-government-data-quality-framework
NIST — NIST/SEMATECH Engineering Statistics Handbook — https://www.nist.gov/programs-projects/nistsematech-engineering-statistics-handbook
scikit-learn — Common pitfalls and recommended practices — https://scikit-learn.org/stable/common_pitfalls.html
NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 9 月 4 日。

用 AI 草擬客戶流失分析：先定口徑與分母，再提出可檢驗假設