# PLG 信号链数据源审计报告

> 日期:2026-07-30 · 作者:GTM AI Assist(Yan 复核)
> 范围:PLG Daily Digest、APAC New Tenant Monitor、Tenants Monitor 目标账户地图、NexusCRM、Reo.Dev
> 依据:2026-07-22 至 07-30 每日 enrichment run 实际拉取的数据,非抽样推断

## TL;DR(So What)

PLG 信号链的**榜单和分发机制在正常运转,但三个上游问题正在侵蚀信号质量**:① P1 队列四天膨胀近4倍且无解释;② QPS 单点采样导致租户评分/定级反复横跳;③ CRM Lead 占位符与永不推进的状态,使"净新"判定退化为"没人处理过"的同义词。修复优先级见文末。

---

## ① PLG Daily Digest(上游评分)— 问题最大

**P1 队列无解释膨胀(高优)**
P1:62 → 125 → 186 → 236(07-27 → 07-30,4天近4倍),同期 P0 基本持平。总队列 2034 → 3503(8天 +72%),只增不减——**队列没有淘汰/衰减机制**,更像评分或准入逻辑被变更/出 bug,而非市场变化。需上游 owner 给出根因。

**QPS 单点采样导致评分抖动(高优)**
`tenant_avg_qps` 是 11:00 时刻的 1 小时 Prometheus 速率。实例:CUPPASOFT 五天内评分 82→67→57→67→82、tier P0↔P1 反复翻转(QPS 491→1.7→0.8→1.1→462),疑似其批处理任务恰好撞上采样窗口。**单点1小时速率不适合作定级输入**,建议改用 24h 均值或分位数;且该指标可能含非用户流量(IT 确认中),QPS>0 ≠ 用户活跃。

**个人租户混入(中优)**
gmail.com 的 "a's Org"(category=individual,已由 07-21 Tenants Monitor 确认)反复进入 top10。上游未过滤 free-mail/个人租户。

**结构性盲区(已知,修复待推进)**
评分纯累计使用量(集群+QPS+绑卡+AI 类别),零 firmographic 权重,top10 门槛 ~57 而 day-1 租户上限 ~40 → **新签约永远进不了榜单**,榜单是同一批存量租户的重复。变更请求已提(docs/scoring_change_request_2026-07-27.md),待落地。

## ② APAC New Tenant Monitor(AI 富化)

**与 Reo 冲突率偏高**:一周内至少 3 起同一公司两源打架——CIS(San Jose vs Indore)、Loyalty Power 7(Maryland BPO vs 菲律宾 loyalty 平台)、Definition Lab(Reo 称 Florida,实为韩国 Naver Place 服务)。两边均为 AI 推断,**任何单边不可直接采信**,现行"双源并列展示"规则(R10)必须保留。

**free-mail 判定漏洞**:winerfree.ntesmail.com(网易免费邮箱子域)被标为 non-individual 进入 feed。

**feed 静默不可判**:07-24 23:47 后至 07-27 无新卡片,无法区分"周末真没签约"和"feed 挂了"——feed 需要心跳或每日零条确认。

## ③ NexusCRM(数据卫生)

- **占位符 Lead**:cloud-signup 同步的 Lead,Name/Company 多为 "[not provided]" —— 直接削弱 R5 lead-company 桥接能力,而净新判定依赖桥接。
- **重复记录**:ryan.murtagh@ 两条且状态互斥(OPEN + Nurture)、eakapong@ 两条、tivon@ 同一分钟两条;Account 层 MEGAHARD 存在两个重复账户("MEGAHARD LIMITED" / "MEGAHARD LIMITED ( No )")。
- **Lead 状态永不推进**:Definition Lab OPEN 26 个月、anteraja 存在 2022 年 OPEN lead。"OPEN" 在当前库中几乎无信息量;这是净新行每日重复出现的根因(已上 R17 陈化机制对冲,但根治靠 SDR 流程)。
- **关键字段缺失**:Trickle 的 Account Website 为空,Website LIKE 永久失配,只能靠桥接兜底。
- **ID 格式混用**:同一对象混有 Salesforce 风格 ID(00Q…/001…)与 UUID(如 Cartenz Account、部分新 Lead),疑似两套写入路径;做 IN 关联时需兼容两种格式。
- **认证不稳定**:needs_auth 断连 07-15 → 07-29 反复出现(仅 07-22 例外),07-29 OAuth 迟到导致重复 run。07-30 健康,但需持续每 run 探测(已入规则)。
- **同步缺口**:B2K Advisory 等 HubSpot lead 长期未落入 Nexus(watchdog 任务持续监控中)。

## ④ Reo.Dev(覆盖与一致性)

- **覆盖率缺口**:本次 run 约 1/3 域名返回空(cuppasoft.com、gratefulprintsph.com、adonisgym.com.au、wevm.dev)。失败即写"Reo lookup failed",不得沿用旧描述(R3,曾有 07-27 编造事故)。
- **crm_owner 陈旧**:Qing Liu、Vince Yao 等为遗留映射,不代表 Nexus 真实 Owner(R5/R9 已规避,防止他处误用)。
- **内部自相矛盾**:Kitabisa "708 活跃开发者" 与 "developer_activity LOW (score 2)" 并存;customer_fit 对大集团亦有误判先例(Sea Ltd 等)——fit 分不能为 tier 封顶。

## ⑤ 跨源不一致

- **同租户双评分**:07-21 Tenants Monitor 给 anteraja score=82,同期 Digest 给 67——两个上游用了不同版本的评分公式,消费侧无从校准。
- **目标账户地图陈化**:最后更新 07-21(明日过 10 天陈化线),且卡片只展示 16 条中的 10 条,完整名单不可见。

---

## 修复优先级建议

| # | 问题 | Owner 方向 | 动作 |
|---|------|-----------|------|
| 1 | P1 队列 4 天 ×4 膨胀、队列只增不减 | Digest 上游(刘昉/谢玉洁团队) | 给出根因;补淘汰/衰减机制 |
| 2 | QPS 单点 1h 采样致 tier flapping | Digest 上游 + IT | 改 24h 均值/分位数;确认指标是否含非用户流量 |
| 3 | cloud-signup Lead 占位符 + 状态永不推进 | CRM Ops + SDR 流程 | 同步时回填公司名;给 OPEN lead 设 SLA/自动过期 |
| 4 | 个人/free-mail 租户混入 digest 与 monitor | Digest 上游 | 上游过滤 free-mail 及 category=individual |
| 5 | 目标账户地图陈化且展示不全 | Signal Ops | 固定更新节奏;输出完整 16 条 |
| 6 | MEGAHARD 等重复账户、重复 Lead | CRM Ops | 去重合并 |

消费侧(本任务)已有的对冲:R2 QPS caveat、R3 反编造、R5 桥接、R16 新租户过滤、R17 陈化标记(2026-07-30 新增)。

*数据来源:TiDB Bots 群每日 digest 与 enrichment 卡片、APAC New Tenant Monitor 群卡片、APAC PLG/PQL Signal Ops Pilot 群 Tenants Monitor 摘要、NexusCRM SOQL 实查、Reo firmographic 实查。*