给达人的链接套了跳转和短链，上线前怎样检查追踪有没有丢？
保存每层链接，按实际平台入口和设备测试，分别确认到达位置与分析记录。附链路验收表和最终链接确认邮件。
达人链接能打开，但报告里没有预期来源。先不要认定是短链把参数“吃掉了”。把原始链接、跳转链接、短链及实际发布入口依次列出，再从目标设备和平台点击测试，分别核对跳转是否正确、分析系统是否记录了约定的数据。
一位运营者描述过类似链路：AppsFlyer 链接追加 UTM 后，经 Bitly 缩短并用于 Instagram，但没有看到预期归因数据。帖子能证明其排查需求，无法单凭这一描述定位技术原因。
先说明要验收什么数据，再检查链接
短链点击、网站访问、App 打开、安装和购买事件，属于不同观察点。先写明本次希望在哪个系统、哪张报告、哪个字段看到什么结果。否则“后台没数据”可能只是大家查看的指标不同。
OneCrew 能帮助团队整理达人邮件和工作表。可以记录原始地址、最终发布地址、目标事件、测试负责人和结果依据，再从已有沟通准备链接确认草稿。技术测试在实际链接与分析工具中进行，合作记录则让运营和技术同事使用同一版信息。
把每一层地址保存下来
按点击顺序列出平台入口、短链、跳转服务和最终网页或 App 位置。保存创建时的目标地址与参数，检查是否重复添加、大小写不一致、被复制截断，或者修改了短链所指向的旧目标。
Google Analytics 官方说明，UTM 用于识别带来网站流量的活动，参数值区分大小写。Bitly 的官方操作则把 UTM 加在目标地址上，再生成短链。短网址表面看不到 UTM，并不能证明参数已经丢失；需要检查它实际指向的完整地址。
| 验收层 | 检查什么 | 保留什么证据 |
|---|---|---|
| 发布入口 | 达人实际将链接放在哪里 | 平台、账号、入口与测试时间 |
| 短链与跳转 | 各层目标是否是约定版本 | 地址链、参数与实际落点 |
| 网页或 App | 到达的位置和行为是否正确 | 设备、安装状态、操作结果 |
| 分析系统 | 约定事件与来源是否可核对 | 测试标识、报告位置、确认人 |
从真正发布的入口走一遍
桌面浏览器粘贴成功，不能代表手机上的社交 App 内点击成功。按本次目标用户场景测试，记录设备、系统、浏览器或 App，以及目标 App 是否已安装。涉及安装或深度链接时，交给熟悉配置的同事按对应服务的测试方法执行。
AppsFlyer 的 OneLink 文档区分链接行为与不同测试条件，并提供社交 App 跳转排查说明。UTM 字段也不能直接替代 App 归因配置。必要时分别验证网页访问和 App 内事件，不要求两个系统的所有数字天然相等。
用 OneCrew 工作表保存每个测试场景的实际结论：已到达、事件待核对、来源不符或技术处理中。随后让它准备只包含未解决项的沟通草稿，例如请分析负责人确认某次测试的记录，而不是笼统告诉达人“链接坏了”。
没有数据时，先保留证据再逐层定位
由分析负责人核对数据处理时间、测试设备与事件配置、同意状态、过滤条件及报告口径。不要在原链接上随意加新参数、再缩短一次后反复试，因为这样会不断引入新版本。每次调整都记录改变了哪一层，并在相同条件下重新测试。
主题：［活动］最终发布链接与测试确认
你好［名字］，本次请使用［最终链接］，放在［具体平台入口］，版本为［日期／编号］。请不要另行改写参数或再套一层短链；需要调整时先回传给［负责人］。
目前已完成［具体测试］，仍待确认［如有］。全部约定项目确认后，我们会回传可使用的最终结论。上线后请提供实际入口或发布链接，便于按同一路径复核。
如果后续涉及按播放数据结算，还需另外确认 播放量达标就加钱，达人合作奖金到底按哪个数算？来补充。
在 OneCrew 中先建立一条完整链路记录，再把“能到达”和“能在约定系统核对数据”分别写清楚。一次验收应留下最终地址、测试条件和负责人的结果。
