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: trueconfig.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 订单,与「先扣款失败退款」计费模型一致。