簡介這套客戶留存分析與流失預(yù)測項(xiàng)目包面向電信、保險(xiǎn)等行業(yè)的客戶分析場景也適合人工智能、計(jì)算機(jī)科學(xué)等專業(yè)用于畢業(yè)設(shè)計(jì)或課程作業(yè)。方案基于生存分析模型刻畫客戶流失隨時(shí)間變化的趨勢并計(jì)算生命周期價(jià)值同時(shí)使用隨機(jī)森林模型預(yù)測流失概率通過Flask Web應(yīng)用完成交互式部署與結(jié)果展示。壓縮包共62個(gè)文件容量19.89MB主體包括3個(gè)Jupyter Notebook數(shù)據(jù)探索、生存分析、流失預(yù)測建模、1個(gè)Python應(yīng)用入口、1個(gè)前端HTML模板以及49張結(jié)果可視化圖片如生存曲線、特征重要性、SHAP解釋、部分依賴圖等另有訓(xùn)練好的模型pkl文件、依賴清單和說明文檔。已有163人學(xué)習(xí)下載。下載后可按README指引快速復(fù)現(xiàn)流程直觀獲取完整代碼、圖表與模型文件便于對照學(xué)習(xí)客戶生命周期價(jià)值計(jì)算、特征解釋及模型部署等關(guān)鍵環(huán)節(jié)。1. 客戶留存分析與流失預(yù)測系統(tǒng)先想清楚拿到zip之后要干什么拿到客戶留存分析與流失預(yù)測系統(tǒng).zip的那個(gè)下午我以為是解壓就能跑的現(xiàn)成工具結(jié)果從理解業(yè)務(wù)到真正用它做出判斷花了兩周。這套系統(tǒng)要解決的問題有兩層一層是留存分析——用戶來了之后有多少留到今天有多少在第幾天離開另一層是流失預(yù)測——在用戶徹底離開之前用一個(gè)概率分圈出高流失風(fēng)險(xiǎn)名單交給運(yùn)營去觸達(dá)。它適合的不是算法團(tuán)隊(duì)而是手里有用戶行為數(shù)據(jù)、想用低成本方式建一套留存監(jiān)控與預(yù)警流程的運(yùn)營或開發(fā)。下面講的是我在落地這套系統(tǒng)時(shí)的完整路徑包括數(shù)據(jù)清洗、建模、打包交付和最常見的坑。2. 數(shù)據(jù)清洗與特征工程留存分析不是跑個(gè)模型的事2.1 用戶行為數(shù)據(jù)長什么樣從訂單表到用戶日活表很多團(tuán)隊(duì)的數(shù)據(jù)現(xiàn)狀是訂單表、注冊表、登錄日志各存各的甚至取數(shù)的口徑都要問三個(gè)部門。做留存分析之前第一步不是寫模型而是把數(shù)據(jù)在用戶維度上拉平。常見的做法是以 user_id 為主鍵把訂單表和日志表聚合成一張寬表每一行是一個(gè)用戶字段是“最近一次下單距今多少天”、“累計(jì)訂單金額”、“最近7天活躍天數(shù)”等聚合值。寬表的產(chǎn)出質(zhì)量決定了后面模型的上限。先別急著造高階特征先用 SQL 或 pandas 跑一遍留存率驗(yàn)證數(shù)據(jù)能和業(yè)務(wù)直覺對上。比如你定義“第7日留存率”為某天新增用戶中注冊后第7天仍有活躍行為的占比。這里的活躍行為是“登錄”還是“下單”要和業(yè)務(wù)方確認(rèn)口徑不同數(shù)字能差出一倍。我一般會先按天算一張留存矩陣確認(rèn)沒有明顯的周末效應(yīng)或數(shù)據(jù)斷檔再繼續(xù)造特征。數(shù)據(jù)樣例可以這樣理解訂單表有三個(gè)字段 user_id、order_id、order_time、amount行為日志表有 user_id、log_time、action。你的目標(biāo)是把這些變成每用戶一行。如果日志表特別大千萬級以上別在 pandas 里硬做 groupby先在數(shù)據(jù)庫或數(shù)倉里用 SQL 做預(yù)聚合只把用戶維度的統(tǒng)計(jì)結(jié)果取回來。這不是優(yōu)化建議是血淚經(jīng)驗(yàn)。2.2 留存分析的三個(gè)核心特征RFM、使用頻次與沉默期RFM 是客戶分析里的老框架Recency最近一次消費(fèi)距今多久、Frequency消費(fèi)頻次、Monetary消費(fèi)金額。在流失預(yù)測里R 的權(quán)重通常最高因?yàn)槌聊亩x本身就依賴“最近一次活躍距今多久”。F 和 M 則能區(qū)分兩類用戶高頻低客單的用戶和低頻高客單的用戶它們的流失信號完全不一樣前者可能只是最近沒下單后者可能是徹底換供應(yīng)商了。沉默期怎么定不要拍腦袋。常見做法是統(tǒng)計(jì)全體用戶相鄰兩次活躍的間隔天數(shù)取90分位數(shù)。比如你算出來90%的間隔都小于15天那“15天沒有活躍”就可以作為沉默閾值。這個(gè)閾值直接用來打標(biāo)簽在歷史數(shù)據(jù)里如果一個(gè)用戶最后一次活躍距離預(yù)測時(shí)點(diǎn)超過了15天就標(biāo)記為流失。這個(gè)標(biāo)簽定義是后續(xù)所有模型的地基得先把它寫進(jìn)配置中心而不是散落在腳本里。使用頻次特征比金額特征要穩(wěn)定。我個(gè)人的做法是先按自然周統(tǒng)計(jì)每周活躍天數(shù)再做一個(gè)28天滑動窗口的加權(quán)和時(shí)間越近權(quán)重越高。權(quán)重可以用指數(shù)衰減weight 0.95 ** (days_diff)。寫成代碼并不復(fù)雜但收益明顯因?yàn)橛脩舻慕谛袨槟Ｊ奖壤塾?jì)值更能反映當(dāng)下的狀態(tài)。注意所有特征都必須基于預(yù)測時(shí)點(diǎn)之前的數(shù)據(jù)這個(gè)“時(shí)點(diǎn)”是最后一道紅線后面避坑章會專門講。2.3 用Python把原始表轉(zhuǎn)成訓(xùn)練集完整代碼與參數(shù)說明下面這個(gè)腳本是聚合訓(xùn)練集的最小實(shí)現(xiàn)。假設(shè)你有 users.csv 和 actions.csv目標(biāo)是生成一個(gè)寬表包含 user_id、last_active_days、recent_days、recent_count、total_amount。為了后續(xù)做時(shí)間切分代碼里顯式引入 prediction_date。import pandas as pd import numpy as np # 讀數(shù)據(jù)注意解析事件時(shí)間 users pd.read_csv(users.csv, parse_dates[reg_date]) actions pd.read_csv(actions.csv, parse_dates[log_time]) prediction_date 2024-06-01 # 預(yù)測時(shí)點(diǎn)用字符串方便改 # 特征1最近一次活躍距今天數(shù) last_active ( actions.groupby(user_id)[log_time] .max() .reset_index() .rename(columns{log_time: last_active_time}) ) last_active[last_active_days] ( pd.Timestamp(prediction_date) - last_active[last_active_time] ).dt.days # 特征2/3近30天活躍天數(shù)和行為次數(shù)只統(tǒng)計(jì)預(yù)測時(shí)點(diǎn)之前的30天 window_start pd.Timestamp(prediction_date) - pd.DateOffset(days30) mask (actions[log_time] window_start) (actions[log_time] pd.Timestamp(prediction_date)) recent actions[mask].groupby(user_id).agg( recent_days(log_time, lambda x: (x.max() - x.min()).days 1), recent_count(log_time, size), ).reset_index() # 特征4累計(jì)金額 amount_agg actions.groupby(user_id)[amount].sum().rename(total_amount).reset_index() # 合并成寬表 feat users[[user_id]].merge(last_active[[user_id, last_active_days]], onuser_id, howleft) feat feat.merge(recent, onuser_id, howleft) feat feat.merge(amount_agg, onuser_id, howleft) # 沒有行為記錄的用戶用999標(biāo)記沉默時(shí)間其他缺失填0 feat[last_active_days] feat[last_active_days].fillna(999) feat[recent_days] feat[recent_days].fillna(0) feat[recent_count] feat[recent_count].fillna(0) feat[total_amount] feat[total_amount].fillna(0) print(feat.head())代碼邏輯分成三步先按 groupby 把最近一次活躍時(shí)間取出來再拿時(shí)間差得到 last_active_days第二步用條件過濾得到近30天行為數(shù)據(jù)用 agg 聚合第三步把各聚合結(jié)果在 user_id 上合并。注意 recent_days 這里用的是近似“首尾活躍時(shí)間跨度加一”如果用戶在這個(gè)窗口內(nèi)活躍不連續(xù)它會比真實(shí)活躍天數(shù)偏大。更精確的做法是 x.dt.date.nunique()但那樣在千萬級數(shù)據(jù)上會慢很多看你的數(shù)據(jù)量取舍。參數(shù)說明prediction_date 是整套系統(tǒng)的錨點(diǎn)訓(xùn)練時(shí)要把錨點(diǎn)滾動到每個(gè)歷史月份用來生成不同月份的樣本。last_active_days 用999填充是因?yàn)檫@些用戶沒有任何活躍記錄他們不是“沉默”而是“從未激活”應(yīng)當(dāng)被模型識別為特殊群體。recent_days 和 recent_count 的缺失填0代表觀察窗口內(nèi)沒有活躍行為這個(gè)0是真實(shí)事件不是缺失。真實(shí)業(yè)務(wù)中你可能還要加更多特征注冊天數(shù)、平均消費(fèi)間隔、商品類目偏好、客服反饋次數(shù)。我給的原則是先把 RFM 和沉默期做成可運(yùn)行版本再逐步加特征每加一個(gè)就用時(shí)間切分驗(yàn)證 AUC 是否真的提升而不是一味堆特征。這個(gè)系統(tǒng)里的特征工程不是一次性的它要能跟著業(yè)務(wù)周期持續(xù)迭代。提示千萬不要在造特征時(shí)混入預(yù)測時(shí)點(diǎn)之后的數(shù)據(jù)比如用“這個(gè)用戶后面有沒有下單”來填充近期行為。這是最常見的特征泄漏后面避坑章有一條專門講它。3. 流失預(yù)測模型選擇算法與調(diào)參的實(shí)戰(zhàn)思路3.1 為什么先跑邏輯回歸和XGBoost做基線模型選擇上我見過最常翻車的不是模型不夠強(qiáng)而是上來就調(diào) LightGBM 的黑匣子最后解釋不了業(yè)務(wù)方的問題“為什么他分高”。所以建議先跑邏輯回歸它的系數(shù)能直接解釋特征方向。比如 last_active_days 的系數(shù)是正說明最近一次活躍距今越久流失概率越高符合直覺。邏輯回歸作為基線也能給出一個(gè) AUC如果 XGBoost 比它高不了多少那說明特征工程才是瓶頸。XGBoost 適合表格數(shù)據(jù)對特征縮放不敏感還能自動處理缺失值。我們用它做主力模型但注意樹的深度、葉子數(shù)和正則參數(shù)會直接影響過擬合。數(shù)據(jù)量只有幾千到幾萬條的留存場景太深的樹幾乎必定過擬合。常見初始參數(shù)是 max_depth3、learning_rate0.05、n_estimators300然后用早停法選迭代輪數(shù)。這里有一個(gè)容易被忽略的點(diǎn)流失場景的正樣本往往很少。一個(gè)月流失10%用戶聽起來不少但在特征空間里樹模型很容易通過切分把這些樣本撿出來然后在驗(yàn)證集上表現(xiàn)得很好等上線遇到分布變化就失效。因此基線模型不只是看 AUC還要看它預(yù)測出的概率分布是否合理。我常用的辦法是把預(yù)測概率分桶看每個(gè)桶里的真實(shí)流失率是否單調(diào)遞增如果不是單調(diào)說明模型學(xué)到了噪聲或者特征有泄漏。3.2 流失閾值怎么定基于業(yè)務(wù)沉默天數(shù)而非模型輸出很多系統(tǒng)的預(yù)測結(jié)果是一堆0到1的概率但業(yè)務(wù)方問“那到底誰流失了”你如果回答“大于0.5的流失”這個(gè)閾值會讓運(yùn)營抓狂。正確做法是先定沉默期再根據(jù)沉默期生成歷史標(biāo)簽?zāi)Ｐ椭皇菍W(xué)“哪些特征能預(yù)測這種沉默行為”。所以模型輸出的 score 其實(shí)是“在沉默期定義下該用戶未來7天內(nèi)進(jìn)入沉默的概率”而不是絕對的流失概率。閾值的選擇取決于你的運(yùn)營資源資源多閾值調(diào)低多撈人資源少閾值調(diào)高只保重點(diǎn)。具體怎么定閾值用驗(yàn)證集畫出精確率-召回率曲線運(yùn)營能接受的精確率比如30%就選對應(yīng)的閾值。這里的精確率意思是“預(yù)測流失的人里真的流失了多少”召回率是“真流失的人里被預(yù)測到了多少”?？蛻袅舸嫦到y(tǒng)的目標(biāo)通常不是精確率最大化而是在保證一定精確率的前提下提高召回率因?yàn)槁┑粢粋€(gè)高價(jià)值用戶的損失遠(yuǎn)大于打擾一個(gè)普通用戶。如果每個(gè)用戶的貢獻(xiàn)金額已知可以把閾值做成代價(jià)敏感形式。比如一個(gè)高價(jià)值用戶流失一個(gè)月?lián)p失1000元一次無效觸達(dá)成本5元。那么只有當(dāng)預(yù)計(jì)流失概率 × 1000 5 時(shí)才值得觸達(dá)算出的閾值為0.5%。這個(gè)計(jì)算比拍腦袋強(qiáng)但前提是你有用戶貢獻(xiàn)金額數(shù)據(jù)并且愿意維護(hù)這組系數(shù)。我把這個(gè)邏輯寫進(jìn)配置每次預(yù)測后直接輸出“建議觸達(dá)”和“可以再等等”兩個(gè)名單。3.3 訓(xùn)練與評估代碼P/R曲線、AUC與代價(jià)矩陣下面的代碼展示了用邏輯回歸和 XGBoost 訓(xùn)練并比較的流程。假設(shè)你已經(jīng)有了 feat 和 labellabel 是1表示該用戶在未來一個(gè)周期內(nèi)沉默。import pandas as pd from sklearn.model_selection import train_test_split from sklearn.linear_model import LogisticRegression from xgboost import XGBClassifier from sklearn.metrics import roc_auc_score, precision_recall_curve, precision_score, recall_score # 準(zhǔn)備數(shù)據(jù)假設(shè) feat 有 user_id 和特征列l(wèi)abel 單獨(dú)一列 X feat.drop([user_id], axis1) y feat[label] X_train, X_test, y_train, y_test train_test_split(X, y, test_size0.2, random_state42) # 邏輯回歸基線 lr LogisticRegression(max_iter1000, C1.0, class_weightbalanced) lr.fit(X_train, y_train) y_prob_lr lr.predict_proba(X_test)[:, 1] print(LR AUC:, roc_auc_score(y_test, y_prob_lr)) # XGBoost 主力模型 xgb XGBClassifier( max_depth3, learning_rate0.05, n_estimators500, subsample0.8, colsample_bytree0.8, scale_pos_weightsum(y_train 0) / sum(y_train 1), eval_metriclogloss, early_stopping_rounds50, verbosity0, ) xgb.fit(X_train, y_train, eval_set[(X_test, y_test)], verboseFalse) y_prob_xgb xgb.predict_proba(X_test)[:, 1] print(XGB AUC:, roc_auc_score(y_test, y_prob_xgb)) # 根據(jù)運(yùn)營目標(biāo)選閾值 precision, recall, thresholds precision_recall_curve(y_test, y_prob_xgb) # 找精確率超過30%且召回率最高的閾值 valid [(t, p, r) for t, p, r in zip(thresholds, precision[:-1], recall[:-1]) if p 0.3] if valid: best max(valid, keylambda x: x[2]) print(建議閾值:, best[0], 精確率:, best[1], 召回率:, best[2])參數(shù)說明max_depth3 是為了控制模型復(fù)雜度當(dāng)前量級的數(shù)據(jù)不需要太深。learning_rate0.05 配合 n_estimators500讓模型一步一步走不容易在訓(xùn)練集上飆升。subsample 和 colsample_bytree 都取0.8相當(dāng)于每棵樹只用80%的樣本和特征增加隨機(jī)性減小方差。scale_pos_weight 寫成正負(fù)樣本比例的倒數(shù)讓少數(shù)類被漏掉時(shí)損失更大。early_stopping_rounds50 在驗(yàn)證集 logloss 不再下降時(shí)提前停止避免過擬合。邏輯回歸的 C1.0 是正則強(qiáng)度的倒數(shù)越小正則越強(qiáng)。如果特征之間存在共線性比如 recent_count 和 total_amount 高度相關(guān)可以調(diào)小 C 或先做標(biāo)準(zhǔn)化否則系數(shù)的絕對值大但方向不穩(wěn)定。class_weightbalanced 會自動調(diào)整正負(fù)樣本權(quán)重但代價(jià)是預(yù)測概率會出現(xiàn)整體偏移閾值也需要重新校準(zhǔn)所以我不建議在最終交付時(shí)用這個(gè)參數(shù)只把它作為基線檢查用。評估部分AUC 看整體排序能力但真正決定業(yè)務(wù)動作的是精確率和召回率的取舍。我給的這個(gè)閾值搜索邏輯是“運(yùn)營只能跟進(jìn)精確率30%以上的客戶在這個(gè)前提下挑召回率最高的點(diǎn)”這是一個(gè)可落地的折中。實(shí)際你還要看每一檔閾值下會撈到多少人、多少獎(jiǎng)勵(lì)金額這需要結(jié)合客戶分群下一章會講。4. 把系統(tǒng)打包成zip從訓(xùn)練腳本到可交付的預(yù)測工具4.1 目錄結(jié)構(gòu)設(shè)計(jì)模型文件、配置、增量更新腳本交付不是把幾個(gè) .py 丟給對方就行。一個(gè)能跑起來的客戶留存分析與流失預(yù)測系統(tǒng)至少要有訓(xùn)練腳本、預(yù)測腳本、配置文件、數(shù)據(jù)樣例、模型輸出目錄和 README。我通常按下面這樣的目錄組織retention_system/ ├── config.yaml ├── train.py ├── predict.py ├── data/ │ ├── users.csv │ └── actions.csv ├── model/ │ └── xgb_model.json └── README.md配置文件里寫數(shù)據(jù)路徑、預(yù)測時(shí)點(diǎn)、沉默閾值、模型參數(shù)、特征列表。這樣換一批數(shù)據(jù)跑的時(shí)候不用改代碼。訓(xùn)練腳本讀配置產(chǎn)出的模型放在 model/ 下。預(yù)測腳本讀配置和模型輸入當(dāng)天的特征表輸出帶 churn_score 的用戶名單。config.yaml 的樣式我一般這樣寫data: users_path: data/users.csv actions_path: data/actions.csv prediction: date: 2024-06-01 silent_days: 15 model: type: xgboost params: max_depth: 3 learning_rate: 0.05 n_estimators: 500 subsample: 0.8 colsample_bytree: 0.8 output: score_path: output/churn_scores.csv為什么用 YAML 而不是命令行參數(shù)因?yàn)檫\(yùn)營同事要改的是數(shù)據(jù)路徑和閾值不該改代碼。把參數(shù)從代碼里剝離出來這個(gè)系統(tǒng)才談得上可維護(hù)。README 里除了安裝命令還要寫清楚 Python 版本和依賴我建議用 requirements.txt并告訴對方用虛擬環(huán)境。別假設(shè)對方會用 conda直接把命令寫出來。4.2 用zipfile和命令行實(shí)現(xiàn)一鍵打包把整個(gè)文件夾打成 zip 是交付前最后一步也是需求量極高的動作。在 Linux 上最省事的命令是zip -r retention_system.zip retention_system/如果需要排除體積大的緩存目錄比如 data/raw/用zip -r retention_system.zip retention_system/ -x retention_system/data/raw/* -x *.pyc-x 參數(shù)接的是通配符排除規(guī)則*.pyc 能去掉 Python 緩存文件這個(gè)一定要加否則對方解壓后會看到一堆pycache顯得很不專業(yè)。如果輸出包要帶日期可以這樣命名retention_system_20250611.zip方便后續(xù)回溯。如果你希望打包過程可重復(fù)我建議寫成腳本尤其是當(dāng)模型文件越來越多的時(shí)候import zipfile import os def zip_dir(dir_path, zip_path, excludes): with zipfile.ZipFile(zip_path, w, zipfile.ZIP_DEFLATED) as zf: for root, dirs, files in os.walk(dir_path): for f in files: full os.path.join(root, f) rel os.path.relpath(full, dir_path) if any(ex in rel for ex in excludes): continue zf.write(full, rel) if __name__ __main__: zip_dir( retention_system, retention_system_20250611.zip, excludes[__pycache__, .pyc, /data/raw/] )這段腳本用 os.walk 遍歷目錄把文件寫入 zipZIP_DEFLATED 表示壓縮。excludes 里的子串如果出現(xiàn)在相對路徑中就跳過。這樣每次交付跑一遍python package.py就能得到新包不會漏文件。打包之前先在干凈的臨時(shí)目錄里跑一遍 train.py確認(rèn)數(shù)據(jù)路徑不是硬編碼的絕對路徑我見過太多次本地能跑、zip 包解壓到別處就報(bào) FileNotFoundError 的情況原因就是代碼里寫了C:/Users/xxx/data/actions.csv。路徑要寫成相對于配置文件的相對路徑或者運(yùn)行時(shí)自動獲取腳本所在目錄。4.3 交付后如何運(yùn)行解壓即用的最小命令與驗(yàn)證交付后對方第一步是解壓。如果對方拿到的包是加密的先要移除 zip 密碼通常做法是問打包人要密碼別去用什么暴力破解工具那是給自己找坑。解壓后按 README 跑python -m venv .venv source .venv/bin/activate pip install -r requirements.txt python train.py --config config.yaml python predict.py --config config.yaml --score output/churn_scores.csv預(yù)測腳本里要加一個(gè) --score 參數(shù)讓結(jié)果輸出到指定路徑。第一次運(yùn)行完驗(yàn)證三步訓(xùn)練日志里有沒有 AUC 指標(biāo)預(yù)測輸出里 churn_score 是不是0到1之間的分布隨機(jī)抽一個(gè)明顯很久沒活躍的用戶看他的 score 是否偏高。如果這幾步都正常系統(tǒng)才算真正跑通。我還會給一個(gè)最小驗(yàn)證清單像這樣檢查項(xiàng)命令/操作期望結(jié)果訓(xùn)練能跑通python train.py --config config.yaml輸出 AUC 和模型文件預(yù)測能跑通python predict.py --score output/churn_scores.csv輸出 CSV 且不少于100行概率分布合理查看 score 列大部分在0.1~0.5之間少量接近1沉默用戶命中抽查 15 天未活躍的用戶score 排名靠前跨平臺注意點(diǎn)Windows 上壓縮的 zip 在 Linux 解壓后中文文件名容易亂碼所以項(xiàng)目文件和 README 最好都用英文命名內(nèi)容可以中文。另外 zip 包里的換行符也會在跨平臺時(shí)出問題代碼文件盡量用 LF 換行這個(gè)可以在打包前用 dos2unix 統(tǒng)一一下。如果對方要在 Windows 上跑記得把 .venv 相關(guān)命令換成venv\Scripts\activateREADME 寫兩個(gè)版本。5. 客戶流失預(yù)測落地避坑這5個(gè)問題最容易翻車5.1 現(xiàn)象訓(xùn)練時(shí)AUC很高上線后預(yù)測全偏向不流失這是一個(gè)典型的“離線很爽、線上翻車”的例子。我見過有人把 AUC 做到 0.98結(jié)果第二輪預(yù)測出來的高分用戶全是些已經(jīng)消失很久的老用戶對運(yùn)營毫無指導(dǎo)意義。原因是特征泄漏造特征時(shí)用了未來數(shù)據(jù)離線驗(yàn)證時(shí)又用隨機(jī)切分而不是時(shí)間切分模型在訓(xùn)練集里見過“答案”了。解決方法是嚴(yán)格按時(shí)間切分用預(yù)測時(shí)點(diǎn)之前的數(shù)據(jù)訓(xùn)練之后的數(shù)據(jù)驗(yàn)證特征工程里禁用未來函數(shù)。檢查方法也很簡單把預(yù)測時(shí)點(diǎn)換個(gè)時(shí)間窗口看 AUC 是否基本穩(wěn)定如果大幅下跌先查特征里有沒有用到標(biāo)簽信息。5.2 現(xiàn)象新用戶沒有歷史數(shù)據(jù)特征全部為空新注冊用戶沒有近30天活躍記錄也沒有累計(jì)金額模型會給它們一個(gè)不高不低的分?jǐn)?shù)。但運(yùn)營真正關(guān)心的是“剛進(jìn)來還沒留存的用戶”你如果只用一個(gè)模型覆蓋所有用戶新用戶永遠(yuǎn)被忽略。原因是沒有區(qū)分用戶生命周期階段。解決方法是先給每個(gè)用戶打一個(gè) has_history 標(biāo)志注冊不足30天的用戶單獨(dú)建模或者用冷啟動特征比如注冊渠道、注冊時(shí)間、首日是否完成關(guān)鍵行為。在填充缺失時(shí)不要一律用0因?yàn)?可能表示“沒有行為”也可能表示“不適用”建議同時(shí)保留一個(gè)“數(shù)據(jù)不足”標(biāo)記列。5.3 現(xiàn)象zip包換臺機(jī)器跑路徑全是反斜杠錯(cuò)誤這類問題幾乎每個(gè)交付的人都踩過。代碼里寫了 Windows 的絕對路徑C:\Users\xxx\data\actions.csv打包到 Linux 服務(wù)器或 Mac 上跑一啟動就報(bào)文件不存在。原因很簡單路徑分隔符硬編碼。解決方法是統(tǒng)一用 pathlib.Path 拼接路徑配置里的路徑全部寫成相對路徑然后在代碼入口通過Path(__file__).parent定位項(xiàng)目根目錄。打包前我還會用grep -r C:掃一遍代碼看到絕對路徑就先改掉再壓縮省得對方解壓后拿著日志截圖來找你。5.4 現(xiàn)象流失標(biāo)簽定義錯(cuò)了模型學(xué)到的其實(shí)是“定義本身”這是最隱蔽的坑。我見過有人把“近30天無活躍”當(dāng)作流失標(biāo)簽但特征里又包含“近30天活躍次數(shù)”。標(biāo)簽和特征直接重疊模型根本不是在預(yù)測而是在把特征里的0映射成標(biāo)簽里的1AUC自然很高上線后卻一無是處。解決方法是標(biāo)簽和特征之間必須有嚴(yán)格的時(shí)間間隔。用 t-1 月的特征預(yù)測 t 月是否沉默特征窗口和標(biāo)簽窗口不交叉。我在代碼里把 prediction_date 作為硬邊界生成樣本時(shí)確保特征截止日比標(biāo)簽開始日早至少一個(gè)沉默期。5.5 現(xiàn)象模型每周要重訓(xùn)數(shù)據(jù)量太大內(nèi)存直接崩客戶留存系統(tǒng)的數(shù)據(jù)是不斷累積的幾周后全量行為日志可能過億行。直接用 pandas 讀進(jìn)來做 groupby內(nèi)存很容易撐爆。原因不是代碼寫錯(cuò)而是聚合方式不適合增量場景。解決方法是把特征聚合下沉到數(shù)據(jù)庫或數(shù)倉用 SQL 先算好每周的最新統(tǒng)計(jì)量Python 只負(fù)責(zé)讀寬表。如果一定要在 Python 里做可以按用戶分片用 Dask 或 Polars 代替 pandas另外把用戶ID、渠道ID這些低基數(shù)字段轉(zhuǎn)成 category 類型能省不少內(nèi)存。更聰明的做法是設(shè)計(jì)成增量特征表每周只更新近30天的窗口統(tǒng)計(jì)歷史累計(jì)值用上次結(jié)果加本周增量而不是全量重算。6. 進(jìn)階用生存分析和流失概率做分群運(yùn)營6.1 為什么不只預(yù)測“會不會流失”還要預(yù)測“還有多久”流失預(yù)測給的是一個(gè)概率但運(yùn)營接到名單后會問下一句“他還能留多久”如果預(yù)測發(fā)現(xiàn)一個(gè)用戶本月會流失觸達(dá)動作可以更緊一點(diǎn)如果預(yù)測他三個(gè)月后才流失那可能是正常的使用周期不需要打擾。生存分析解決的正是“還要多久”的問題。它不把流失當(dāng)成一個(gè)二分類標(biāo)簽而是把每個(gè)用戶看成一個(gè)帶時(shí)間的事件樣本輸出的是“存活到下一個(gè)周期”的概率曲線。6.2 用lifelines做Cox回歸的落地代碼我常用 lifelines 庫跑 Cox 比例風(fēng)險(xiǎn)模型。它接受兩條信息用戶觀察時(shí)長 T以及是否在觀察期內(nèi)流失 E。下面是最小用法from lifelines import CoxPHFitter df_surv feat.copy() df_surv[T] df_surv[observe_days] # 從第一次活躍到觀察結(jié)束的天數(shù) df_surv[E] df_surv[label] # 1流失0未流失 cph CoxPHFitter() cph.fit(df_surv[[T, E, last_active_days, recent_count, total_amount]], duration_colT, event_colE) cph.print_summary()Cox 模型的參數(shù)解讀比樹模型直觀如果 last_active_days 的風(fēng)險(xiǎn)比大于1說明最近一次活躍距今越久流失風(fēng)險(xiǎn)越高。有了存活曲線你還可以對每個(gè)用戶預(yù)測未來30天的存活概率把概率和 XGBoost 的流失分結(jié)合做一個(gè)二維分群高流失分且低存活概率的優(yōu)先觸達(dá)高流失分但存活概率還高的可能是需要長期培育的用戶不用急著打擾。6.3 從預(yù)測到行動生命周期積分卡與觸達(dá)時(shí)機(jī)最后這套系統(tǒng)真正產(chǎn)生價(jià)值的不是模型文件而是那張輸出名單。我會把預(yù)測結(jié)果做成一張積分卡流失風(fēng)險(xiǎn)分、預(yù)計(jì)剩余活躍天數(shù)、用戶貢獻(xiàn)等級、最近觸達(dá)時(shí)間。運(yùn)營只需要關(guān)注“預(yù)計(jì)剩余活躍天數(shù)小于30天”的用戶再結(jié)合風(fēng)險(xiǎn)分決定用短信還是電話。我第一次上線時(shí)只顧著把 AUC 調(diào)高忽略了閾值和行動策略結(jié)果運(yùn)營拿著一張全是中低分用戶的名單不知道干嘛。后來我把閾值和觸達(dá)成本寫進(jìn)配置每個(gè)月復(fù)盤一次預(yù)測命中率這個(gè)系統(tǒng)才算真正轉(zhuǎn)起來了。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取