用户流失判断需结合last_active_time、session_duration_avg、page_views_per_session三者加权打分；优惠券发放须异步队列处理，预热code池，禁用动态拼接模板，避开竞品活动日与睡眠期，按渠道优先级分层触达，设48小时有效期，绑定recall_id归因，短信带utm参数，灰度验证转化率＞3%再全量，召回后72小时追踪二次沉默并动态调整策略。
用户流失判断不能只看登录时间
很多团队用「最近7天未登录」当流失标准，但实际要结合行为深度：比如用户上周刚下单、本周没登录，可能只是正常消费间歇；而连续3天打开APP又秒退，配合页面停留＜5秒，才是高危信号。建议用组合条件：last_active_time + session_duration_avg + page_views_per_session 三者加权打分，而不是单字段阈值硬切。
优惠券发放必须走异步队列，别在HTTP响应里发
直接调用短信网关或优惠券生成接口会拖慢主流程，尤其在批量召回时容易超时或触发限流。常见错误是把 sendSms() 写在控制器里，结果用户点个按钮等8秒——其实90%的召回请求根本不需要实时反馈。
- 用
php-resque或laravel horizon接收召回任务，入队后立刻返回{ "status": "queued", "id": "recall_abc123" } - 优惠券生成务必预热：提前生成好
coupon_code池，避免发券时实时加密+DB写入成为瓶颈 - 短信模板里禁用动态变量拼接，改用平台支持的占位符（如
{name}），否则模板审核不通过或触发敏感词拦截
召回时机要避开用户睡眠期和竞品活动日
凌晨2点发5元无门槛券，打开率通常不到0.3%；而周三上午10:15发，配合「今日限定」标签，转化能翻2倍。更关键的是查竞品日历：getCompetitorPromotionDays() 返回数组，召回任务调度前先过滤掉这些日期。
- 用户时区必须从
user.timezone字段取，别用服务器本地时间 - 首次召回用短信，二次用APP Push，三次才发邮件——渠道优先级错了，后续所有动作都白搭
- 优惠券有效期建议设为48小时，太短来不及决策，太长（如7天）会让用户觉得“随时能领”，反而降低紧迫感
召回效果必须绑定归因ID，否则算不清ROI
不带追踪参数的优惠券等于扔钱。每次生成券必须嵌入唯一 recall_id，并记录到 recall_log 表；用户核销时，券表的 used_at 要反查这个ID，才能确认是哪次召回带来的成交。
- 短信链接必须带UTM参数，例如
https://a.com/coupon?rid=rec_789&src=sms_wed - 别用
$_SESSION存召回上下文——用户换设备、清缓存就断链了 - 灰度上线时，先对5%用户开召回，观察
recall_conversion_rate是否＞3%，再全量；低于1.5%说明策略或人群选错了
最常被跳过的一步：召回后的72小时内，必须检查用户是否再次沉默。如果发券后仍无任何行为，下次召回就得换策略——比如把通用券换成他上次浏览品类的定向券，而不是继续塞满减。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
