客户复购预测真的值得做吗？从业务目标、方案取舍到上线验收

上一篇《从一家小店看懂数仓与机器学习先理业务再串技术》沿着小林的店把交易、客户状态、数仓与预测连接了起来。接下来还有一组更难的问题这件事值得投入吗普通规则是否已经够用模型分数更好为什么业务未必受益如果每天有人依赖名单工作什么才算真正交付本文继续使用小林的虚构小店并扩大教学场景讨论从明确目标到上线验收的判断过程。人数、成本、阈值与试验安排均为示例设定不是真实经营或上线结果。文中的“P7式判断”指在明确业务范围内对目标、取舍、交付、风险和结果承担较完整的责任不对应任何公司的正式职级标准也不意味着掌握一套模板就达到某个职级。文章目录一、先讲业务小林真正想改善的是什么1. 店变大了问题也变了2. 把需求拆成三个可检验的问题3. 先解决眼前痛点不必把全部问题绑在模型上4. 先算一笔账命中购买者不等于增加购买5. 为什么要分别回答“维护值得做”和“模型值得加”二、把业务判断变成方案选择1. 四种方案都应该有机会被选择2. 把“模型值得做”的理由写成可被否定的假设3. 首期范围要能独立交付三、再讲技术业务约束怎样推导出系统设计1. 先把责任分开再选择组件2. 一条可验收的输入合同3. 从输入到可使用名单中间有一道发布门4. “同一批数据”还不够训练与使用必须一致5. 名单策略要能解释也要能重放6. 失败时业务要怎样继续7. 一次业务任务可以有多次技术尝试四、上线验收分数、系统和业务分别证明什么1. 离线验收先证明判断有依据2. 工程验收再证明使用方拿得到、用得对3. 影子运行先观察不改变实际选择4. 小范围试验公平比较行动策略5. 业务验收证据不够时结论就是尚未证明五、把P7式判断落实成一份决策记录1. 记录决定、依据与改变决定的条件2. 责任边界不是所有问题都由算法负责3. 三种都合理的交付结果六、复习章节十分钟重建判断过程1. 记住六个问题2. 概念速查3. 五道自测题4. 十分钟复习安排延伸阅读与说明一、先讲业务小林真正想改善的是什么1. 店变大了问题也变了上一章只有几位客户店主看账本就能作判断。现在把故事推进一步小店已积累更多客户每批约有3000位符合历史购买与可联系条件的老客户店员最多联系600人。目前店员凭印象选人选择过程不一致有时不同店员重复联系同一客户有时名单交付太晚错过工作安排。维护做完了也说不清比不做多带来多少购买。小林于是提出“能不能做个复购预测系统自动告诉我应该联系谁”负责项目的小周没有立即选择算法。他先追问想改善的是挑名单耗时、重复打扰还是维护带来的利润这几件事可以同时存在但对应的解法和证据不同。2. 把需求拆成三个可检验的问题小周和小林把目标分开问题需要看到什么改善工作是否更省事名单按时交付、少花人工、减少重复联系判断是否更有依据同样人数下比普通规则更能识别后续购买者经营是否更划算联系带来的增量贡献能覆盖触达与系统成本只要现有数据足够清楚前一项可能通过规则和流程就能改善。第二项需要历史检验第三项还需要观察实际行动的效果。因此“做一个预测系统”是一种方案表达。真正需求应先写成“在有限人员下稳定安排客户维护并判断这件事是否产生值得继续的收益。”3. 先解决眼前痛点不必把全部问题绑在模型上两人决定先建立一份稳定名单统一购买定义排除近期已经联系的人按简单规则排序并记录执行情况。这一步的直接价值是减少名单整理与重复联系。即使后来发现模型没有额外收益这些改进仍然可以保留但要实测节省多少工作不能预先算作已实现收益。同时把模型放在候选位置与普通规则使用同一人群、同一时点和同一预算比较。只有证据支持才增加后续投入。4. 先算一笔账命中购买者不等于增加购买假设某份600人名单中60%的人后来购买即360人。仅凭这个数字不能说维护增加了360位购买者因为其中很多人可能不联系也会买。即使新模型把名单命中率从60%提高到62%多找到的12位购买者也不等于多创造了12位购买者。模型可能只是更擅长找出本来就会回来的人。立项时可以先做一笔简化的盈亏测算。以下全部是假设项目教学设定每批最多联系人数600人每人联系成本2元每位增量购买客户平均贡献40元分摊到每批的模型维护成本300元这里40元是简化的贡献估计已考虑示例中约定的商品、履约与优惠成本但尚未扣联系与模型维护成本它不是交易额。如果联系使这600人的购买概率平均增加6个百分点那么估计为增量购买客户 600 × 0.06 36人 增量贡献 36 × 40 1440元 联系成本 600 × 2 1200元 维护成本 300元 估计净增量 1440 - 1200 - 300 -60元在这个简化模型中盈亏平衡需要增加37.5位购买客户即平均提升6.25个百分点所需平均购买概率提升 (1200 300) / (600 × 40) 6.25个百分点6.25个百分点是这组成本假设推导出的门槛不是行业标准也不是模型必须提升的AP或准确率。它还没有计入初期开发、机会成本以及其他可能的损益。真实效果评价应比较各组全部客户的实际贡献避免遗漏本来就会购买者的优惠损失、客单价变化或购买时间提前。这个小公式用于检查投入是否合理不能代替经营试验。5. 为什么要分别回答“维护值得做”和“模型值得加”即使客户维护本身赚钱也不意味着复杂模型值得做。因为一条普通规则可能已经得到相近效果维护成本却更低。因此需要两个比较开展维护 与 不开展维护 → 判断维护有没有增量价值 模型名单 与 普通规则名单 → 判断模型有没有额外价值第二个比较关注额外收益能否覆盖额外成本。不能把整项维护工作的收益全部归功于模型也不能把模型费用当成唯一投入。二、把业务判断变成方案选择1. 四种方案都应该有机会被选择小周提出四条路径方案适合的条件主要代价保留人工选择统一记录人少、工作量小、经验较丰富难扩展过程不稳定购买频次、最近性等规则数据有限需要快速稳定交付表达能力有限需明确规则规则之外试验机器学习有较长历史普通规则仍有明显不足训练、验证、解释与维护成本增加暂停名单优化先补数据购买或联系记录不可信暂时得不到预测收益选择依据是实际问题、证据与约束。数据还不可靠时优先补证据规则够用时先把规则交付好。Google的ML工程指南也强调先建立指标与可靠流程允许先使用启发式办法。参考Rules of ML2. 把“模型值得做”的理由写成可被否定的假设小周不能只写“引入机器学习提升智能化水平”。他需要提出可以被检验的理由在统一人群与预算下模型能否比当前规则更好地识别后续购买者并在实际维护中带来足以覆盖额外成本的增量贡献如果离线比较没有改善不急于进入模型上线离线改善但行动效果尚不确定先限定试验行动收益覆盖不了成本就调整或停止模型投入。这样“继续”“暂缓”“停止”都是预先允许的结果项目不会为了证明最初方案正确而不断更换指标。3. 首期范围要能独立交付本例首期只服务既有客户的批量维护不同时加入新客获客、推荐商品、自动优惠券定价或跨店统一平台。先做一条能交付、能记录、能复核的链路生成名单人工执行回收结果。预测是候选能力自动触达也暂不加入避免把多个不确定问题绑在一次上线中。交付时间、规则优先级、名单有效期与异常处理由使用方共同确认。下面的时间及阈值都是教学验收约定需要在真实项目中重新协商。三、再讲技术业务约束怎样推导出系统设计1. 先把责任分开再选择组件当数据、评分、名单和执行混在一个脚本里时出现问题很难判断是原始交易少了、模型异常还是店员拿错了名单。因此按责任形成清晰边界责任管理什么关键保证交易与行为数据购买定义、客户历史、时间覆盖指标与样本可追溯规则与模型评分特征、方法版本、评分同一输入能复核名单策略预算、排除规则、同分顺序选人符合业务约定执行交付名单领取、联系状态、重复防护使用方拿到正确且有效的批次效果评价分组、购买结果、贡献与成本区分预测效果与行动效果规则和模型负责给出判断依据不能绕过名单策略直接发送消息。是否超过预算、是否重复联系属于动作约束不应由模型分数决定。基础设施随后映射到责任SQL与分析数据库加工交易和客户状态Python负责拟合、评分与评估调度和存储负责按时运行、保留版本与交付状态。2. 一条可验收的输入合同本例约定每周一09:00前交付名单10:00开始维护交易观察截止点为周日24:00。参与资格先由业务确认再进入评分。还必须区分交易发生时间与数据到达时间。如果周日的交易周一才传入历史回测也不能假装周日就已经知道它。需要按预测时点重建当时真正可用的信息。完整性不能只看“最大交易时间已经到周日”。源系统可能有部分记录遗漏因此还要有源批次完成标记、分区核对或约定的控制总量等证据。输入合同至少包含数据截止点、完整性凭据、购买口径、已知客户资格、缺失处理以及规则或模型实际需要的字段。3. 从输入到可使用名单中间有一道发布门一次运行先形成候选结果再检查最后交付固定本次输入与口径版本 → 构造客户历史状态 → 规则或模型评分 → 执行排除规则与预算限制 → 检查名单与输入质量 → 发布带版本和有效期的名单 → 记录领取及实际执行这道发布门很关键计算成功只表示产生了结果质量通过才允许使用。名单还应附带批次号、预测时点、截止点、方法版本、适用活动和有效期。名单可以少于600人。没有合格对象、试验需要保留对照或达到联系上限都可能让名单变短不能为了凑满人数绕过排除规则。4. “同一批数据”还不够训练与使用必须一致客户状态仍可采用过去90天的RFM等特征标签仍定义为未来30天是否发生约定购买。但训练时与实际评分时字段含义和计算方式必须相同。例如训练金额扣了取消、实际评分金额没扣模型面对的就不是同一种状态。缺失填补、标准化也不能两边各做一套。同时预处理只在训练数据上拟合验证选方案测试检验已选方案不能用测试结果反复调参。参考scikit-learn常见陷阱这是训练与实际使用一致性的要求。可以通过固定口径、版本化特征计算、保存样本及模型复算来验证不能只靠“大家用的是同一份表”。5. 名单策略要能解释也要能重放本例先排除不符合联系条件、近期已联系以及试验要求保护的客户再在合格集合中按分数排序。规则名单也执行相同约束才能公平比较。同分时采用固定的稳定顺序例如客户编号不能通过后续购买标签打破平局。如果边界排除后补位应按原排序继续选择并再次检查而非随意插入客户。保存每位客户的入选或排除原因。之后有人问“为什么没选小赵”至少能分清是资格、预算、冷却期还是评分导致而不是笼统回答“模型决定的”。6. 失败时业务要怎样继续假设周一早晨本批数据不完整仍然生成600人名单会把“没有观测到购买”误当成“没有购买”。这种情况下模型和规则都可能失真。因此不能笼统规定“模型出错就用规则”。回退也有前提异常本例处理方式原因数据不完整、口径检查失败停止本批发布通知责任人新模型与新规则名单都不可信输入合格模型文件损坏或评分失败使用已批准、已验证的规则版本数据可靠可以采用明确后备方案名单已生成交付失败重试交付同一批次避免重新选出另一份名单联系请求超时不知是否已发出先核对发送状态直接重发可能重复打扰业务发现名单不适用标记批次停止使用处理待执行项撤销名单不能撤回已经发出的联系旧名单也不能无限期使用。本例可以约定其在明确活动窗口内有效过期后拒绝作为新名单除非业务重新确认。有效期是业务约定不是从模型训练时间自动推出来的。7. 一次业务任务可以有多次技术尝试“生成本周客户名单”是一项业务任务数据库暂时不可用后的重跑只是技术尝试。重试不应制造另一批语义不明的业务任务。同一输入快照和方法版本重跑应能核对名单一致数据修订后则明确形成新版本不能悄悄覆盖已领取的结果。联系执行也需要稳定标识例如活动、联系周期与客户共同确定一项动作。去重、冷却期和发送前检查共同防止重复联系不能只依赖进程没有运行两次。四、上线验收分数、系统和业务分别证明什么1. 离线验收先证明判断有依据规则与模型使用相同的预测时点、人群、特征可用信息和预算在后续时间样本上比较。每个30天标签窗口必须完整不能把未知未来补成0。若业务最多联系600人应重点报告该预算下的名单命中和覆盖如果还使用概率决定投入就检查概率误差。AP等整体排序指标可以补充但不能替代当前预算目标。观察多个后续时期记录波动与不确定性。模型只领先一两个人时不能凭一个点估计宣布稳定获胜如果没有达到事先约定的改善与成本条件规则继续作为正式方案是合理结论。2. 工程验收再证明使用方拿得到、用得对以下是一份示例验收表不是已完成的真实上线报告验收项输入或故障场景可观察的通过条件按时交付按正常周期输入完整数据周一09:00前发布10:00可领取数据正确包含取消、重复内容、未知客户按约定分类金额对账通过客户资格正确数量约束合格人群超过600名单不超预算排除规则不被绕过运行复现同快照、同版本重新执行客户集合与顺序一致质量阻断源批次未完成不发布新名单明确报错和通知后备方案输入合格但模型不可用明确标记规则版本不冒充模型结果重复防护任务重试、发送超时不重复交付有效动作未知发送状态先核对版本与失效名单更新或超过有效期领取方能识别有效版本过期批次不可继续执行业务使用店员领取并执行测试名单能查看对象、原因、批次并回填执行状态真实项目还要提前确认环境、入口、参与角色和具体期望区分本地自动检查与目标环境验收。测试环境跑通不能直接代表生产业务通过。3. 影子运行先观察不改变实际选择模型先随正常批次生成候选名单但店员继续使用当前规则。对比两份名单差异观察是否准时、是否存在异常集中、输入变化是否影响结果。影子阶段可以验证运行稳定性和后续自然购买识别能力。它没有实际改变联系策略因此不能证明模型维护策略产生了经营增量。4. 小范围试验公平比较行动策略要区分维护与模型的价值可以将一批符合条件的3000位客户随机分成三组。下面是设计示例1000人一组不代表样本量足够。分组客户数行动安排A组对照1000不开展本次试验性维护其他正常服务一致B组规则策略1000规则选择前20%联系200人C组模型策略1000模型选择前20%联系200人首轮总计联系400人低于600人上限。保留试验条件比用满人员更重要不能把剩余名额随意补到对照组。两种策略均使用20%联系比例与完整场景的600/3000一致。分组在评分和行动之前固定联系内容、时点与成本条件尽量一致。首轮保持客户组别不变观察完整30天并记录其他活动干扰不能在下周重新分组后把同一客户当成独立新试验。评价应比较每组全部1000人的平均贡献或购买结果再扣实际触达成本。只比较B、C组中被选中的200人会受选择方式影响不能直接解释为策略对整个人群的增量。B对A用于评价规则维护策略C对A用于评价模型维护策略C对B用于评价模型相对规则的额外作用。开发和固定运维成本则按事先约定口径另行核算。随机化与恰当设计为因果评价提供基础但还需要检查分组、执行、干扰与统计不确定性。参考Microsoft的在线对照实验实践5. 业务验收证据不够时结论就是尚未证明试验前应约定主要指标、最小值得追求的收益、可接受损失、样本量与观察期并设置客户投诉或重复联系等保护条件。不能每天挑最好看的结果宣布成功。样本量应根据历史波动、希望识别的效果和风险要求计算。客户不足时可能无法迅速得出结论应如实说明不确定性而不是承诺“跑两周一定有效”。如果结果的合理估计范围仍包含不可接受亏损或收益不足以覆盖额外成本就不应仅凭平均数为正而扩大投入。技术交付可以通过经营收益仍可能尚未证明。五、把P7式判断落实成一份决策记录1. 记录决定、依据与改变决定的条件这里的责任范围是把当前业务问题完整解决而不是把技术组件堆齐。每个重要决定都应留下理由决定当前理由什么时候重新判断先交付规则与执行记录先解决不稳定和重复联系建立比较基础规则仍有明显不足且数据成熟模型先做候选与影子运行离线效果尚不足以证明行动收益运行合格、比较有价值后进入小试验输入失败阻断名单不完整数据会同时误导规则与模型完整性恢复且重新验收规则作为受控后备输入可靠时可维持已知能力规则也不适用时停止发布用随机策略组评价区分自然购买与联系效果人群、渠道或行动内容明显改变暂不自动发券当前没有支持定价与优惠优化的证据另行定义目标、成本与验证方案一份决定必须允许被新证据推翻。“为什么选择”和“何时不再适用”同样重要。2. 责任边界不是所有问题都由算法负责小林负责确认经营目标、预算和是否继续投入数据负责人确认事件口径与输入完整性模型负责人解释样本、方法与比较证据应用负责人管理名单交付和执行状态店员负责真实执行与回填。同一人可以承担多个角色但责任不能空着。否则模型可能说“名单生成成功”店员却拿不到数据缺失时各方又都认为应该由别人决定停不停。3. 三种都合理的交付结果规则足够好交付稳定规则、执行记录和效果证据停止额外模型建设。业务问题得到解决不需要靠复杂度证明项目价值。模型有改善但证据不足保留影子或限定试验补足观察与评估不提前宣称经营成功。模型额外价值得到支持在成本、稳定性与保护条件满足时逐步扩大同时保留规则后备和持续评价。此外数据不可信或任务不适配时也应允许暂停。投入已经发生不能成为继续投入的唯一理由。六、复习章节十分钟重建判断过程1. 记住六个问题为什么做——当前痛点、目标与收益空间 值不值得——收益假设、成本和不确定性 为什么这样做——人工、规则、模型与补数据的取舍 怎样交付——输入、时点、名单约束和责任边界 出错怎么办——阻断、回退、重试和失效处理 怎样决定继续——离线、工程、经营三类证据2. 概念速查概念对应的业务判断基线现有普通办法已经能做到多少机会成本做这个项目会推迟什么更有价值的工作增量相比不行动真正多带来什么额外价值相比规则模型多带来的收益是否覆盖额外成本输入合同使用前必须具备哪些数据与完整性证据发布门哪些条件没满足就不能交给业务使用幂等与重复防护同一任务多次尝试怎样避免重复动作后备方案主方案不可用时什么条件下还能维持服务影子运行先观察新方案不改变当前实际选择验收什么环境、输入与结果足以支持交付结论3. 五道自测题名单命中率提高2个百分点为什么不能直接算成增量购买模型文件坏了可以回退规则源数据缺失为什么不能照样回退发送请求超时为什么不能直接把600人重新发送一遍规则与模型策略试验中为什么要比较整组客户而不只比较被选中的人工程验收通过但经营收益仍不确定应该怎样报告和安排下一步4. 十分钟复习安排前两分钟闭卷讲小林为什么需要这个项目。中间三分钟画出“数据→评分→名单→交付→执行→效果”的责任链。最后五分钟任选一道题说明判断依据、失败后果与改变决定的条件。可以用这一段话检查自己的表达我先确认目标和约束用简单规则建立基线再判断模型是否有额外价值。交付时明确输入、版本、预算和失败处理用离线比较证明判断有依据用工程验收证明可使用用受控行动评价经营效果。证据不支持继续时就保留简单方案或停止投入。复习时不必逐字背诵。换成自己的项目仍能解释“为什么做、为什么选、失败怎样处理、凭什么继续”才说明这套判断真正变成了可使用的能力。延伸阅读与说明上一篇从一家小店看懂数仓与机器学习。GoogleRules of Machine Learning参考其中简单方法、指标和可靠流程的工程思路。scikit-learnCommon pitfalls and recommended practices参考预处理一致性与数据泄漏的说明。Microsoft ResearchOnline Experimentation at Microsoft参考受控实验评价产品变化的思路。本文经AI辅助整理并核对了算术、假设边界与论证关系。文中方案、验收条件和试验均为教学设计未开展真实客户触达、生产上线或收益试验不应将其作为已验证的经营效果。