需要为开发者关系触点（文档、博客、仓库、包注册表、社区…

为 DevRel 各触点设计一份书面埋点追踪计划，让文档、仓库、注册表、社区等分散数据能拼成可信的开发者漏斗。

适用场景

解决思路

1. 先写决策清单：每条决策一行，并写出能回答它的那个问题；计划中每个事件都必须回溯到某一行，没有决策支撑的事件直接删除而不是推迟。
2. 建立触点登记表：每个触点一行，记录负责人、真实存在的数据源、保留窗口、已知偏差、以及你打算采集什么（参考 references/surface-register.md）。
3. 对每个触点应用开发者受众修正：判断计划采集的数字能否在开发者屏蔽客户端分析的情况下存活；这通常会重写登记表的数据源列。
4. 排定建设顺序：用效率（每小时价值）默认排序——标记词汇表 > 快照任务 > 自报来源字段 > 文档事件采集 > 身份主线 > 日志分析 > 产品侧事件 > CLI/SDK 遥测；按访谈中的投入上限删掉不可行的层级，并把保留的顺序与理由写进计划。
5. 设定身份主线：anonymous_id（首次访问、第一方、跨所有自有子域携带）；user_id（注册时分配，并在注册事件中与 anonymous_id 一同发出以便拼接历史）；account_id（仅公司采购动线，从注册域名解析并排除免费邮箱域名）。标记永远无法解析到个人的触点，改用可口头念的 vanity URL、按事件短链或自报来源字段。
6. 编写事件分类：采用 Object-Action 命名框架（对象在前、动作在后、过去时）；上下文放进属性而非事件名；维护属性注册表（每个属性有类型和允许值列表）；禁止任何 PII 或类 PII 标识符进入属性。
7. 编写链接标记规范：在第一条链接出现前就固定 source 和 medium 的受控词表以及 campaign 的模式。
8. 定义漏斗视图：每个视图对应第 1 步的一个问题，写明入口事件、各步骤、成功事件、以及每步所在触点；若某视图无法由第 6 步的事件构建，就回到第 6 步。
9. 采集基线并开始快照：六个触点中有三个会过期（仓库流量 14 天、某主要注册表时间序列 180 天、聊天场所按套餐），先记录今天的数值并安排导出，之后再埋点，因为无法回填。
10. 对每个触点做一次端到端追踪验证，然后排除内部流量（按 references/verification-playbook.md）；调试器全绿不算证据，追踪才算。
11. 按 references/tracking-plan-template.md 交付计划文档，带版本、负责人和复审触发条件；任何站点改版、文档生成器升级、同意横幅变更或新增触点后，重跑第 10 步。
12. 应用屏蔽分析修正：第三方分析脚本在文档站只能测到开发者受众中非开发者的那一半，且漏测率随页面变化；只信任同一来源内部的步骤转化率，绝不把被屏蔽的客户端数字与服务端数字取平均，把同意拒绝视为样本并在报告中说明。
13. 在每次转化上携带三个字段而非一个：source（渠道）、source_basis（证据类型：journey_linked / self_reported / campaign_window）、source_confidence（按证据质量判断，绝不从 basis 直接读出）；basis 与 confidence 必须一起报告。
14. 遵守三条归因规则：失败即关闭（合并有歧义时不记录任何内容）；窄幅猜测（campaign-window 启发式仅在日期落在唯一活动窗口内、落地页属于该活动、且标签当时有效时才使用，否则写 unknown）；绝不覆盖（回填只针对 source 为空的记录，且回填历史要视觉上分开）。
15. 事件分类长期规则：事件与属性用小写 snake_case；若已有计划则沿用其大小写；每个用户意图一个事件而非每个 UI 元素一个；重命名已上线事件会切断历史，应改为加属性或版本化；事件总数控制在一屏内；同一意图跨触点用同一事件名，差异由 surface 属性承载。
16. 链接标记规则：source 和 medium 用固定允许列表；全部小写、单一分隔符、无空格；只标记第三方点进来的链接，绝不标记内部文档链接；比较制品时按制品而非按活动打标；所有已发布标记链接登记在一张表中含负责人与发布日期；重定向链、短链和 OAuth 跳转必须保留查询串；线下触点用可念的 vanity 路径、二维码和注册时稳定的自报来源字段。
17. 通过质量门（四项全过才算完成）：决策覆盖率 100% 事件可回溯；已验证追踪 100% 主要转化事件在真实触点上端到端跑通；join coverage ≥ 80%（本技能自设基线，可由用户调整）；标签合规率 100% 已发布外链通过受控词表校验。
18. 对产出的数字加两条护栏：一个周期内事件少于约 30 个时，发布带日期的原始列表而非比率；任何被激励的数量指标都要配一个质量反向指标（如发布文章配每篇自然入口数、注册配该批次 30 天留存）。
19. 交付默认是一份 markdown 文档（决策、触点登记表、建设顺序、身份主线、事件表、属性注册表、标记词表、漏斗视图、基线、质量门结果、已知缺口）；单触点请求用同样结构但删掉无关章节。
20. 遇到「给我们定一个文档转化率目标」要拒绝：借来的转化目标衡量的是别家受众，应把目标设定转给 samber/developer-relations-skills@devrel-metrics，并提供能产出真实目标的基线采集计划。

适用边界 · 注意事项

• 用户还没决定哪些数字重要时——先转给 samber/developer-relations-skills@devrel-metrics 再回来。
• 只想要一次性回答某个问题、而非可持续复用资产时，应优先做标记与自报字段，而非快照任务与身份主线。
• 投入上限只有电子表格加月度导出时，应直接删除日志分析、产品侧事件和 CLI/SDK 遥测，而不是把它们排在末尾。