技能介绍

要解决的问题

小程序首页的访问通常来自多个入口：搜索、分享卡片、订阅消息、线下扫码、广告落地页。真正麻烦的不是"没有数据"，而是口径不统一：entry 字段有十几种拼法，scene 值在不同版本被改写，埋点事件名在迭代中被废弃。结果运营手里那份"来源分布"回答不了"这个活动到底带来多少下单"，归因靠口头共识，人走了口径就散。

这个技能只做一件事：把首页流量标记成稳定、可读、可复算的归因字段表，再用点击率复查这张表是否真的能用。

技能如何工作

先对齐证据：核对访问来源、页面点击与下单路径，标记数据日期、来源、缺失项和不可比较口径；资料不足时先输出补证据清单，不猜。
编码来源：为每个入口生成唯一且可读的 source_code，区分首次触点与末次触点，并写明人工归因的使用场景。
写死硬约束：把首屏位置、加载速度、活动库存受限作为场景约束，任何方案不得绕过。
处理冲突：跨设备、口头到店、重复来源的冲突规则在表里留痕，而不是复盘时临时决定。
交付核验：用页面版本、埋点和订单来源做交叉核验，以 首页到目标页点击率 作为复查指标；没有实际数据时只给测量口径，不虚构结果。

适用边界

不承诺流量、转化率、收入、排名或活动效果，也不替代全盘战略、平台操作、合同与合规审批。涉及价格、促销、广告、个人信息和平台规则时，先列出需要业务或法务确认的事项。处理会员、客户或活动参与者数据时只用完成任务所需的最小信息，并提醒去标识化。关键条件不满足时输出"暂不可交付"，列出缺失信息和下一步补证据动作，不用空泛建议填满模板。