DogeSMS · 经营日报 / 情报

一次「供应商质量塌方」伪装成需求高峰，悄悄吃掉了转化率

数据窗口：过去 24h（截至 2026-07-18 20:07 UTC）· 对比 7d / 30d · 交叉源：订单库 + supplier_execution_attempts + GA4(prop 512790783) + main 分支代码
一句话结论：7-17 订单量暴涨到 4,072 单（≈平日 2 倍）但完成率崩到 8.2%，看起来像流量高峰—— 但 GA4 显示当天流量不升反降（859 活跃用户，自然搜索 -45%，零付费激增）。真相是：主力供应商 durianrcs.com 的 openai/US 号池当天枯竭（取号率 99% → 12%），路由自动兜底到 5sim.net——一个「能取到号但几乎收不到码」的供应商（openai/US 交付率 0.4%）。 用户拿到死号 → 等待 → 超时 → 重下单，新用户人均下单 ~13 次，把订单量灌成假高峰。 根因：质量评分路由（scorer）与 1% 死亡线自愈（combo_health）两道自动防线在生产环境全部关闭， 数据管道却一直在跑——防线已建好，只是没打开。

① 核心指标：24h vs 7d vs 30d

1,602
过去24h 订单
30d日均 ~1,521 · 基本持平
15.4%
过去24h 完成率(e2e)
7d 18.9% / 30d 20.0% ↓
$103.9
过去24h 营收(completed)
7d日均 $129.6 · 略低于趋势
$48.0
过去24h 利润
7d日均 $66.8

营收/订单量基本在正常波动内；真正的信号是完成率——以及它背后 7-17 的塌方事件与结构性隐患。

每日订单量 & 完成率（近 8 天）

日期(UTC)订单完成完成率备注
07-111,45126618.3%
07-121,44426218.1%
07-132,04630715.0%
07-141,42429820.9%
07-151,90541221.6%
07-161,82135119.3%
07-174,0723358.2%← 假高峰 / 塌方日
07-181,45423115.9%部分恢复

② 证据链（三源交叉验证）

  1. 订单库：7-17 订单 4,072 单（≈2×），完成率 8.2%（平日 15–22%）。次日恢复到 15.9%。
  2. GA4（独立源）：7-17 活跃用户仅 859（周内正常 1,000–1,500），自然搜索 411 vs 7-13 的 746（-45%），无付费/展示激增 → 不是流量增长。
  3. 重下单灌水：塌方窗口内新用户人均下单 ~13 次（正常 1–3 次）——典型的「死号 → 重试」循环。
  4. 主力枯竭：durianrcs.com openai/US 取号率长期 98–99%，7-17 骤降到 12.2%（590 试 → 72 取号）= 号池枯竭。
  5. 毒性兜底：路由兜底到 5sim.net，当天 openai/US 取号 454，收码 2 条（0.4%）——用户全拿到死号。
  6. 代码印证：scorer.enabled=false（质量评分路由关）+ combo_health.enabled=false（1% 自愈关），而 performance_aggregator.enabled=true（数据一直在跑）。防线全关。

③ 元凶画像：5sim.net —— 全站第 2 大供应商，交付率只有一半

供应商 (7d)取号数收码数交付率
durianrcs.com5,1561,42927.7%
5sim.net2,69136013.4%
sms-bus.com88914316.1%
grizzlysms.com83521225.4%
isptelecom(自营池)766455.9%已知地理拒发码，另议

5sim.net 取号量全站第二，交付率却只有主力的一半。它并非全面差——在 flipkart/IN(58.6%)、openai/AT(47.5%) 上很好，但在下面这些高需求组合上近乎「死号供应商」：

5sim.net 的 12 个「毒性组合」（7d，取号≥20 且交付率<10%）

服务国家取号数收码数交付率
openaiUS46720.4%
openaiGB362205.5%
whatsappDE17110.6%
whatsappGB8789.2%
telegramUS7011.4%
telegramGB6769.0%
openaiID6757.5%
whatsappHK6000.0%
googleUS3700.0%
telegramCA3538.6%
whatsappUS2100.0%
telegramUZ2100.0%
合计1,464463.1%

7 天内 5sim 仅这些毒性组合就造出 1,418 个死号（≈200/天）。每个死号 = 一位用户拿到号、等最多 5 分钟、收不到码、订单超时——然后重下单。

④ 为什么没被拦住：两道防线都关着

平台其实已经建好了应对这种情况的两套机制，但生产环境全部关闭：

机制作用生产状态
质量评分路由 scorer按「解码率0.6 / 成本0.3 / 延迟0.1」重排供应商，5sim 会被压到最后enabled: false
(shadow_mode: true)
combo_health 自愈24h 交付率<1% 且样本≥100 → 自动隐藏该组合（带 admin 覆盖 + 双窗口恢复 + 1 分钟回滚）enabled: false
performance_aggregator把 attempts 聚合成快照，喂给上面两个enabled: true

数据一直在采集，决策却没开。结果：主力供应商一打嗝，流量就静默流向死号供应商，用户反复重试，完成率崩盘—— 而现有的供应商健康监控只看余额，对交付率崩盘完全失明（「平台对供应商侧变化经济无感知」）。

⑤ 建议动作（路由红线，需人工拍板 + staging 验证，不宜自动上线）

建议 1 · 低风险先做 —— 打开 scorer 的 shadow_mode 观测（enabled: true, shadow_mode: true，只写决策日志、不改分配）。这正是配置里写好的「Day 8」步骤，能立刻看到「scorer 会把 5sim 排到哪」与实际分配的差异，零分配风险。
建议 2 · 主修复 —— 打开 combo_health.enabled: true（config.production.yaml:221）。它会在交付率<1% 时自动隐藏 openai/US×5sim 这类死号组合，带 admin 手动覆盖、双窗口恢复防抖、1 分钟回滚。建议先 staging 验证≥24h 再切生产。
建议 3 · 补监控盲区 —— 把「取号成功但交付率骤降」纳入供应商健康告警（现只看余额）。这样下次主力枯竭 + 毒性兜底能在分钟级被发现，而不是靠日报回溯。

为何本次不自动提 PR：打开 scorer / combo_health 属于供应商路由红线，团队既定规范要求人工判断 + A/B/staging 验证后再上线（配置注释亦写明该分阶段流程）。本报告给出精确改动点与分阶段方案，由团队开眼确认后一键切换，比自动合并更稳妥。

生成：Claude（自动经营日报任务）· 数据源：production 只读 PG（dogesms_db_production）+ GA4 prop 512790783 + main@25de12aa 代码
相关配置：backend/config/config.production.yaml:221(combo_health) · :499(scorer) · 服务代码：backend/internal/service/supplier/routing.go / scorer.go / service/combohealth/service.go
口径说明：完成率=orders.status='completed'/总下单；交付率=sms_received/allocated（attempts 表）；营收/利润仅计 completed 订单，与「先扣款失败退款」计费模型一致。