Rebrandly 迁移到 Urlik 的分析交接指南

定义分析交接范围

在碰任何一个链接之前，先明确对团队来说“分析连续性”意味着什么，也就是要先讲清楚短链接迁移分析连续性。对有些团队而言，这意味着在切换当天之前，Rebrandly 中的点击历史仍可用于旧报表，而未来的点击则转到 Urlik。对另一些团队来说，这还包括 Google Analytics 事件、CRM 归因，或市场部有人每周一早上 9 点查看的周报看板。

把范围写成一段话。尽量具体：哪些报表不能断、哪些日期范围最重要、以及上线后谁来负责对照结果。如果你正在寻找如何在不丢失分析数据的情况下从 Rebrandly 迁移到 Urlik，那么这个最初的决定，正是避免后面变成一团乱麻的关键；同样，提前想清楚 UTM链接跟踪怎么做，也能避免后续报表口径不一致。

一个小提醒。如果一个链接会被用于邮件、广告和二维码，那就意味着要核对三个不同的地方。不是一个。

盘点最重要的链接数据

不要从整个账户入手。先从那些真正影响决策、成本或报表截止时间的链接开始。通常包括付费媒体链接、与上线活动相关的活动链接，以及会持续按月累计点击的常青链接。

列一个四列表：短链接、目标地址、负责人、业务影响。黑五广告链接理应比上季度的测试链接更值得关注。播客推广链接如果仍会从旧节目说明中获得点击，也可能需要特殊处理，因为这些点击会在活动团队早已离开后继续出现。

• 有实际投放预算的高价值活动链接
• 付费社交和搜索链接
• 出现在个人简介、新闻简报和页脚中的常青链接
• 嵌入合作伙伴内容或二维码中的链接

短名单就够了。12 个真正有价值的链接，胜过 300 个没人看的链接。

在改动前导出 Rebrandly 数据

先保存当前状态。先从 Rebrandly 导出链接列表，再导出你能访问到的点击报表、日期筛选和标签数据。如果团队以后需要解释流量下滑，这些基线数据比记忆更重要。记忆会骗人。

把导出文件保存在两个地方：一个工作文件夹，一个带日期命名的归档文件夹。这个习惯看起来有点较真，直到有人来问上个月的点击量，而原始报表已经找不到了。

检查日期。晚上 11:50 拉取的报表和过了午夜之后拉取的报表，不是同一份报表。

制作并排的链接映射表

建立一张表，左边放旧的 Rebrandly 链接，右边放新的 Urlik 链接。加入目标 URL、活动名称、来源、媒介，以及任何必须保留的参数。这不是设计练习，而是一份需要快速回答问题的工作文档。

每个链接占一行。如果同一个目标分别用于邮件、付费社交和短信，就给每个版本各自单独一行。这样你就能看出追踪差异，而不用去读单元格备注，或者只靠链接名称猜测。

表格建立后，就要分配责任。一个人编辑；另一个人复核。两个编辑者通常会带来四个错误。

在 Urlik 中复现相同的活动标签

Urlik 应该沿用你之前使用的活动逻辑，这样迁移后报表仍然可以相互比较。尽量保持 UTM、命名规则和渠道标签的一致，然后记录任何不得不更改格式或大小写的地方。如果旧链接用的是 newsletter 而不是 email，除非有明确理由，否则就继续沿用这个选择。

这时候，另一份指南会很有帮助。如果你的团队已经在使用 短链接中的 UTM 跟踪是什么意思，就把那份操作说明里的取值与映射表中的取值对齐。重点不是完美，而是整个交接过程保持一致，这样同一场活动不会因为名字略有不同而出现在三份不同报表里。

注意大小写和标点。“Paid Social”、“paid_social”和“paid social”对人类来说看起来差不多，但在不那么宽容的工具里，可能会把报表拆成几份。

还有一点：如果链接目标地址本身已经带有参数，要先决定 Urlik 是追加、替换，还是保留这些参数。这个决定会很快改变归因结果。

分批迁移并对比结果

先迁移一小批。十个链接是比较合理的起点，前提是这批里至少包含一个活动链接、一个常青链接，以及一个流量较高的链接。该批上线后，在动剩下的链接之前，先对比 Rebrandly 和 Urlik 的点击量、引荐来源和落地页表现。

用对比来发现实际问题。UTM 拼写错误可能会把流量导入错误渠道。目标 URL 多了一次跳转可能会增加延迟。合作伙伴链接在桌面浏览器里能用，却可能在移动应用内失效。这类问题通常会在第一批里暴露，而不是第五十批。

批量大小要控制在便于排查的范围内。如果哪里不对，你需要知道是这 10 个链接里的哪一个出了问题，而不是 200 个里的哪一个。

如果你的活动依赖精确标签，下一批之前，最好先复习一下 अभियानों के लिए UTM लिंक ट्रैकिंग。这篇内容尤其适合那些需要在付费、邮件和社交渠道中使用统一活动标签，而不想每个季度都重新发明一套规则的团队。

把历史报表与实时表现分开

不要把旧的 Rebrandly 数据和新的 Urlik 数据混在一起，好像什么都没变一样。标出切换日期，然后把旧报表放进单独的文件夹、仪表板标签页或标签集合中。原因很简单：历史点击属于 Rebrandly，切换之后的实时点击属于 Urlik。

当有人要求做月度环比时，这一点尤其重要。把两个系统混在一起的一张图，可能会掩盖真实趋势，也可能凭空制造一个趋势。如果团队想要干净的对比，就把边界展示出来。必要时在图上画一条竖线。那条线很诚实。

用直白的话记录交接：“Rebrandly 追踪到 5 月 14 日的链接；Urlik 从 5 月 15 日起开始追踪。”这一句话，日后就可能帮你省下一小时的来回沟通。

如果你的链接是通过印刷物分发的，也不要忘记报告链路中的实体部分。同样的边界逻辑也适用于 प्रिंटेड सामग्री के लिए डायनामिक क्यूआर，因为海报或传单即使在数字活动已经变化之后，仍可能在几周内持续带来点击。

确认迁移后的报表与责任归属

切换完成后，确认仪表板、同事以及所有已连接的工具都在读取 Urlik，而不是旧的 Rebrandly 设置。先检查最显眼的地方：共享仪表板、定期邮件报表，以及任何按计划拉取链接数据的 BI 工具。然后再检查不那么显眼的地方，比如销售人员保存的报表，或者三个月前做好的客户演示文稿。

责任归属在这里很重要。明确第一周每天检查 Urlik 的人、负责核对差异的人，以及回答销售或财务问题的人。如果没有人对报表负责，那报表就会反过来支配所有人。

留意那些仍需人工对账的缺口。比如：只存在于 Rebrandly 中的旧点击、缓存了旧短链接的合作伙伴，或者同事在上线后又把旧链接复制到了新的 Slack 消息里。这些问题很烦，但如果有人在找，它们是看得见的。

对于共享账户权限的团队，还要确保相关人员仍然理解平台条款和数据处理规则。如果你的报表系统会接触 Google 服务，尤其是当用户把看板、表单或登录数据接入同一套活动流程时，隐私政策——隐私与条款以及相关账户设置就很重要。

用固定清单检查上线后的第一周

把前 7 天当作受控观察期。每天对照一小部分链接，确认点击量在变化，并检查是否有链接失效或标签缺失。7 天足够发现大多数错误，也足够在习惯固化之前修正它们。

检查清单要短。确认目标 URL、确认活动标签、确认分析来源、确认负责人。每天四项检查，持续一周。这样就足以在数据难以分辨之前，发现错误跳转或缺失参数。

如果某个链接在两个系统里都还有效，就明确标注它。归属混乱会带来数据混乱，数据混乱会引发争论。第一周没人想面对这个。

如果报表依赖更广泛的账户规则，同一个团队也应该复核他们已经在使用的平台政策页面，包括 google 服务条款——隐私。这不是无用功；它能在数据在平台与人员之间流转时，保持报表链路干净。

统一使用 Urlik 的命名和路由规则

第一批稳定之后，就要让 Urlik 这一侧保持纪律。不同团队使用相同的命名方式，相同类型的活动使用相同的路由逻辑，除非业务理由非常明确，否则不要随意开特例。少数例外可以接受。十个例外就会变成一套新系统。

这也是标准化谁能创建链接、谁能编辑链接的好时机。如果三个人都能重命名一个线上链接，分析质量会很快漂移。每个活动一个负责人，比多人一起猜更清晰。

最后再检查一次。确保新的 Urlik 链接是所有新创意、新邮件和新合作伙伴素材中唯一出现的版本。如果旧的 Rebrandly 链接仍然出现在新素材里，那么即使仪表板显示迁移已经完成，实际上也还没有结束。

对于依赖共享文档的团队，建议保留一个参考页面，写明迁移后的确切规则，并在内部文档中链接到它。如果同事需要自己去找规则，他们很可能会直接跳过。坏链接就是这样活下来的。