开发者 Changelog 分发归因：发布身份、触达凭据与转化窗口

同一条 Changelog 可能先成为 GitHub Release，再进入 Atom feed、邮件、Webhook、社区帖子和产品内通知。运营面板常把“发送成功”“链接被安全扫描器打开”和“用户升级 SDK”揉成一次转化，最后给最后一个 UTM 全部功劳。正确做法不是寻找更长的 query string，而是让发布、分发、触达和采用分别留下可验证凭据。事件驱动架构解释生产者与消费者解耦，本篇进一步要求每条营销事件都能回到同一发布身份。

这套归因不衡量搜索抓取或索引，SEO 内容刷新证据账本负责那个边界；它也不计算收入、发票或 COGS，AI 运营毛利对账接收最终汇总后另行处理。这里的终点只是预先定义的开发者采用动作。

发布记录必须先于渠道素材

发布系统先写不可变的 developer.release.v1，固定 releaseId、revision、仓库与制品摘要、兼容范围、变更严重度、文档 diff 摘要、发布时间及采用谓词。采用可以是“在受支持客户端首次上报 SDK 4.2 user-agent”或“新 API 首次成功调用”，不能用任意页面点击代替。勘误发布新 revision 并声明 corrects，禁止修改原记录后继续复用其摘要。

schema: developer.release.v1
releaseId: sdk-node-4.2.1
revision: 2
artifact: sha256:90e...
docsDiff: sha256:3a1...
adoptionPredicate: sdk.user-agent == 4.2.1
corrects: sdk-node-4.2.1@1

Atom entry 的稳定 ID 映射 releaseId，updated 只表达 revision 更新时间；GitHub Release、邮件 HTML、Webhook JSON 和社区短文则各有 renditionDigest。所有链接携带短期、签名且不含账号信息的 touchId，服务端解析后立即映射到 release 与渠道版本。REST API 版本控制保护外部调用契约，这里的 release revision 保护传播中的语义身份。

每次投递写 changelog.delivery.v1：deliveryId、release revision、channel、audience snapshot 摘要、rendition 摘要、发送 generation、同意用途、attempt 和供应商 receipt。Webhook 用 HTTP Message Signatures 验证消息内容、目标和时间边界；重试沿用 delivery 身份并递增 attempt。RSS 拉取无法证明个人阅读，只能记 feed fetch；邮件供应商接受也只是 ACCEPTED_BY_PROVIDER，不是 human exposure。

逐层呈现五个分母

报表按 eligible -> delivered -> observable_exposure -> engaged -> adopted 展开。每层给出独立分母和 UNOBSERVABLE：RSS 客户端可能不给曝光回执，隐私代理可能预取图片，企业安全网关会扫描链接。点击先依据已版本化的 bot/scanner 规则分类，未知 user-agent 进入 UNKNOWN_ACTOR，不能自动算人。真正 adopted 由服务端 API 或包遥测产生的版本凭据决定，并以幂等 adoptionId 去重。

归因规则在发布前写入 changelog.attributionPolicy.v1，固定窗口、允许渠道、同一组织的合并方式、迟到水位和同意要求。默认报告“合格触点后的采用”以及各渠道的关联计数，不强迫多次触点只有一个赢家；这类观察性连接不能解释为渠道造成的净增量。需要因果结论时，必须把 release 与 cohort 交给开发者 Launch 留出实验预先随机分配。窗口从可观察触达开始；只有投递回执的渠道另列 delivery-assisted，不伪造曝光时间。AI 产品留存可以继续观察采用后的持续行为，但不能反过来改写本次触点。

subjectRef 使用站内、用途限定的伪名，禁止把邮件 hash 当跨渠道万能身份。每个归因事件携带 consentSnapshotId、用途、policy revision 和撤回 generation。用户拒绝营销测量仍能阅读公开 Changelog；撤回后停止新的用户级连接，按保留策略删除映射并写 deletion receipt，历史匿名总量只能在满足既定聚合门槛时保留。AI 应用数据隐私给出更广的合规框架，这里把同意状态固化到每次连接决策。

用伪触达和迟到事件攻击账本

故障测试让邮件扫描器在投递前点击、Atom reader 重复抓取、Webhook 因密钥轮换重放、短链 302 丢失参数、同一开发者跨设备采用、组织成员转发链接、投递回执晚三天、客户端时钟倒退、release 勘误与旧素材并存，以及用户在点击后撤回同意。还要让渠道供应商返回 202 后永久丢弃消息。系统必须保留“提供方接受”与“最终投递未知”的差别，水位到达前不封账，封账后用修正分录而非覆盖历史。

接受门要求：所有 rendition 可追溯到唯一 release revision 的比例 100%；签名投递验证率 100%；重复投递与重放对采用数影响为 0；已知扫描器对抗样本误计为 human 的比例为 0；无合格同意的用户级连接为 0；99% 可观测回执在声明的 48 小时水位内进入；无法归因的采用必须单列且总量守恒。渠道关联报表至少同时显示 eligible、delivered、adopted、样本量和区间，并醒目标为非因果；缺任何一项就不做胜负排序。

新账本先旁路消费旧渠道事件，连续两个发布周期对比旧报表，只报告差异；再选择一个低风险 feed 和 5% 邮件 cohort 写入新 attribution。若事件守恒失败、未知 actor 超过 3%、撤回传播超过 24 小时或任何渠道采用数被重复放大，立即停止新 generation 的发送并把链接 alias 切回上一版。已发消息无法召回，因此回滚重点是停止后续投递、撤销短链解析和恢复旧 reader，而不是删除已发生的回执。