combo_health 自愈系统在生产环境未启用，且即便启用也抓不到它们——因为判定粒度与样本阈值的设计与这类失败模式不匹配。
按服务拆分过去 7 天订单（已规避 mix-shift 假象，逐服务看真实接码/完成口径）。openai / netflix / tinder 健康；telegram / whatsapp 等高量服务则大面积失败。
| 服务 | 订单/周 | 完成率 | 取号失败率 | 完成营收(USD) | 判定 |
|---|---|---|---|---|---|
| openai | 2,676 | 48.1% | 2.2% | $340 | 健康·主力 |
| telegram | 2,123 | 6.3% | 24.9% | $161 | 严重失血 |
| 1,219 | 4.7% | 27.2% | $74 | 严重失血 | |
| 648 | 12.7% | 11.3% | $35 | 偏弱 | |
| netflix | 202 | 80.7% | 2.0% | $56 | 优秀 |
| tinder | 133 | 51.1% | 3.8% | $30 | 健康 |
telegram 是第 2 大量级服务（2,123 单/周），但完成率仅 6.3%、取号失败率高达 24.9%。whatsapp 同理。两者合计占全平台约 39% 的下单量，却几乎转化不出来。
下钻到「服务 × 国家」级别，筛出过去 7 天 ≥30 单且取号失败率 ≥90% 的组合。这些不是偶发缺货——它们每一天都 100% 失败，execution_fallback_reason 统一为 cross_supplier_fallback（已轮询所有供应商、全部无法分配号码）。
| 服务 / 国家 | 订单/周 | 取号失败率 | 完成率 | 性质 |
|---|---|---|---|---|
| telegram / OM (阿曼) | 102 | 100.0% | 0% | 每日全灭 |
| telegram / CN (中国) | 76 | 100.0% | 0% | 每日全灭 |
| whatsapp / SG (新加坡) | 67 | 98.5% | 0% | 每日全灭 |
| telegram / KR (韩国) | 58 | 98.3% | 0% | 每日全灭 |
| telegram / SG (新加坡) | 56 | 100.0% | 0% | 每日全灭 |
| alipay / CN (支付宝) | 54 | 100.0% | 0% | 结构性不可供 |
| telegram / TW (台湾) | 53 | 90.6% | 0% | 每日全灭 |
| redbook-xiaohongshu / CN (小红书) | 39 | 100.0% | 0% | 结构性不可供 |
| whatsapp / QA (卡塔尔) | 37 | 100.0% | 0% | 每日全灭 |
注：alipay/CN、redbook-xiaohongshu/CN 是中国本土 App，只认 +86 实名号，西方聚合器结构上无法供货——属于"永远不该上架"的组合。其余为我们持续展示、用户反复点击、却每天 100% 给不出号的组合。
GA4 过去 7 天活跃用户按国家排序（property 512790783，dogesms.com 生产）。把它和上表对照，问题的严重性才完全显现：我们最大的受众，正是我们供给最薄弱的地区。
| 排名 | 国家 | 活跃用户/周 | 该国关键组合供给状态 |
|---|---|---|---|
| #1 | 🇨🇳 中国 | 3,946 | telegram/CN、alipay/CN、小红书/CN 全部 100% 失败 |
| #2 | 🇺🇸 美国 | 2,038 | 主力供给健康 |
| #3 | 🇯🇵 日本 | 1,020 | 需进一步审计 |
| #4 | 🇭🇰 香港 | 687 | telegram/HK 失败率 18.8% |
| #5 | 🇸🇬 新加坡 | 532 | telegram/SG、whatsapp/SG 全灭 |
| #7 | 🇹🇼 台湾 | 305 | telegram/TW 90.6% 失败 |
| #10 | 🇰🇷 韩国 | 116 | telegram/KR 98.3% 失败 |
这正是历史上记录过的"流量—产品错配"模式的最新实证：站点吸引了高度偏华语/亚洲的受众（中国 #1、日本 #3、港台星韩齐聚 Top 10），但 telegram/whatsapp 在这些地区的供给约等于 0。用户带着真实意图来，撞墙后空手离开——而中国是我们的第一印象窗口。
阅读 main 分支 backend/internal/service/combohealth/ 与 repository/catalog/repository.go 后确认，平台本就内建了一套"死组合自动下架"机制，但它对这类失败完全失效，原因有三层：
catalog/repository.go 已 LEFT JOIN combo_health_decisions 并在 sellable 重建时跳过 status='hidden' 的组合——下架机制本身完整可用。但 config.production.yaml 里 combo_health.enabled: false，写决策的 worker 根本没跑，所以没有任何组合被标记隐藏。(供应商 × 服务 × 国家) 三元组，且要求 min_sample_size = 100 次/24h 才评估。但跨供应商 fallback 把流量摊薄到 4+ 家供应商，每个三元组 24h 实际只有 1–11 次尝试（telegram/OM 即便 7 天累计每供应商也仅 ~102 次）。没有任何一个三元组够得到 100 的门槛，全部被判 insufficient_samples_24h 跳过。combo_health 算的是接码率（SMSReceived / Allocations）——针对"能拿到号但收不到码"的烂号。而这些死组合是取号阶段就失败（Allocations = 0，号都分配不出来），是另一种失败模式。结论："1% 阈值拦不住"的真正病根不是阈值，而是判定粒度与度量维度。本次为情报投递，未自动改动生产行为——因为 (a) 仅翻开 enabled 开关不足以解决（样本粒度问题依旧），(b) 这是会改变用户可购买商品的店面级行为、且团队此前刻意保持关闭，应由团队拍板。以下为按优先级排序的建议：
alipay/CN、redbook-xiaohongshu/CN 以及 telegram/whatsapp 的 OM·CN·KR·TW·SG·QA。这些不存在恢复可能，零风险、当天可见效，直接消除 ~80 单/天的"必败"体验与无谓的供应商 API 调用。
(service, country) 跨供应商汇总 attempts/allocations，使长尾组合的样本能达到阈值；并新增"取号失败率"判据（allocations / attempts ≈ 0 且样本足 → 隐藏），覆盖当前只看接码率漏掉的失败模式。改完后再启用 enabled: true，自愈系统才真正生效。属真实功能改动，触及支付关键店面路径，需评审 + 灰度。