CLS 告警该盯「bad 会话率」还是 P75 聚合值：0.1/0.25 分档下阈值怎么定、采样 10% 时小样本时段怎么才不误报？

背景 我负责一个 B 端 SaaS 前端（React 18 + Vite 5，约 20 个页面），DAU 约 3.5 万，RUM 采样率 10%，核心页日均约 3~5 万会话。去年把 CLS 从 Lighthouse 0.35 治到 0.08（参考 #43 的 5 步落地），但只做了治理，没做告警——现在 CLS 劣化全靠用户反馈「页面老跳」才发现，平均滞后 1~3 天。

现象 / 卡点

1. CLS 是会话级累加指标，分布天然双峰：约 60% 会话 CLS=0（无偏移），剩下 40% 里 90% 集中在 0.01~0.15，但有 1~2% 的会话能到 0.5+（图片/广告位加载异常）。用 P75 做告警时，P75 长期贴 0 或 0.02，几乎永远不触发；用 P99 做告警时，单会话的极端值就把曲线拉爆，上周一次 CDN 图片 404 导致 P99 从 0.12 跳到 0.61，触发了 6 条告警，实际只影响 0.4% 会话。
2. 按 Web Vitals 官方分档（good < 0.1 / needs improvement < 0.25 / poor ≥ 0.25），我试了「bad 会话率（CLS ≥ 0.25 的会话占比）> 1% 告警」，但凌晨 0~8 点时段会话量只有白天的 1/5，1% 阈值在小样本下抖得厉害：上周凌晨 3 点 47 个会话里 1 个 bad 就触发了告警，查下来是用户网络抖动，白叫了一趟。
3. 和 LCP 不同，CLS 的「bad」没有连续劣化的物理意义——0.12 和 0.26 对用户体验的差别远小于 LCP 1.9s 和 2.6s 的差别，所以我不确定该抄 LCP 那套「P75 + 分档」的做法。

已尝试的排查

• P75 告警：3 个月触发 2 次（都漏掉了真实劣化，因为 P75 被 60% 的零值会话压着）；
• P99 告警：3 个月触发 23 次，人工确认有效 4 次，误报率 ~83%；
• bad rate > 1%：3 个月触发 11 次，其中 6 次来自凌晨小样本时段；
• 加「会话数 ≥ 200」的最低样本量门槛后误报降到 2 次，但漏掉了一次真实问题（当时正好在午间低峰，会话数 180）。

期望得到的答案形态

1. CLS 告警到底该盯 bad 会话率、P75、还是「bad 会话数绝对值 + 最低样本量」的组合？有没有团队给过具体的阈值组合和背后的取舍依据（数字）？
2. 小样本时段（凌晨 / 低峰）你们怎么处理的：直接不告警、拉长聚合窗口、还是动态阈值？
3. 如果 CLS 的 bad 率要和错误率、LCP 一起进 burn rate / SLO 面板，权重和分档怎么对齐才不互相打架？

参考：站内 #1743 讨论过 LCP 的 RUM 告警阈值反推、#847 讨论过前端告警降噪，但 CLS 这类「会话级累加 + 双峰分布」的指标我还没看到具体方案，想专门请教。