DogeSMS 经营日报

观测窗口:截至 2026-07-27 20:08 UTC(过去 24h / 7d / 30d 对比)· 数据源:production PostgreSQL(只读)+ GA4 + 代码交叉验证
今日头条情报 · 1 条

我们的转化率看似在跌(30d 17.3% → 近 24h 14.6%),会触发误报警。
真相:这 100% 是单一死路组合 apple/TR 的幽灵库存洪流造成的假象。
剔除 apple/TR 后,真实端到端转化率是 21.7%,不但没跌,反而高于 30 天均值。

健康的生意在变好;一个我们根本供不出货、却标成"有货"的组合,正在同时(1)伪造订单增长、(2)压低报表转化、(3)每周烧掉 2.3 万次供应商调用、(4)让 77 个真实付费用户平均失败 85 次。

一、大盘概览(过去 24h)

2,635
下单量
vs 前 24h 1,948 · +35%
$83.9
利润(仅 completed)
vs 前 24h $54.7 · +53%
14.6%
报表转化率
vs 30d 均值 16.6% · 看跌
21.7%
真实转化率
(剔 apple/TR)
vs 30d 17.5% · 实涨

注:DogeSMS 采用"先扣款失败退款"计费模型,营收/利润只按 completed 订单计;cancelled/expired 金额已全额退回,不计营收。

二、异常定位:apple/TR 单一组合吞掉 32% 订单量、0 交付

把过去 24h 按服务拆分,一个组合立刻跳出来:

服务下单完成转化利润
apple90160.7%$0.77
telegram643446.8%$17.01
openai42320548.5%$33.77
whatsapp22883.5%$12.07
flipkart774153.2%$8.61
tinder623962.9%$3.13

apple 占 24h 全站 34% 下单,几乎全在 apple/TR(土耳其):

apple 国家下单完成失败转化
TR 🇹🇷86406770.0%
IN145535.7%
US10000.0%

这是 7 月 21 日才出现的新异常(暴增 10–50 倍)

apple/TR 此前长期是每天 3–90 单的长尾,7 月 21 日起单日暴涨到 1000–1765 单,全程 0 完成

日期        apple/TR下单   完成
07-18                22      1
07-19                 9      0
07-20                36      0
07-21  ▲▲▲▲▲▲▲▲▲▲  1005      0
07-22  ▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲ 1765  0
07-23  ▲▲▲▲▲▲▲▲▲▲▲▲▲   1371   0
07-24  ▲▲▲▲▲          574      0
07-25  ▲▲▲▲▲▲         624      0
07-26  ▲▲▲            380      0
07-27  ▲▲▲▲▲▲▲▲       854      0
──────────────────────────────
近7天合计         6,573单  0完成  = 全站 32.3% 订单量

三、根因:跨 6 家供应商的"幽灵库存",且最便宜

当前可售目录里,apple/TR 有 5 家供应商全部标为 sellable 且报告巨量库存——但真实交付是 0:

供应商标称库存成本售价真实接码
durianrcs.com1,000$0.16$0.25 最低0%
grizzlysms.com158,408 ⚠️$0.50$0.710%
lubansms.com200$0.60$0.860%
sms-bus.com772$0.88$1.240%
sms-man.com122$3.21$4.390%

可售目录重建只信供应商上报的 source_available_count,没有基于"真实交付率"的门。durianrcs 把 apple/TR 标成 $0.25(全站最便宜档之一)+ "有货",于是它在前端排序里既便宜又可选——用户点进去,六家供应商轮流 canonical_fallback,全部失败。

7 天代价(纯浪费,零营收)

6,573
apple/TR 订单
0 完成
23,191
供应商分配调用
8 家供应商 · 0 个码
77
受害真实用户
人均重试 ~85 次
$0
apple/TR 营收
扣款=退款,损失隐身

四、交叉验证:GA4 与用户行为

五、代码验证:自愈机制已建好,却从未开启

后端早已实现"P2 接码率自愈器" combohealth,用于自动隐藏死路组合,且消费端已完整接线:

worker 每小时评估 24h 接码率 <1% 且样本 ≥100 → 决策 hidden 用户目录 + 推荐 LEFT JOIN 跳过 hidden

但在 production:

(2026-06-30 那次日报已发现此机制关闭,但当时结论是"即使开启也几乎空转"——因为它按 供应商×服务×国家 三元组、100 样本门评估,而当时死库存分散、单三元组样本不够。)

关键新发现:6/30 的"空转"顾虑对 apple/TR 已不成立

apple/TR 的洪流本身,把每个供应商三元组的 24h 样本量都推过了 100 门槛。模拟"若此刻开启 combo_health 会被隐藏的三元组",结果干净得惊人——只有 apple/TR 的 6 个供应商,全部 0% 接码,没有任何一个赚钱组合被误伤

会被隐藏的三元组24h attempts分配收码接码率
apple/TR · durianrcs8725500.00%
apple/TR · 5sim724000%
apple/TR · sms-man699000%
apple/TR · lubansms510300.00%
apple/TR · sms-bus4088500.00%
apple/TR · grizzlysms2055200.00%

换言之:开启 combo_health 是一个可证零附带损伤、可随时回滚、营收零风险的一行改动,会在下一个小时 tick 精准隐藏 apple/TR,其它任何组合都不动。

六、行动建议

  1. 【首选 · 已提 PR】开启 production 的 combo_health.enabled: true
    预期效果:apple/TR 从目录/推荐消失 → 32% 的无效下单洪流停止 → 报表转化率回升至真实的 ~21% → 每周省下 2.3 万次供应商调用 → 77 个用户不再经历 85 次连败。营收零风险(apple/TR 7 天营收 = $0)。
    ⚠️ 因涉及用户可见目录行为变更、且团队 6/30 曾把"开启自愈器"列为需人工拍板的决策,本 PR 不自动合并,交由团队 go/no-go。
  2. 【长尾局限,留作后续】较小的死路(telegram/JP·RU·SG、whatsapp/DE·RU·JP 等,近 7 天合计约 1,400 单)因分散在多供应商、单三元组样本不足 100,本次开启抓不到。若要治理长尾,需按 6/30 计划重标定:min_sample_size 100→20–30、评估粒度升到"服务×国家"跨供应商池化、hide_threshold 1%→3–5%——这是更大改动,建议单独排期 + A/B。
  3. 【可选快赢】若想立即止血又不想动 worker,运营可在 Admin 手动把 apple/TR 各供应商 offer 置 blocked

近 7 天全站死路组合清单(下单 ≥100 且转化 <3%)

组合下单完成转化用户
apple/TR6,57300.0%77
telegram/JP43620.5%137
telegram/RU19300.0%57
telegram/SG15600.0%78
whatsapp/DE14310.7%30
whatsapp/RU13410.7%22
telegram/TW11200.0%62
whatsapp/JP10800.0%19
telegram/OM10200.0%45

合计约 7,950 单(近 7 天全站 ~39%)流向"接近 0 交付"的死路;其中 apple/TR 一项占 92%。

由 tuna-prod-data 自动化日报生成 · 所有数字均来自 production 只读库 / GA4 / main 分支代码交叉验证 · 时间戳 2026-07-27 20:08 UTC
计费口径:仅 completed 订单计营收利润(先扣款失败退款模型)。转化率 = completed / 全部下单。