DogeSMS 经营日报

2026-08-02（数据窗口截至 2026-08-01 20:08 UTC）· 情报级别：高 · 由 tuna-prod-data + main 代码 + GA4 三方交叉验证

🎯 一条核心洞察：我们的"接码率自愈系统"存在结构性盲区，正在让 ~500 单/天掉进"永远收不到码"的死路，其中 ~40 个/天是新用户的第一单。

大盘平稳（营收/利润/订单量与 7 日均值持平），但产品体验的最大失血点藏在一个大盘看不到的角落：canonical_fallback 路径占 41% 的订单，接码率仅 3–5%。combo_health 刚上线止住了最大的一个死路（apple@TR），但它按"单供应商 / 24h / ≥100 样本"评估，对碎片化在多个供应商上的长尾死路完全失明——而这些死路恰好就是我们 76% 中国流量最想要的亚洲号码。

1 · 大盘概览：平稳，无异常

窗口	订单	完成单	端到端完成率	营收(实收)	毛利
近 24h	2,906	418	14.4%	$196.6	$104.5
前 7 天（日均）	2,851	445	15.6%	$195.4	$93.4
前 30 天（日均）	2,197	350	15.9%	$137.9	$68.2

订单量、营收、毛利均与近周持平甚至略升，完成率 14–16% 稳定。大盘无警报——这正是本条洞察的价值：真正的失血点不会在大盘上冒头。

2 · 核心洞察：40% 订单掉进 3% 接码率的死路

40.9%

订单走 canonical_fallback 路径 (24h)

3–5%

该路径端到端完成率 vs raw_ref 26%

80%

canonical_fallback 订单以 failed 收场

~500/天

掉进"0 收码"死路组合的订单

执行路径	订单(7d)	完成	完成率	失败(failed)占比
`raw_ref`（正常）	9,256	2,447	26.4%	4.2%
`canonical_fallback`	7,834	210	2.7%	80.1%

raw_ref 的未完成主要是用户主动取消/超时（正常行为）；canonical_fallback 的未完成是 80% 系统取号即失败——用户想要的号码根本供不出来。7 天内共 424 个组合、7,175 单（占 fallback 的 79.5%）实现了"零收码"。

零收码死路 TOP（7d，已排除已被 combo_health 隐藏的 apple@TR / telegram@MR）

服务@国家	订单	供应商数	单供应商 24h 最大样本	combo_health 可见性
telegram@JP	436	9	46	失明 (<100/供应商)
tiktok@KR	177	5	52	失明
telegram@SG	155	8	14	失明
openai@TW	129	7	12	失明
telegram@KR	126	5	30	失明
telegram@TW	124	8	21	失明
whatsapp@SG	114	8	20	失明
qq@HK	70	7	2	失明
kakaotalk@KR	52	4	52	失明

对照验证：telegram@MR（单供应商 135/24h ≥ 100）是唯一被自动捕获并隐藏的——恰好是唯一一个有供应商越过 100 样本门的组合。机制吻合度 100%。
深度验证：telegram@JP 过去 30 天 3,478 次尝试、678 次取到号、仅 8 次收到码（0.23%）——不是短期波动，是结构性死路。

3 · 根因：combo_health 的"碎片化盲区"（已读 main 代码确认）

自愈决策发生在 backend/internal/service/combohealth/service.go 的 EvaluateOne，判定单位是三元组 (supplier_slug, service, country)，样本门是每个三元组的 24h 尝试量：

// service.go:118 —— 样本门按「单供应商 × 组合」判定
if snap24h.Attempts < cfg.MinSampleSize {   // MinSampleSize = 100
    return Decision{Action: ActionNoChange,
        SkippedReason: "insufficient_samples_24h"}   // ← 长尾死路全部在此早退出
}

apple@TR
需求集中：每供应商 100–716/24h

→ 越过 100 样本门 →

✅ 9 供应商全部被隐藏，止血

telegram@JP
需求碎片：9 供应商摊薄，最高仅 46/24h

→ 每个三元组都 <100 →

❌ 永远不被评估 → 持续流血

本质：一个组合在聚合层面已 100% 死亡，但需求被 4–9 个供应商摊薄，没有任何单一供应商能在 24h 内攒够 100 样本 → 每个三元组都在样本门前早退出 → 死路对自愈系统隐形。样本越集中越容易被发现，越分散越安全地流血。

4 · GA4 交叉验证：流量-产品错配

国家/地区	会话数 (7d)	占比
🇨🇳 中国	5,724	76.3%
(not set)	606	8.1%
🇺🇸 美国	393	5.2%
🇸🇬 新加坡	209	2.8%
🇯🇵 日本	207	2.8%
🇭🇰 香港	165	2.2%
🇹🇼 台湾	50	0.7%
🇰🇷 韩国	16	0.2%

闭环坐实：76% 流量来自中国，加上 SG/JP/HK/TW/KR，受众高度亚洲化。这些用户天然想要亚洲号码（telegram/qq/kakaotalk/whatsapp @ JP/KR/TW/SG/HK）——而这些恰好就是第 2 节里零收码的死路组合。我们花钱把亚洲受众引进来，产品却供不出他们要的货，而安全网又看不见这个失败模式。

5 · 新用户冲击：第一印象即"产品坏了"

286

7 天内首单落死路的新用户（注册 1h 内）

~39/天

每天首单即撞死路的新用户

41%

死路订单来自新用户第一单

近 24h：523 单死路订单，其中 209 单是新用户注册 1 小时内的第一单，涉及 39 个新用户。这批用户对 DogeSMS 的第一印象是"取了号但永远收不到码"——直接的获客-留存漏斗杀手，且被计入了 76% 中国流量的获客成本。按此速率，一个月约 1,200 个新用户被一个大盘看不见、自愈系统抓不到的结构性缺口劝退。

6 · 建议动作

✅ 推荐修复（需人工 + A/B，不自主上线）

给 combo_health 增加"组合级聚合"评估通道，与现有"单供应商"通道并行：

按 (service, country) 聚合全部供应商的 7d 尝试量与收码量；
极保守规则——聚合样本 ≥ 100 单且收码数 = 0 → 判定组合级死路（0/100+ 无假阳性风险）；
关键配套：组合级隐藏后需要探测流量（probe sampling）回灌，否则会踩已知的"hidden 无自动恢复"坑（见 apple@TR 遗留）。这正是不能草率自主上线的原因——它触碰的是营收关键的自愈路由系统。

预期收益：把 ~500 单/天的确定性失败挡在下单前，保护 ~39 个新用户/天的首单体验，并把亚洲需求引导到能真正交付的组合。

⚠️ 更深的业务解法（Tony 决策域）

代码只能"止损"（挡下死单），真正"止血"是补齐亚洲号码供给。76% 中国流量 + 亚洲需求结构长期存在，值得评估：接入亚洲源头供应商 / 自营亚洲号池，或在获客侧调整——避免继续为供不出货的需求付获客成本。

📌 本次为何不自主提 PR

combo_health 是营收关键的自愈路由系统，组合级隐藏若过度触发会直接下架可售库存、切掉营收；且正确实现需要探测流量恢复通道（一个完整 feature，需 plan + A/B），而非同会话可安全速交付的改动。按既定纪律（供给侧/路由改动需人工 + A/B），本条以已量化、可直接落地的修复规格交付给团队定夺，比自主合并一个半成品到安全系统更负责任。

数据来源：production 只读 PG（orders / supplier_execution_attempts / combo_health_decisions）· main 分支 backend/internal/service/combohealth/service.go · GA4 property 512790783。
所有结论均可用报告内 SQL 复跑验证。生成时间 2026-08-02 · 自动化经营日报。