| 指标 | 目标值 | 上线前 | 上线后 | 变化 | 判定 |
|---|---|---|---|---|---|
| 快捷支付带券率 | ≥10%（上线 2 周内） | 0%（不支持） | 18.6% | 从 0 打通 | ✅ 超预期 |
| Apple Pay 成交订单用券率（订单后台） | 打通快捷支付用券覆盖 | 14.6% | 22.5% | +7.9pp（+54%） | ✅ 最大成效 |
| M 端 vs PC 用券率差距（订单后台） | ≤10pp（原 15.8pp GA4 口径） | 12.7pp | 9.6pp | -3.1pp | ✅ 达标 |
| 用券成功 → 带券进入结算/支付 | ≥70%（漏斗健康度） | — | 1,447 次 / 1,312 次成功 | 环节无流失 | ✅ 健康* |
| 整体用券率（成交订单口径） | 维持 35% 左右 | 35.7% | 32.3% | -3.4pp | ⚠️ 微降，入口扩大稀释（见 3.3） |
| 购物车触达 → Apply 率 | ≥15%（原基于结算页 UV 口径） | 19.4%（结算页口径） | 9.6%（购物车口径） | 分母扩大 3.5 倍 | 📊 口径不可比 |
| Select Coupon 面板使用率 | ≥30%（登录用户） | —（新能力） | 7.2% | — | 🔴 未达标，归因见 3.1 |
| 用券用户支付完成率 | ≥54.3%（上线前基线） | 54.3% | API 不可查 | 数据缺口 | ⚠️ 以订单后台 999 用券单填补（见 3.4） |
* 带券进入为次数口径（含同一用户重复点击），无法做严格 UV 漏斗；带券进入次数（1,447）≥ 用券成功次数（1,312），说明成功用券后基本都会进入结算，该环节无明显流失。
本需求成功把用券能力覆盖到此前完全无法用券的快捷支付场景——Apple Pay 订单用券率提升 54% 是最直接的成效证据，M 端与 PC 的用券差距同步缩小至目标线内；整体用券率与触达转化率的小幅下降是入口扩大带来的分母稀释与季节性波动，不构成功能负面。下一步重点：提升优惠码单次输入成功率（55.6%）、优化 Select Coupon 引导。
上线前 Apple Pay 直接跳过结算页，用户几乎无法用券（14.6% 多为系统自动券/活动券）；上线后购物车页应用的优惠码自动带入 Apple Pay 支付请求，成交订单用券率跃升至 22.5%。
| 支付方式 | 上线前用券率 | 上线后用券率 | 变化 | 解读 |
|---|---|---|---|---|
| Apple Pay | 14.6% | 22.5% | +7.9pp（+54%） | 前置最大受益者，此前无法用券 |
| PayPal | 30.0% | 30.3% | +0.3pp | 稳定，已有用券习惯用户保持 |
| 普通支付（信用卡等） | 42.9% | 38.6% | -4.3pp | 自然波动 |
| 快捷支付合计 | 27.6% | 27.7% | +0.1pp | 整体稳定，结构内 Apple Pay 显著改善 |
埋点侧同步验证：快捷支付按钮点击带券率 18.6%（634 / 3,417 次，目标 ≥10%），近 1/5 的快捷支付点击携带购物车页已应用的优惠券；后端券失效拦截（express_coupon_invalid_click）11 天仅触发 1 次，扣券时序兜底逻辑运行良好。
数据来源：订单后台「优惠券名称」字段 × 支付方式；ga4-data/06、ga4-data/10
本需求的核心假设「Mobile 存在被入口不便抑制的用券需求」得到验证：前置后 M 端用券绝对人数（392）与 Desktop（403）仅差 11 人，成交订单口径的用券率差距也进入目标线内。
| 设备 | 用券用户数 | 占比 |
|---|---|---|
| Desktop | 403 | |
| Mobile | 392 | |
| Tablet | 2 |
| 设备 | 上线前 | 上线后 | 变化 |
|---|---|---|---|
| PC 端 | 41.4% | 37.0% | -4.4pp |
| M 端 | 28.7% | 27.4% | -1.3pp（更稳） |
| M vs PC 差距 | 12.7pp | 9.6pp | ✅ 缩小 3.1pp |
解读：7 月整体用券率有季节性回落，但 M 端仅微降 1.3pp、PC 降 4.4pp——M 端用券的抗跌性显著更强，说明前置入口对 M 端场景的改善是结构性的，而非流量红利。
数据来源：ga4-data/07；订单后台设备维度对比
GA4 埋点（行为意图层）与订单后台（成交结果层）相互印证，形成完整转化链路。用户级 Apply → 成功率 78.8%，带券进入结算 1,447 次，最终落地 999 笔用券订单。
解读：② → ③ 近 8 成尝试用户最终成功用券；③ → ④ 带券进入次数超过成功次数，说明成功用券后基本都进入了结算，该环节无流失；④ → ⑤ 由订单后台「优惠券名称」字段验证闭环——999 笔用券订单与埋点链路量级吻合。
数据来源：ga4-data/18（minicart 触达）、ga4-data/01/02/05/06/08；订单后台上线后数据
minicart 流量约为 cart 落地页的 13.4 倍（9,277 vs 692 人），用券行为分布与之高度一致——优惠码入口做进抽屉购物车（而非仅落地页）是正确决策。
| 模块 | 事件次数 | 用户数 | 占比 |
|---|---|---|---|
| 抽屉购物车（minicart） | 1,216 | 755 | |
| 购物车落地页（cart） | 96 | 69 |
用券券种以 C-1 满减/满折券为主（99.8%）；Top 券为「会员新人礼 10% OFF」（36.5%）+「订阅券 10% off」（34.3%），合计 70.8%——用券主力是新注册和订阅用户，前置让这些高价值用户更早锁定优惠、减少流失。
数据来源：ga4-data/02、ga4-data/04；订单后台 Top 优惠券分布
影响：券码库面板作为新增能力，使用率远低于预期，11 天仅 112 位用户点击（171 次），需判断是「入口没被发现」还是「不需要」。
| 指标 | 数值 | 说明 |
|---|---|---|
| Select Coupon 点击 | 171 次 / 112 人 | 全部为登录用户（符合 PRD：未登录不展示） |
| 面板使用率 | 7.2% | 目标 ≥30%，未达标 |
| Apply 手动输码 | 2,360 次 / 1,012 人 | 手动输码仍是绝对主路径 |
解读：按 PRD 规则，登录用户进入购物车时后端自动返回最优券并直接展示 code + 优惠金额——大部分登录用户无需打开券码库就已拿到最优惠，Select Coupon 实际只承接「不满意自动推荐、想换券」的少数场景。7.2% 的低使用率有相当部分是产品机制的合理结果。
归因说明：30% 目标制定时未充分考虑自动最优券推荐对手动选券需求的替代效应，属于目标设定偏差而非纯功能失败；但也不能排除入口辨识度不足的贡献，两者混合，无法从现有埋点中拆分。
优化方向：① 重新校准目标值（建议以「自动推荐覆盖率 + 手动换券率」双指标替代单一面板使用率）；② 低成本增强引导：券码库入口展示可用券数量角标、输入框旁增加「Or select your coupons」文案，观察使用率是否回升，以验证入口辨识度假设。
数据来源：ga4-data/08、ga4-data/09；PRD v2「自动最优券与手动操作的关系」
影响：每 100 次 Apply 操作约 60 次失败（1,406 次失败 / 2,360 次 Apply），用户依赖重试才把用户级成功率拉到 78.8%——约 215 位用户（21.2%）尝试后始终未成功，可能带着挫败感离开。
| 口径 | 分子 | 分母 | 成功率 | 说明 |
|---|---|---|---|---|
| 用户级（重试后） | 797 人 | 1,012 人 | 78.8% | ✅ 最终结果尚可 |
| 事件级（单次尝试） | 1,312 次 | 2,360 次 | 55.6% | ⚠️ 首次失败率高，体验有损 |
| 失败事件 | 1,406 次 | — | 59.6% | 成功+失败 > Apply 次数，存在一次 Apply 多次验证 |
解读：1,406 次失败的 eventFailureMsg 100% 为 "Coupon code is invalid"——失败提示无区分度，用户无法知道是拼写错误、券过期还是门槛不满足，只能盲目重试。
归因说明：失败率高是用户输入行为（手输错误码、使用过期码）与提示信息笼统共同作用的结果，不能归因于前置功能本身——上线前结算页用券没有对应的事件级埋点基线，无法证明前置后失败率变高。
优化方向：① 前端增加实时格式校验（长度/字符类型），拦截明显无效输入；② 后端失败原因细分（无效/过期/门槛不足/渠道不符），提示对应文案；③ 失败时若用户已登录且有可用券，引导跳转 Select Coupon。
数据来源：ga4-data/02、ga4-data/03、ga4-data/08
影响：如果只看这一个数字会误判功能失败，必须拆解归因。
| 指标 | 上线前（6.01–6.30） | 上线后（7.17–27） | 日均变化 |
|---|---|---|---|
| 购物车总触达 | 21,972 人 | 10,568 人 | 732 → 961/天（+31%） |
| GA4 purchase 事件 | 9,592 | 3,205 | 320 → 291/天（-9%） |
| 后台有效订单 | 10,140 | 3,091 | 338 → 281/天（-17%） |
| 用券订单 | 3,621 | 999 | 121 → 91/天（-25%） |
| 触达 → 成交转化率 | 46.1% | 29.2% | -16.9pp |
| 整体用券率（成交订单） | 35.7% | 32.3% | -3.4pp |
解读：转化率下降由三个因素叠加——① 分母扩大效应：优惠码入口前置后更显眼，浏览型用户更频繁打开 minicart，日均触达 +31%（minicart:cart 比例从 8.8:1 升至 13.4:1），天然稀释转化率；② 季节性差异：7 月本身是淡季，日均订单独立于功能下降 17%；③ 周期不对等：上线前 30 天 vs 上线后 11 天，短周期波动更大。
归因说明：相关性 ≠ 因果性——转化率下降与功能上线同期发生，但分母口径变化和季节性是更强的解释变量；成交侧的结构性指标（Apple Pay 用券率 +54%、M 端差距缩小、带券进入率 20.9%）均为正向，不支持「功能导致转化下降」的结论。
优化方向：上线后第 30 天做同周期（对齐 30 天、避开大促）复核；以「用券率结构性改善」为核心成效指标，绝对转化率仅作参考。
数据来源：ga4-data/17/18/21/22/23/24；订单后台上线前/后数据
影响：复盘方案设定的「用券用户支付完成率 ≥54.3%」无法按原口径验证——GA4 Data API 查询 coupon / itemCoupon / customEvent:coupon 均返回 INVALID_ARGUMENT（该参数未在 GA4 注册为可报告维度）。
解读：本次用订单后台「优惠券名称」字段填补了成交侧数据（999 用券单 / 3,091 订单），闭环了「有没有用券成交」；但「Apply 过券的用户中多少人最终支付」这一用户级转化仍无法计算，因为订单后台与 GA4 用户无法关联。
归因说明：属于数据基建缺口，与功能实现无关；上线前报告的 54.3% 来自 GA4 后台探索工具手工导出，本次自动化链路无法复现该口径。
优化方向：① 数据团队在 GA4 后台将 purchase 的 coupon 参数注册为自定义维度（生效后仅覆盖新数据）；② 30 天复盘时用 GA4 后台探索工具手工补拉该口径；③ 另需排查 C-2 兑换券零使用、C-3 运费券仅 3 次的发放与可用性问题。
数据来源：ga4-data/16/16a/16b/16c（均查询失败）；订单后台数据
| 优先级 | 行动项 | 负责方 | 对应问题 |
|---|---|---|---|
| P0 | 优惠码输入实时格式校验 + 失败原因细分提示文案 | 前端 / 后端 | 3.2 单次成功率 55.6% |
| P0 | Select Coupon 入口增加可用券数量角标 + 引导文案，验证入口辨识度假设 | 前端 / 产品 | 3.1 面板使用率 7.2% |
| P1 | GA4 后台注册 purchase.coupon 自定义维度；30 天复盘时手工补拉「用券用户支付完成率」 | 数据 / BI | 3.4 数据口径缺口 |
| P1 | 排查 C-2 兑换券零使用、C-3 运费券极低使用的发放与可用性 | 运营 / 后端 | 3.4 券种覆盖 |
| P2 | 重新校准 Select Coupon 目标值（自动推荐覆盖率 + 手动换券率双指标） | 产品 | 3.1 目标设定偏差 |
| P2 | 上线后第 30 天对齐周期完整复盘（含 purchase.coupon 维度、排除季节性） | 产品 / 数据 | 3.3 转化率复核 |
| 风险 / 遗留 | 影响 | 应对 |
|---|---|---|
| 触达→成交转化率下降尚未用对齐周期复核 | 若 30 天复核仍显著低于基线，需重新评估浏览型流量的引导策略 | 30 天复盘设为硬性检查点（P2 行动项） |
| 「用券用户支付完成率」持续缺失 | 漏斗第 ⑤ 步只能用订单总量近似，无法做用户级归因 | purchase.coupon 维度注册后重算（P1 行动项） |
| minicart 触达为估算值（基于 express 按钮曝光用户数） | 触达类指标存在 ±15% 误差，影响 Apply 率等比率的绝对值 | 评估为 minicart 增加独立曝光埋点 |
| 约 21% Apply 用户始终未成功用券 | 潜在流失与负面体验，当前无法追踪其后续行为 | P0 校验与提示优化后观察该比例变化 |
| 数据来源 | ① GA4 埋点（行为意图层）：主站资源 www.smallrig.com（313302501），Data API 自动拉取，全渠道按 pagePath 前缀拆分（US/Global/UK/EU/DE/KR/JP/AU/CA）；② GA4 purchase 事件（3,205 单）；③ 订单后台（成交结果层）：上线后 3,091 有效订单 + 上线前 10,140 有效订单，含「优惠券名称」「支付方式」「设备」字段。三层相互验证闭环。 |
|---|---|
| 数据周期 | 上线后 11 天（2026-07-17 ~ 2026-07-27）；上线前基线为 6 月整月（2026-06-01 ~ 2026-06-30）。周期不对等且跨月，存在季节性差异。 |
| 数据局限 | ① 购物车触达为估算：minicart 不触发 page_view，用 express_pay_button_show（content_group=minicart）用户数 9,277 估算，与 cart 落地页 UV 1,291 存在重叠，误差 ±15%；② purchase.coupon 维度 GA4 API 不可查（INVALID_ARGUMENT），成交用券数据由订单后台填补；③ 带券进入结算为次数口径，含重复点击，不能做严格 UV 漏斗；④ GA4 多渠道并发查询存在 ±5% 取样误差。 |
| 归因提醒 | 上线前后数据变化受季节性（6 月 vs 7 月）、周期长度（30 天 vs 11 天）、触达分母口径变化共同影响，相关性 ≠ 因果性。转化率类指标的下降不构成功能负面结论，以结构性指标（Apple Pay 用券率、M/PC 差距、带券进入率）为准。 |