从 Google Analytics 4 迁移之前要核对的 8 件事

换统计工具在技术上微不足道，在组织上却很难。代码一分钟就装好；之后的那个月，新数字和旧数字对不上、三个看板还指着一个没人更新的属性，迁移就是在这里停住的。这份清单是我们陪团队从 Google Analytics 4 迁到 TapCub 时用的。它是有顺序的：每一项都让下一项更容易，前七项做完，最后的切换会平淡无奇。

一、盘点事件和转化

导出当前属性收到的事件列表，标出哪些是转化。大多数属性有三类事件：你从没配置过的自动事件、两年前某人为一次活动加的自定义事件，以及真正驱动决策的那五六个。只有最后一组需要在第一天就存在。把它们连同你依赖的参数一起写下来。

如果网站长得比埋点方案快，代码装上之后 TapCub 的全埋点与事件收件箱会从真实的点击和表单提交里提议事件，经常能揭示旧方案漏掉的那些。

二、对照指标定义

第一周大多数「数字不对」的对话都是定义不匹配。用户 vs 访客、互动会话 vs 会话、跳出率 vs 互动率：在任何人比较看板之前先把对照写下来。下面这张表是我们交接时给的。把它和迁移计划放在同一份共享文档里。

三、并行跑两到四周

把 TapCub 代码和现有标签一起装上，两边同时跑。两周是最少的，能看两遍完整的周周期；有月度报告的话四周更稳。期间比形状，不比总数：趋势线是否一起动、排在前面的页面是否相同、来源排名是否一致。一致了，定义就算对齐了，剩下的差距由定义差异解释。

一开始就定好退出条件，比如「排除机器人后日访客差距在 15% 以内，前十页面顺序一致，五个转化全部触发」。没有退出条件的并行运行会永远跑下去。

四、干净地安装，再映射自定义事件

把 TapCub 代码放进每个模板的 head，或者装建站平台的插件。然后把盘点里的每个自定义事件映射成同名同参数的 track() 调用，历史比较才读得通。对大多数网站这是十几行代码。安装指南覆盖了标签管理器和单页应用。

// 保留旧名字，同比对照才读得通
tapcub.track('begin_checkout', { value: 89, currency: 'USD' });
tapcub.track('purchase', { value: 89, currency: 'USD', order_id: 'A-10422' });
tapcub.track('generate_lead', { form: 'contact' });

// 识别登录用户，用于留存和档案
tapcub.identify('user_8f21', { plan: 'pro' });

五、重建漏斗和看板

列出每个指向旧属性的看板、定时报告和漏斗，以及各自的负责人。重建人们真正会打开的那些，其余的退役。通常团队会在这一刻发现一半的报表一年没人看过。借这个机会按漏斗检查清单，把漏斗定义在访客上并带上转化窗口。

新看板为读它的人建，别照抄旧的。每周给管理层看的看板需要五个数字和一条趋势；市场看板需要渠道、活动和带点击 ID 的 14 个广告平台；产品看板需要激活漏斗和留存矩阵。三个聚焦的看板比一个什么都想装的看板好维护得多。

六、权限、告警和集成

切换之前就邀请团队、设好角色，别等到有人找不到报表再说。把告警（流量下跌、转化下滑、错误激增）在 TapCub 里重新建好，切换后的那一周才不会是没人发现结账坏掉的那一周。重新接上你依赖点击 ID 的广告平台；TapCub 读 14 个平台的点击 ID，集成页列出了其余的。

七、导出你会想念的历史

历史数据不会在工具之间迁移；定义不同，迁了也没法比。导出以后会想引用的东西：最近两三年的月访客和转化、按季度的热门页面和来源。一张电子表格就够。和对照表放在一起，将来的比较才带着该有的注解。

八、挑一个安静的日子切换

挑一个低流量的日子，摘掉旧标签，确认那天 TapCub 的数字和前几天相像。把共享文档里的链接更新到新看板。旧属性保留一个季度的只读权限，以防有人要查历史数字，然后放手。前七项做完了，这一步就是十分钟的改动加一封邮件。

接下来一周还是会有一两个意外：某人私下建的报表、还在触发旧标签的落地页工具、没人知道的月度导出。迁移文档开着放一个月，把每个意外加进下一次的清单。