零星 · DM 发送时效分布

最近 100 条已发出 DM ｜ 生成于 2026-06-04 02:42 UTC ｜ 桶：0-1/1-3/3-6/6-12/12-24/24-72/>72h
⚠️ 该账号 DB 内无回复信号——零星全部 conversation 的 messages.role='customer' 与 last_inbound_at 均为 0， 说明 ADB 通道的 inbound 没有被 /api/cron/check-replies 回灌入库。因此本报表无法从 DB 区分「已回复 / 未回复」， 下方分布是全部 100 条的整体时效。要做「回复 vs 没回复」的时效对照，需要运营从手机端导出真实回复名单回填。
100
样本 DM 数
N/A
回复信号缺失（DB 未回灌）
柱长 = 该时效桶内的 DM 条数（共 100 条）

① 用户评论 → 系统采集（拉评时效）

comments.comment_time → comments.created_at；worker 抓到这条评论用了多久
全部 n=100 · 均值 11.5h · 中位 3.4h · P90 29.4h · 最大 86.9h
0–1h
35
1–3h
11
3–6h
20
6–12h
2
12–24h
9
24–72h
20
>72h
3

② 系统采集 → 我们拉取（待办积压）

comments.created_at → lead_claims.claimed_at；评论入库后多久被 operator claim
全部 n=100 · 均值 9.8h · 中位 4.0h · P90 25.2h · 最大 66.6h
0–1h
29
1–3h
16
3–6h
11
6–12h
8
12–24h
22
24–72h
14
>72h
0

③ 我们拉取 → 真发出（运营动手）

lead_claims.claimed_at → messages.sent_at；claim 之后多久真发出 DM
全部 n=100 · 均值 1.0h · 中位 0.5h · P90 4.2h · 最大 5.3h
0–1h
82
1–3h
5
3–6h
13
6–12h
0
12–24h
0
24–72h
0
>72h
0

④ 端到端：用户评论 → 收到我们 DM

comments.comment_time → messages.sent_at；用户从发评论到收到回复实际等了多久
全部 n=100 · 均值 22.2h · 中位 13.9h · P90 55.1h · 最大 102.9h
0–1h
2
1–3h
17
3–6h
13
6–12h
17
12–24h
15
24–72h
33
>72h
3

⑤ 归因分析：没收到回复，时效卡在哪一环？

端到端
用户从发评论到收到我们 DM，中位 13.9h、均值 22.2h。 只有 2/100 条在 1 小时内送达，却有 36/100（36%） 拖到了 24 小时以上。 装修是冲动 + 比价型需求，评论当下热度最高；隔了大半天到一两天才私信，用户要么已经忘了、要么早被同行先捞走，回复率天然被时效拖死。
主因
把端到端按中位拆三段，时间几乎全耗在前两步： ① 评论→采集 3.4h（占 43%） + ② 采集→拉取 4.0h（占 51%）， 而 ③ 拉取→发送只占 6%（中位 0.5h）。 最大瓶颈是 ② 采集→拉取，其次 ① 评论→采集。 换句话说——不是运营发得慢，是评论太老才轮到被发。 ③ 段 13% 在 3h 内发出，运营响应没问题。
瓶颈拆解
  • ① 评论→采集：中位 3.4h 不算差，但长尾重——23/100（23%）的评论 worker 隔了 24h+ 才抓到。抓取频率/覆盖不稳，热评被晾凉。
  • ② 采集→拉取：中位 4.0h，36/100（36%）的评论入库后压了 12h+ 才被 claim。说明评论进了池子没人及时捞——拉单频次/人手或拉单策略的问题。
  • ③ 拉取→发送：中位 0.5h，基本即拉即发，不是问题环节，无需优化。

⑥ 对应解决方案（按性价比排序）

1
拉单只拉新鲜评论（最快见效，零成本）
claim 时强制加时间窗：pnpm tsx scripts/claim-leads.ts --limit=N --since-hours=6， 只捞近 6h 评论，直接把 ② 段积压和端到端长尾砍掉。代价是可拉量变少，需要配合提高抓取量（方案 2）。
2
提高抓取频率 / 覆盖（治 ① 的长尾）
① 段 23% 评论 24h+ 才入库。提高 /api/cron/scrape 频率、对高产源加抓取并发，或给高意向源开小灶优先抓，把「评论→采集」中位压到 1h 内、消掉 24h+ 长尾。
3
缩短拉单间隔 / 高意向自动提醒（治 ② 的积压）
36% 评论入库后压 12h+ 没人 claim。让运营每 1-2h 拉一次而不是一天一波，或对高意向新评论做 Lark 推送提醒，把「采集→拉取」从中位 4.0h 压到 2h 内。
4
把端到端时效纳入日报红线 + 真实回复回填
给端到端设硬指标（如中位 < 6h），每天在个人日报里盯。同时——当前 DB 无回复信号——让运营导出手机端真实回复名单回填，才能把「发得快是否真的更容易收到回复」这条因果坐实，而不是只看时效推断。
目标线：端到端中位从现在的 13.9h 压到 6h 以内（方案 1 立即砍长尾，方案 2/3 治本）。 回复率改善需待真实回复数据回填后量化验证。
怎么读：对比每段「回复」(蓝) 与「未回复」(橙) 的中位时效——若未回复样本明显集中在更长的时效桶，说明「发太晚」是丢回复的重要原因；若两者分布接近，则回复差异更可能来自文案/意向而非时效。
口径说明：①回复检测仅 DB 反查（同 conversation 后续 messages.role='customer'），依赖 /api/cron/check-replies 回灌，可能低估真实回复；② comment_time 或 lead_claims 缺失的样本不进对应段统计；③负 delta（时钟漂移）clamp 到 0。