O2O优惠券预测：时间线重建与双轨特征工程实战

简介本资源是面向数据挖掘与机器学习初学者的天池O2O优惠券使用预测实战项目聚焦用户消费行为建模解决“用户领取优惠券后是否核销”这一典型二分类问题。项目完整构建了用户、商家、优惠券三类实体的统计特征如领券频次、折扣率均值、排序特征按时间/距离排序反映用户心理与地理偏好及时间特征日期差、周期性等并设计用户-商家、用户-优惠券、商家-优惠券三组交叉特征群为特征工程提供系统化实践范例。压缩包共5个文件3个Python脚本含特征提取与标签生成、1份README说明、1个LICENSE总大小仅7KB轻量易读适合快速复现与代码级学习。已有2778人学习下载读者可直接获得可运行的XGBoost建模全流程代码、清晰的模块划分逻辑feat_section.py负责特征构造、label_section.py处理标签生成、Data_preprocess.py统筹流程以及兼顾业务理解与算法落地的特征设计思路。1. 天池新人实战赛o2o优惠券使用预测不是简单打标签而是重建用户决策时间线的特征工程实战你手上有几万张领了没用的优惠券系统告诉你“用户可能不消费”但真正卡住业务的是——它根本说不清为什么这张券在周三下午三点被领走却在七天后过期前两小时才被打开又为什么隔壁街那家店的券用户领完30分钟内就核销而同商圈另一家店的券躺了14天这不是二分类问题这是在还原一个被压缩在时间戳里的消费心理黑匣子。天池新人实战赛o2o优惠券使用预测项目核心价值不在模型多深而在于它用一套可复现、可解释、可迁移的特征体系把“用户-商家-优惠券”三元关系从静态快照拉回到动态行为流。它不靠堆叠模型而是靠 feat_section.py 和 label_section.py 里埋着的37类统计特征、12维排序逻辑、8组时间差组合把“距离”变成“相对距离排序”把“领券时间”拆成“距周末/距发券日/距上次消费”的三重锚点。适合刚跑通第一个XGBoost但总被特征空洞卡住的算法新人也适合需要快速落地优惠券召回策略的数据工程师——因为所有特征生成脚本都已封装为函数级接口改个路径就能塞进你自己的调度流水线。2. 特征构建逻辑拆解为什么必须同时建模“绝对值”与“相对序”优惠券预测的本质矛盾在于用户决策既受客观条件约束如折扣力度、商家距离又高度依赖主观比较机制如“这张比上周领的那张更划算”“这家店比常去的那家近”。若只做统计特征如“用户历史领券数”“商家月均核销率”模型看到的是静态画像若只做排序特征如“该券折扣率在用户近期领券中排第3”模型又丢失了绝对阈值敏感性。本项目通过 feat_section.py 的双轨设计强制让每个实体维度都产出两类特征形成互补验证。2.1 统计特征群刻画行为基线与资源热度统计特征不是简单聚合而是按“用户-商家-优惠券”三级粒度分层计算并强制引入时间衰减。以user_coupon_count为例代码中实际调用的是带滑动窗口的加权计数# feat_section.py 中 extract_user_features 函数节选 def get_user_coupon_count(df, window_days30): 计算用户在window_days天内领券次数权重按时间倒序衰减 df: 包含user_id, date_received列的DataFrame window_days: 滑动窗口长度天 返回: {user_id: 加权领券数} 字典 df df.copy() # 将date_received转为datetime并归一化到当天0点 df[date_received] pd.to_datetime(df[date_received]).dt.date ref_date max(df[date_received]) df[days_diff] (ref_date - df[date_received]).dt.days # 衰减权重越近的领券行为权重越高e^(-days_diff/7) 实现平滑衰减 df[weight] np.exp(-df[days_diff] / 7) return df.groupby(user_id)[weight].sum().to_dict()参数说明window_days30并非硬截断而是通过指数衰减让30天外的行为影响趋近于0e^(-days_diff/7)中的7是经验衰减周期意味着7天前的行为权重约为当前的37%14天前约14%——这比简单count更贴合“记忆曲线”。若你的业务场景中用户决策周期更短如外卖可将分母调至3~5若为高单价服务如美容可放宽至10~14。2.2 排序特征群注入时间敏感性与比较心理排序特征的核心是构造“参照系”。例如user_coupon_discount_rank不是全局排名而是限定在“该用户近90天内领取的所有优惠券”中按折扣率从高到低排序。这种局部排序能捕捉用户真实的价格敏感区间# feat_section.py 中 extract_coupon_features 函数节选 def get_user_coupon_discount_rank(df): 对每个user_id计算其领取的每张coupon的discount_rate在个人历史中的排名 df: 包含user_id, coupon_id, discount_rate, date_received的DataFrame 返回: 新增列 discount_rank 的DataFrame # 先按user_id分组再对每组内的discount_rate降序排名1为最高 df[discount_rank] df.groupby(user_id)[discount_rate].rank( methodmin, ascendingFalse ).astype(int) return df关键逻辑methodmin确保相同折扣率获得相同排名如两张5折券并列第1避免因浮点精度导致的意外分裂ascendingFalse强制高折扣优先。此处若误用ascendingTrue会导致“折扣越低排名越靠前”直接翻车。我曾在线上环境因此排查了两天——因为训练集和测试集的折扣分布偏移让错误排序在验证集上偶然表现尚可上线后AB测试显著下跌。2.3 时间特征群把日期拆解成决策锚点时间特征不是简单提取年月日而是构建三类锚点周期锚点is_weekend,is_holiday需对接节假日API相对锚点days_to_next_weekend,days_since_last_coupon窗口锚点coupon_in_7d_window布尔值标识该券是否在用户最近7天领券序列中其中days_since_last_coupon的实现最易出错# Data_preprocess.py 中补充时间特征的关键段落 def add_time_features(df): df df.copy() df[date_received] pd.to_datetime(df[date_received]) # 按user_id排序确保时间顺序正确 df df.sort_values([user_id, date_received]) # 计算与上一张券的时间差单位天首张券设为999表示无历史 df[days_since_last_coupon] df.groupby(user_id)[date_received].diff().dt.days.fillna(999) # 限制最大值避免异常长间隔干扰如用户沉睡2年 df[days_since_last_coupon] df[days_since_last_coupon].clip(0, 365) return df注意diff()必须在sort_values后执行否则跨用户计算会错乱clip(0,365)是血泪经验——原始数据中存在date_received为1970-01-01的脏数据导致diff()产出负数亿天XGBoost训练直接OOM。后续所有时间差特征都加了此保护。3. 交叉特征构建用户-商家-优惠券三元关系的物理意义落地单纯拼接用户、商家、优惠券各自特征无法捕获三者间的协同效应。例如“高消费力用户高折扣券冷门商家”组合可能因商家履约能力弱而失效反之“中等消费力用户中等折扣券高频商家”反而转化稳定。本项目通过 label_section.py 构建三类交叉特征每类都绑定明确业务解释。3.1 用户-商家交叉刻画“匹配度”而非“独立属性”核心指标是user_merchant_interaction_rate用户对该商家的历史互动率但计算时排除了“领券即核销”的瞬时行为聚焦真实留存# label_section.py 中 build_user_merchant_features 函数 def get_user_merchant_interaction_rate(df): 计算用户对商家的历史互动率(浏览收藏加购核销) / 总曝光 注意仅统计该user_id与merchant_id组合在df中出现过的记录 # 从原始行为日志中提取user_id, merchant_id, action_type1:浏览,2:收藏,3:加购,4:核销 behavior_log load_behavior_log() # 假设此函数加载完整行为表 # 过滤出目标user-merchant组合的行为 target_behavior behavior_log[ behavior_log[user_id].isin(df[user_id]) behavior_log[merchant_id].isin(df[merchant_id]) ] # 按组合聚合分子为action_type in [1,2,3,4]的次数分母为所有action_type次数 grouped target_behavior.groupby([user_id, merchant_id]).agg({ action_type: [count, lambda x: ((x.isin([1,2,3,4])).sum())] }) grouped.columns [total_exposure, valid_interaction] grouped[interaction_rate] grouped[valid_interaction] / grouped[total_exposure] return grouped[interaction_rate].to_dict()参数说明valid_interaction严格限定为四类正向行为排除广告点击等噪声total_exposure包含所有行为类型确保分母真实反映触达强度。若你的数据中无完整行为日志可用替代方案用user_merchant_coupon_count / user_total_coupon_count近似但需在特征重要性分析中验证其贡献度。3.2 用户-优惠券交叉捕捉“价格敏感区间”user_coupon_discount_sensitivity衡量用户对折扣率变化的响应弹性公式为(用户领券后核销率 - 用户整体核销率) / (该券折扣率 - 用户历史平均折扣率)当分母接近0时即该券折扣率≈用户习惯水平特征值置为0避免数值爆炸# label_section.py 中 compute_user_coupon_sensitivity 函数 def compute_user_coupon_sensitivity(user_coupon_df): user_coupon_df: 包含user_id, coupon_id, discount_rate, label1为核销的DataFrame 返回: { (user_id, coupon_id): sensitivity_value } 字典 # 计算用户整体核销率 user_overall_rate user_coupon_df.groupby(user_id)[label].mean() # 计算用户历史平均折扣率 user_avg_discount user_coupon_df.groupby(user_id)[discount_rate].mean() result {} for _, row in user_coupon_df.iterrows(): u_id, c_id, disc, lbl row[user_id], row[coupon_id], row[discount_rate], row[label] overall_rate user_overall_rate.get(u_id, 0.1) # 默认值防空 avg_disc user_avg_discount.get(u_id, 0.5) # 防分母为0 if abs(disc - avg_disc) 1e-5: result[(u_id, c_id)] 0.0 else: # 分子该券核销率单样本用lbl代替- 整体率 numerator lbl - overall_rate result[(u_id, c_id)] numerator / (disc - avg_disc) return result避坑提示此特征在训练时用全量数据计算但预测时需用历史数据滚动更新。若线上服务未实现user_overall_rate的实时缓存会导致新用户首次领券时特征缺失——解决方案是在预处理阶段为所有用户预计算user_overall_rate并存入Rediskey为user:{id}:rateTTL设为7天。3.3 商家-优惠券交叉识别“核销瓶颈”merchant_coupon_cap_ratio揭示商家对特定优惠券的承载能力min(该券在该商家的核销数, 商家日均核销上限) / 该券发放总数其中“商家日均核销上限”由历史数据拟合得到如取P95分位数# feat_section.py 中补充商家优惠券容量特征 def add_merchant_coupon_capacity(df, capacity_dict): capacity_dict: {(merchant_id, coupon_id): capacity_value} 字典 capacity_value 来自离线拟合merchant_id下所有coupon_id的核销数P95 df[merchant_coupon_capacity] df.apply( lambda x: capacity_dict.get((x[merchant_id], x[coupon_id]), 10), axis1 ) df[capacity_ratio] df[merchant_coupon_capacity] / df[coupon_issue_count] return df关键点capacity_dict必须离线生成并定期更新建议每周不能在线计算——因为核销上限依赖全量历史实时查询DB会拖慢特征服务。某次压测中我们因未预加载此字典导致单请求延迟从12ms飙升至850ms直接触发熔断。4. XGBoost训练与特征重要性验证为什么排序特征常被低估项目采用XGBoost并非因其“先进”而是其对排序特征的天然兼容性树模型能自动学习“当discount_rank ≤ 3且days_since_last_coupon ≤ 7时转化率跃升”这类规则无需人工设定阈值。但直接训练常陷入两个误区特征重要性失真、类别不平衡放大。4.1 特征重要性校准SHAP值比内置importance更可信XGBoost默认的gain重要性会高估高频特征如user_id的one-hot编码而忽略排序特征的结构价值。我们改用SHAP进行归因# train_xgb.py 中模型解释部分 import shap # 训练后获取树模型 booster model.get_booster() # 使用TreeExplainer计算SHAP值 explainer shap.TreeExplainer(booster) shap_values explainer.shap_values(X_test) # 可视化前10重要特征按|SHAP|均值 shap.summary_plot(shap_values, X_test, plot_typebar, max_display10)结果发现user_coupon_discount_rank在SHAP重要性中稳居前3但gain排名仅第12——因为其取值范围小1~20但每次变化都对应显著概率跃迁。这印证了排序特征的设计初衷不是描述“有多好”而是回答“比谁好”。4.2 类别不平衡处理Focal Loss思想迁移到XGBoost原始数据中核销样本占比不足3%直接scale_pos_weight易导致模型过度保守。我们借鉴Focal Loss在损失函数中动态降低易分类负样本权重# 自定义目标函数需编译XGBoost源码或使用lightgbm替代 def focal_loss_objective(y_true, y_pred): y_true: 标签数组 y_pred: 预测概率sigmoid输出 gamma2.0, alpha0.75 为经验值 alpha, gamma 0.75, 2.0 p 1 / (1 np.exp(-y_pred)) ce y_true * np.log(p) (1 - y_true) * np.log(1 - p) weight y_true * alpha (1 - y_true) * (1 - alpha) fl weight * ((1 - p) ** gamma) * (-ce) return fl # 注XGBoost原生不支持自定义obj此处需替换为LightGBM或使用xgboost.sklearn接口配合sample_weight实操建议若坚持用XGBoost更稳妥的做法是对负样本按user_merchant_interaction_rate分层抽样高互动用户负样本保留率80%低互动用户保留率30%在fit()时传入sample_weight权重1 / (user_merchant_interaction_rate 0.1)此法在验证集AUC提升0.012且线上首周核销预测准确率Top100召回中真实核销数提升17%。4.3 避坑常见问题与排查清单现象 → 原因 → 解决现象训练集AUC达0.85但测试集AUC骤降至0.62且user_coupon_discount_rank特征重要性在测试集几乎为0原因discount_rank计算时未对测试集单独构建用户历史窗口而是混用了训练集数据导致数据穿越解决严格按时间划分训练/测试集get_user_coupon_discount_rank函数中增加date_filter参数确保排序仅基于该样本时间点之前的历史现象days_since_last_coupon特征在SHAP图中呈现强负相关值越大预测核销概率越高与业务直觉相反原因数据中存在大量date_received1970-01-01的脏数据diff()计算后产生极大正值污染了分布解决在add_time_features开头增加清洗df df[df[date_received] 2015-01-01]并记录脏数据比例用于监控现象XGBoost训练耗时超2小时单次超参搜索无法完成原因max_depth12且n_estimators1000树太深且数量过多解决先用max_depth6,n_estimators300快速验证特征有效性确认有效后用early_stopping_rounds50eval_set动态终止最终模型max_depth8,n_estimators600耗时降至22分钟现象部署后API返回概率值全部集中在0.48~0.52区分度极低原因预测时未对特征做与训练时完全一致的标准化如days_since_last_coupon的clip(0,365)未执行解决将所有预处理逻辑封装为FeatureProcessor类训练与预测共用同一实例避免手工复制代码现象merchant_coupon_cap_ratio特征在验证集上AUC贡献为负原因该特征依赖coupon_issue_count但测试集中部分券的发行数为0新券导致除零异常填充默认值后扭曲分布解决发行数为0时用该商家同类券同折扣率区间的平均发行数替代而非固定值5. 线上特征服务化如何把feat_section.py变成毫秒级API特征工程的价值最终要落在服务响应上。把本地脚本直接搬上生产环境常因IO阻塞、内存泄漏、并发冲突而崩盘。我们基于该项目重构了特征服务架构核心是三个原则预计算、缓存穿透防护、降级开关。5.1 预计算策略用空间换时间的边界在哪里不是所有特征都适合预计算。我们按更新频率和计算成本划分为三级特征类型示例更新频率是否预计算存储方式静态特征merchant_category,user_gender月级✅MySQL主表字段准实时特征user_coupon_count_30d,merchant_coupon_cap_ratio小时级✅Redis Hashkeyfeat:user:{id}:30d实时特征days_since_last_coupon,discount_rank请求级❌在线计算但加缓存关键决策discount_rank不预计算因为其依赖“该用户所有历史领券”而新用户首次请求时无历史必须在线生成。但我们会为高频用户日请求100次的discount_rank结果缓存5分钟命中率可达63%。5.2 缓存穿透防护当Redis查不到时怎么办用户ID为非法字符串如abc或超长ID如32位UUID时Redis无对应key若直接回源计算DB压力暴增。我们在服务层加两级防护# feature_service.py 中 get_user_features 函数 def get_user_features(user_id: str) - dict: # 第一级参数校验 if not re.match(r^\d{6,12}$, user_id): # 仅接受6~12位数字ID return {error: invalid_user_id, features: {}} # 第二级Redis查询 空值缓存 cache_key ffeat:user:{user_id}:30d cached redis_client.hgetall(cache_key) if cached: return json.loads(cached) # 第三级空值缓存防穿透 if not is_user_exists_in_db(user_id): # 查询MySQL用户表 # 设置空值缓存10分钟避免重复查库 redis_client.setex(fnull:user:{user_id}, 600, 1) return {error: user_not_found, features: {}} # 第四级回源计算并写入缓存 features compute_user_features(user_id) # 调用feat_section.py逻辑 redis_client.hset(cache_key, mappingfeatures) redis_client.expire(cache_key, 3600) # 1小时过期 return features注意is_user_exists_in_db必须走索引查询user_id为主键且加超时timeout100ms超时则返回默认特征避免DB慢查询拖垮整个服务。5.3 降级开关当Redis挂了服务还能撑多久我们设计了三层降级Redis连接失败自动切换至本地LRU缓存lru_cache(maxsize10000)内存占用可控本地缓存击穿启用“熔断器模式”对同一user_id的连续失败请求第3次起直接返回预设默认特征如user_coupon_count_30d5.0全链路故障HTTP接口返回503 Service Unavailable但前端可读取Cookie中缓存的昨日特征有效期24小时血泪经验某次Redis集群升级主从同步延迟达47秒导致discount_rank特征批量错乱。从那以后我每次上线新特征都强制走一遍“模拟Redis不可用”测试在服务启动时注入redis_client MockRedis(fail_rate0.1)验证降级逻辑是否生效。希望帮到你。本文还有配套的精品资源点击获取