# 需求:官网UV采集是假装-beacon-token与账号唯一RUM站点tag不一致且从未采集任何一条数据

状态: rejected(2026-10-21 误诊已证伪:site_tag 是查询标识、site_token 才是 beacon 值(CF API snippet 字段为证);原 token 正确,改它反而断采 15 分钟后回滚。真问题=CF auto_install 与仓库片段双计,已删仓库片段并重发布;RUM 是 adaptive 采样集,小流量 0 条不可判采集坏)
归属: 公司运营
来源: 数据自动发现(ops/data/auto-findings.json#2026-10-21#1)
日期: 2026-10-21
建议: 原建议「做」已作废——2026-10-21 11:4x 复核证明**原诊断不成立**：beacon token 本来就对，改它反而断采。真问题另见本文件「复核结论」与 company LEDGER 同日条目。

## 现状（原诊断，已证伪）

- 原判断：线上 `data-cf-beacon` token=`3619bd4c…`，而账号唯一 RUM 站点 `site_tag=c23dd774…`，判为「采的是不存在的站」，14 天 `rumPageloadEventsAdaptiveGroups` 0 条 → beacon 装了 23 天白装。
- 触发：boss 2026-10-21 原话「推广线到现在感觉是有问题的，看数据，没有人，这不对」。

## 复核结论（2026-10-21 实证，原诊断不成立）

1. **两个标识被混淆**：`site_tag=c23dd774…` 是**查询**标识；`site_token=3619bd4c…` 才是**页面 beacon 该填的值**。依据是 CF 自己的 API 返回体：`GET accounts/{acc}/rum/site_info/list` 里的 `snippet` 字段原样就是 `{"token": "3619bd4c…"}`。原值正确，无需修改。
2. **采集链路是通的**：14 天查询里账号内确实有记录（`failbook.pinnadash.com` / `mail.pinnadash.com` 各 10 PV；26 小时窗口里另见 `aizuo.pinnadash.com` 1 PV）。`pinnadash.com` 自身在这些窗口里 0 条。
3. **数据集是 adaptive 采样**：`rumPageloadEventsAdaptiveGroups` 是采样聚合集，窗口不同结果不同、极小流量会出现"这次查不到"——所以「0 条」不能直接判「采集坏」，只能判「没有可测量的量」。
4. **按原诊断动手的后果**：把 token 改成 `site_tag` 后部署（25f75ec8），线上 beacon 立即失效；15 分钟内回滚（047091c）并重新发布。净结果=恢复原状。
5. **顺手查出的真问题**：该 zone 开了 Web Analytics **自动注入**（`auto_install: true`），边缘会按浏览器 UA 给每页注入一条 beacon；仓库 `templates/base.html` 又自带一条 → **每次真实访问被数两次**。已去掉仓库那条，改由 CF 注入（2026-10-21 已发布：9199424）。

## 实际做的事（可回滚）

- `official_website/data/analytics.json`：保持 `site_token`（未变），`build.py` 注释块加「site_tag ≠ site_token」警示；
- `official_website/templates/base.html`：删掉仓库自带 beacon 片段（保留注释与原片段，说明恢复条件），改由 CF auto_install 单点注入；
- 官网已重发布三次（错改 → 回滚 → 单 beacon），每次均线上复读。

## 验收标准

- [x] 浏览器 UA 抓 5 个页面（/、/zh/、/easy-disk、/terms/、/de/），每页**恰好 1 条** beacon，token 均为 `3619bd4c…`
- [x] 普通 UA 抓 HTML 时 0 条（注入的 UA 条件已确认，属正常，不是故障）
- [x] 线上错值（`c23dd774…` 作为 beacon token）绝迹
- [ ] 官网真实访客在 RUM 里可见（待有真实流量后用 7 天窗口判；当前量太小，adaptive 采样判不出）