下面是一则用于讲解核销口径的教学情境，不对应某次真实活动；12%、24% 及角色对话均为示例。
运营同事把核销率圈了三遍。
大促复盘会上，屏幕上那条线从 12% 跳到 24%。会议室里一下热闹起来。有人说券包设计得好，有人建议下个月把预算再加一倍，还有人已经开始讨论海报该换什么颜色。
数据分析师没有鼓掌。他盯着明细看了一会儿，问了三个不太讨喜的问题：同一个人领了几张？昨晚核销的订单今天退了多少？这批人如果没拿到券，本来会不会也买？
投影仪的风扇嗡嗡响。刚才还很挺拔的 24%，忽然有点站不稳了。
这不是说优惠券一定没效果。它只是说明，核销率翻倍只能证明某个分数变大了，不能自动证明活动带来了更多真实生意。
先问清分母：同一个“核销率”，可能是三种数
很多争论不是算错，而是大家算的根本不是同一个东西。
活动系统里常见的“核销率”，至少有三种口径：
- 发券核销率：核销券数 ÷ 成功发放券数；
- 领券核销率：核销券数 ÷ 成功领取券数；
- 领券用户转化率：核销用户数 ÷ 领券用户数。
如果平台把券直接塞进用户账户，发放量会很大，第一种口径通常偏低。若活动页需要用户主动点击领取，第二种口径看起来会漂亮一些，因为没兴趣的人先被挡在分母之外。第三种口径又把“一个人领多张”压成一个人，回答的是人的行为，不是券的消耗。
这三种数都可以用，但必须把名字写全。只写“核销率 24%”，等于在报告上留了一只没有标签的量杯。谁都能拿起来，谁都不知道里面装的是水还是酒。
还要把时间窗写清楚。发券发生在活动开始前，领券可能在活动期间，核销和退款则会延后。拿截至周日的核销数，除以截至周五的领券数，结果也能算出来，只是没有多少业务意义。
所以复盘前先冻结四件事：统计对象、分子、分母、观察窗口。后面的五张表，都是为了让这四件事能回到明细上复核。
第一张表：发券表，确认“谁本来有资格拿到什么”
发券表不是券模板表。
券模板只告诉你满 200 减 30、有效三天、能不能和会员折扣叠加。发券表要回答的是：哪一张具体的券，在什么时间，通过什么批次，发给了哪个对象。
一行至少保留这些字段：
coupon_instance_id：每张券实例的唯一编号；campaign_id与batch_id：活动和发放批次；recipient_id：接收对象，可能是用户、设备或会员账户；issued_at与effective_window：发放时间和可用区间；issue_status：成功、失败、撤回或待重试；channel：站内、短信、直播间、门店或其他入口。
为什么要有券实例编号？因为“同一种券”不等于“同一张券”。一个用户可能从会员中心领到一张，又在直播间拿到一张；两张都属于同一个活动模板，却有不同的发放路径和使用资格。若明细只有 coupon_type=满200减30，重复发放会在汇总里消失。
发券表的分母只认成功发放。只有发券请求返回成功、却无法在用户账户中核到券实例的记录，不能算；批处理重跑产生两条成功记录，也不能直接算两张，先看券实例是否相同。
这张表最终给出一个朴素事实：活动到底向多少独立对象，成功交付了多少张可使用的券。
第二张表：领券表，拆开“热闹”和“有效领取”
发到券包里和主动领取，是两件事。
有些活动把券直接发给目标人群，领券表可以省略；更多活动需要用户点击、完成任务或输入码领取。此时领券事件很容易被页面刷新、接口重试和多端登录放大。