用戶流失預警模型提示詞（流失定義、特徵工程、防止數據泄漏、基線與樹模型對比、SHAP 解釋與運營落地）
想提前識別可能流失的用戶（會員不續費、App 用戶不再活躍、客戶不再下單），把名單交給運營做挽留時用：AI 幫你先把「流失」定義清楚、按時間切分構造樣本避免數據泄漏，建立從簡單到複雜的模型，解釋每個用戶的風險原因，並設計挽留實驗評估真實效果。
通用大模型 對話模型通用
你是一名做過用戶增長項目的數據科學家，重視模型能否真正用於業務。請幫我搭建流失預警模型。 - 業務與用戶類型：[業務與用戶]（例：在線教育的付費會員，按月續費） - 可用數據：[可用數據]（例：用戶屬性、每日學習行為、付費記錄、客服工單） - 我對流失的初步定義：[流失定義]（例：到期後 7 天內未續費） - 數據規模：[數據規模] - 模型結果的用途：[結果用途]（例：每週給運營一份高風險名單，做電話回訪和發券） 請按以下步驟： 1. 流失定義：結合業務週期確認定義是否合理，以及「預測時點」與「觀察窗口」：在哪個時間點做預測、用之前多長時間的數據、預測之後多長時間內是否流失。畫出時間軸示意。 2. 防止數據泄漏：特徵只能使用預測時點之前的數據；列出容易泄漏的特徵（例如「取消自動續費」這個動作本身幾乎就是標籤）。 3. 特徵工程：活躍度與變化趨勢（近 7 天與前 7 天的對比）、使用深度、付費歷史、服務體驗（投訴、工單）、生命週期階段；給出構造代碼。 4. 樣本與切分：按時間切分訓練集、驗證集、測試集（用較早的時間段訓練、較晚的測試），而不是隨機切分；流失樣本比例低時的處理方法。 5. 模型：邏輯迴歸作為基線，再嘗試梯度提升樹；評估指標選擇 AUC 以及業務更關心的「排名前 N% 用戶中的流失比例」（因為運營只能聯絡有限的人）。 6. 解釋：全局特徵重要性，以及用 SHAP 解釋單個用戶為什麼風險高，轉化為運營能看懂的原因標籤（例如「近兩週學習時長下降 60%」）。 7. 落地：名單的更新頻率與輸出格式；按風險原因匹配不同的挽留動作；設定隨機對照組評估挽留效果——模型預測準不代表挽留有效。 8. 監控：上線後模型效果如何隨時間下降，什麼時候需要重新訓練。 代碼完整可運行，中文註釋。
高亮處換成你自己的內容：[業務與用戶]、[可用數據]、[流失定義]、[數據規模]、[結果用途]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[流失定義] 是整個項目的基礎，定義不同，模型學到的東西完全不同。[結果用途] 決定評估指標：運營每週只能聯絡 500 個人，那麼最重要的是「模型給出的前 500 人中有多少真的會流失」，而不是整體準確率。
常見坑：
- 用了預測時點之後才發生的行為作為特徵（例如「最近一次登入時間」算到了流失之後），模型在測試中表現極好，上線後完全失效。
- 隨機切分訓練集和測試集，同一個用戶不同時間的樣本同時出現在兩邊，評估結果虛高。
- 把高風險名單全部拿去發券，沒有對照組，最後無法判斷挽留到底有沒有效果，還可能把本來就不會流失的用戶也補貼了。
追問技巧：追問「設計一個挽留實驗：高風險用戶隨機分為三組（不干預、發券、電話回訪），怎麼評估哪種方式效果最好、成本最低」。
示例輸出
示例，僅供參考（時間軸與評估節選）
|——— 特徵窗口（預測前 60 天）———| 預測時點 |—— 觀察窗口（之後 30 天）——|
只能使用這一段的數據 ↑ 在這段時間內未續費 = 流失| 模型 | AUC | 風險最高的 10% 用戶中實際流失比例 |
|---|---|---|
| 邏輯迴歸（基線） | 0.74 | 41% |
| 梯度提升樹 | 0.81 | 52% |
| 整體流失率（參考） | — | 12% |
單個用戶的風險原因（SHAP 轉為業務語言）：「近 14 天學習時長比前 14 天下降 72%」「最近一次課程評分為 2 分」「會員剩餘 5 天到期且未開啟自動續費」。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～