在让 AI 自动找漏斗异常之前，先要确认每个事件都在说同一种业务语言。埋点不是事实本身，而是客户端、服务端或设备对“发生了什么”的一次声明；如果 iOS 的“绑定成功”代表点了完成按钮，Android 却代表服务端已确认连接，AI 越会分析，越可能把口径差异误判成增长机会。对 Momcozy APP，第一批 AI Product Analysis 能力不应只是会写 SQL，而应先有一层可版本化、可校验、能阻断坏结论的 Event Contract（事件契约）。
产品分析过去常见的旧问题是：大家都在看同一个事件名，却以为自己理解的是同一件事。产品经理把 device_bound 理解成设备已经可用，开发把它埋在“完成”按钮被点击时，数据分析师又拿它当首次价值。数字没有报错，但三个人回答的其实是三个问题。
Event Contract（事件契约），大白话是：在数据进入看板和 Agent 之前，先用一份可执行约定写清“什么业务事实才允许触发这个事件、由谁产生、必须带哪些上下文、哪个版本有效、什么情况不算”。生活类比是快递状态：“已创建运单”“快递员已揽件”“用户已签收”不能都叫“已送达”。扫描码格式正确，只能证明记录长得对；真正签收还需要对应的现实动作。
一份最小事件契约至少要有六项：业务定义、触发时点、生产来源、必需属性、版本、反例。Momcozy APP 的待验证例子是“首次稳定设备使用”：它也许应由可验证的设备或服务端结果产生，而不是由 UI 页面跳转产生；同时带匿名设备类型、APP / 系统 / 固件版本、结果时间和契约版本。若只发生按钮点击、请求发出或结果未知，就不能冒充稳定成功。
这不是说客户端事件都不可信。页面是否真实渲染、帮助是否被看见，只能由客户端更接近事实地记录；设备连接是否稳定、工具调用是否成功，则可能更适合设备或服务端确认。关键不是“全部改服务端”，而是给每一种事实选择最接近真相的生产者，并保留不同证据层级。
Snowplow：先按 schema 验证，再让事件进入可信数据区
数据结构应在进入分析前被机器校验；不符合约定的记录要被隔离，而不是悄悄混进漏斗。
关键事实
Snowplow 在 2026 年 8 月 20 日更新的官方文档中，把 schema（数据结构规则）定义为事件字段、字段含义与校验条件的共同约定。其管道会把事件与对应 schema 核对，只有结构有效的事件正常通过，failed events（失败事件）进入单独位置。文档还强调 schema 需要描述字段含义，并通过版本演进兼容新旧数据；“数据结构”则在 schema 之外继续保存草稿/发布状态、变更说明和被哪些 tracking plan（追踪计划）使用等元数据。
编辑视角它证明了什么： 这证明“定义—版本—自动验证—隔离失败记录”可以成为数据管道能力，而不是靠分析师记住口头约定。证据边界也很重要：结构正确不等于业务语义正确。一个格式完全合规的 device_bound，仍可能在错误的 UI 时点触发；schema 能防脏格式，不能替人定义什么才叫用户获得价值。
Mixpanel：不要“能埋的都埋”，先从 KPI 反推旅程与事件
Tracking Plan（追踪计划）不是事件清单，而是从业务问题反推“为了做这项判断，最少需要哪些证据”。
关键事实
Mixpanel 当前官方指南建议把 tracking plan 作为跨产品、数据与开发团队共享的唯一事实来源，并持续随实现变化更新。它给出的顺序是：先定义关键 KPI 与分析问题，再把 KPI 映射到用户旅程和不同成功路径，最后才把旅程翻译成事件、事件属性与用户属性。指南明确反对“什么都追踪”，因为这会制造开发成本和大量没人使用的数据。
编辑视角它证明了什么： 这支持“指标—旅程—事件”的倒推顺序，也说明事件治理首先是产品判断，不只是技术命名规范。但这是一套方法指南，不是增长实验；它没有证明建了 tracking plan 就会提高留存，也不能保证文档与线上实现永远一致。真正的缺口是：契约变更后，系统能否自动发现新旧版本漂移并阻断错误比较。
先认识这个人
Vijay Iyengar 当时是 Mixpanel 的产品负责人，有工程背景。这个 2023 年访谈并不新，但它点出了一个今天做 AI 分析更危险的问题：当数据源不稳定时，过去是人偶尔读错一张图；现在 Agent 可以持续、规模化地读错，再自动生成一套听起来合理的解释。
核心机制：移动端旧版本会让错误口径长期存活
访谈约 35:12 起，Vijay 认为很多团队把“产品分析”等同于在 Web、iOS、Android 客户端直接调用 SDK。按他的经验性表述，Web 端受广告拦截和 JavaScript 不可靠因素影响，可能丢失 20%–30% 的事件；移动端又有两层问题：iOS 与 Android 各自实现，容易产生“语义相同、名字或触发方式不同”的重复事件；埋点修复还依赖用户升级 APP，因此旧版错误事件会长期继续流入。
他的建议是把服务端作为默认事实源，再用客户端补充只有界面才能知道的上下文。服务端跨平台、由团队控制，修复后不必等待所有用户升级。但这个建议不能机械照抄：服务端知道请求成功，不一定知道用户是否真的看见帮助；设备任务也可能有离线、弱网和延迟回传。正确做法不是选边站，而是把“分配、真实曝光、请求、确认、稳定结果”拆成不同事件，并指定各自最可信的生产者。
AI 改变的不是埋点速度，而是契约执行力
AI 可以读取 tracking plan、schema、代码变更和真实事件样本，发现某个 APP 版本突然缺字段、两个平台对同一事件触发顺序不同，或客户端“成功”与服务端确认长期对不上。它也能生成修复候选和受影响分析清单。可是如果人从未定义事件语义，AI 只能检查格式，不能凭空知道“绑定成功”应该代表页面完成、连接建立还是稳定可用。
Vijay 的 20%–30% 是访谈中的经验说法，不应当作 Momcozy 或当前所有 Web 产品的基准。我们真正能借的是：事件质量包含覆盖、语义、版本和生产来源；任何一个不清楚，Agent 都没有资格把差异解释成用户行为。
以“事件契约守门 Agent”为例，完整链路不是自动生成埋点文档。
系统读取什么：已批准的事件定义、schema 与版本；客户端、服务端和设备的生产来源；APP、系统和固件版本；事件缺失、重复、延迟和顺序；客户端结果与服务端确认的对账；脱敏 VOC、历史实验与数据权限。母婴、儿童、健康和设备数据只按当前分析目的最小化使用，不能为了“补全用户旅程”默认跨场景拼接。
形成什么判断：把事件标为“语义与结构可用、结构不合规、版本混用、来源冲突、结果未确认、数据延迟或无法判断”；同时列出受影响的漏斗、cohort 和实验。系统必须区分“记录没有到达”与“行为没有发生”。
能做什么：自动隔离不合规记录；比较平台和版本之间的触发顺序；对旧事件加不可信标记；在影子模式对账客户端与服务端；提出契约、埋点或回填修复；在语义门未通过时阻断 Agent 发布“某群用户下降”的结论。它无权自行改指标定义、扩大数据用途、触达真实用户或修改生产策略。
如何看结果并更新策略：观察非法事件率、跨源对账差异、未知结果比例、修复后的可复现性，以及同一查询在契约版本固定后是否稳定。若所谓平台差异在统一语义后消失，就把旧洞察降级为测量问题；若差异仍存在，再进入行为原因与实验验证。
何时交给人：核心价值定义变化、新的数据用途、客户端与设备证据冲突、隐私授权不清、健康或儿童语境、历史数据无法重算，以及任何实验和上线决策，都交给人。写 tracking plan、让 AI 找缺字段属于 AI-assisted Operations（AI 辅助运营）；系统持续监测语义漂移、阻断坏结论、用修复结果更新数据可信度，才开始接近受治理的 AI-native Growth System（AI 原生增长系统）。
场景一：设备绑定与首次价值。 待验证假设是，“点击完成”“连接请求成功”“设备已连接”“在合理窗口内稳定可用”可能被混在一个成功事件里。可以借 Snowplow 的契约与失败隔离，为四层证据分别命名并版本化；最终价值优先依赖设备或服务端可验证结果，界面曝光仍由客户端记录。不能把弱网下尚未回传直接算失败，也不能为了对账收集超出必要范围的设备或家庭数据。最先需要的是：选一个当前被用于漏斗终点的事件，查清它在 iOS、Android、服务端和旧版本里到底由什么触发。
场景二：AI 助手与 BBM/VOC。 待验证假设是，“回答已生成”“回答已展示”“用户确认解决”“行为结果验证”“正确转人工”可能没有被拆开。可以借 Mixpanel 的倒推法：先定义“合格低风险任务被安全解决或正确接管”，再反推需要哪些事件。不能把消息生成当曝光，不能把聊天沉默当解决，也不能把敏感会话变成营销画像。最先要的证据是一份小样本人工校准，确认线上事件与真实结果状态能否对应。
不能照抄的地方：Momcozy 不是纯 Web SaaS。设备可能离线，结果会延迟，客户端有系统权限差异，稳定使用也可能需要时间窗口。因此“服务端即真相”仍然太粗；我们需要的是多来源证据的层级与对账规则，而不是把所有行为塞进一个仓库后宣称统一。
- Event Contract｜事件契约：规定一个事件代表什么、何时触发、由谁产生、怎样版本化。Momcozy 例子：只有满足约定的稳定结果，才允许产生
first_stable_device_use。 - Schema｜数据结构规则：规定事件必须有哪些字段、字段类型和允许值。Momcozy 例子：连接结果必须带契约版本和匿名设备类型；缺字段先隔离。
- Semantic Drift｜语义漂移：事件名字不变，真实含义却因平台、版本或实现变化而改变。Momcozy 例子：新版把“成功”改成服务端确认，旧版仍在按钮点击时上报。
- Source of Truth｜事实来源：对某类事实最有资格作证的系统。Momcozy 例子：帮助是否渲染由客户端作证，设备是否稳定连接优先由设备或服务端结果作证。
- Tracking Plan｜追踪计划：从业务问题和用户旅程反推需要哪些最小事件。Momcozy 例子：先定义首次稳定价值，再决定要记录资格、请求、确认和结果，而不是把所有点击都埋上。
给一个现有或假想的 “首次稳定设备使用”事件 写一页契约，不改生产、不触达用户：
- 用一句话写“什么真实业务事实发生时才算”；
- 写三个不算成功的反例：按钮点击、请求发出、结果未知；
- 指定最可信的生产来源，以及客户端需要补充的上下文；
- 写一组最小必要属性：APP / 系统 / 固件版本、契约版本与结果时间，按分析目的择要设计；
- 写一条旧版兼容规则和一条阻断分析的红灯。
产出物是一页“定义—反例—来源—字段—版本—红灯”事件契约。完成后能更新的判断是：我们当前缺的是更聪明的 AI 分析，还是缺一个能让 AI 知道哪些数据有资格被分析的事实层？最后只回答一个具体问题：Momcozy APP 里，现在哪一个看似最基础的“成功事件”，最可能在不同平台或版本中其实不是同一件事？