网站统计分析从百度统计迁出前，先备份这3样东西
目录索引
- 网站统计分析迁移前，先把三样东西备份好
- 历史报表为什么迁不过去
- 事件清单怎么整理成一张表
- 来源参数与自定义参数怎么留
- 迁移的时间线：从定方案到摘掉旧代码
- 迁移后怎么对账
- 迁移里最容易被跳过的一步
- 什么情况下先不迁
- 常见问题
- 延伸阅读
网站统计分析迁移，先备份三样再换代码：历史报表导出、自定义事件清单、UTM 与自定义参数。三样齐了，再双跑两周对账，旧数据才不会变成断点。
换工具这件事，返工点几乎都不在代码上。代码半小时就能换完，真正拖住人的是“想回头比一个数，发现旧报表已经过期、事件名对不上”。
图 1：三样各自对应一个“迁过去就没了”的东西。
▌ 网站统计分析迁移前，先把三样东西备份好
| 备份项 | 具体是什么 | 迁丢了的后果 |
|---|---|---|
| 历史报表 | 近 12 个月的周粒度报表导出（CSV 或 PDF） | 同比、环比从零开始，年度目标没法复盘 |
| 事件清单 | 自定义事件的名称、触发条件、属性 | 新后台事件名对不上，历史转化率断层 |
| 来源参数 | UTM 命名规则、自定义渠道参数 | 渠道归因重来一遍，投放效果无法对比 |
三样之外还有一样容易被忽略：取数口径说明。同一个“转化率”，一边按访问次数算、一边按访客算，差一倍都正常，没有说明就永远说不清。
备份的动作很小，代价很大。等新后台跑了一个月再想补，旧工具那边的数据多半已经按保留期清掉了。
▌ 历史报表为什么迁不过去
网站统计分析的底层是 Cookie 与访问记录。两家工具的 Cookie 不同、会话切分规则不同、去重键不同，原始明细本来就没法一一对应。
能做的是保留“看得懂的部分”：月度或周度总量、来源结构、页面排行、转化漏斗，导出成表格，作为迁移后的对照基线。
导出的粒度按周就够。按天导出量太大，按月又看不出波动；12 个月的周粒度，十几张表，足够支撑一年的复盘。
旧工具的网站流量统计报表里，字段名和计算方式都不一样，导出后先统一列名，再拼成一张总表，后面才有得比。
如果旧工具支持计划导出，迁移前把自动导出先开起来，避免最后一周的数据要靠截图补。
▌ 事件清单怎么整理成一张表
图 2：四列齐了才算能迁，缺一列后面就要返工。
事件清单不是给开发看的技术文档，是给运营看的对照表。至少四列：事件名、触发条件、属性、对应业务动作。
我们建议再加一列“迁不迁”：高频、强业务相关的事件优先迁；只在某个活动用过一次的事件，直接放弃。清单从 30 条压到 12 条以内，迁移工作量差三倍。
整理的顺序建议从高到低：先抽三个直接决定收入的业务动作（注册、下单、咨询），把它们的触发条件写死；再补浏览类的行为事件；最后才是按钮级的细枝末节。
整理时会发现两类问题：同一个动作在不同页面起了不同的名字；同一个名字对应了两种触发条件。这两类不解决，迁过去还是乱的。
表里的“触发条件”要写成可验证的一句话，比如“提交成功后触发一次”，而不是“用户提交时”。前者能写测试用例，后者只能靠猜。
属性列也要写清类型。金额写成字符串，迁过去之后排序会乱；日期写成时间戳，跨时区就会差一天。这些细节在迁移当天不会暴露，一个月后做月度复盘时才会集中冒出来。
清单整理完，让技术和运营各自念一遍，两边念出来的意思不一样，说明还没写清。
▌ 来源参数与自定义参数怎么留
UTM 是跨工具最容易搬的东西：它跟着链接走，不依赖哪家工具。把现有命名规则整理成一张表，迁移后原样沿用，渠道数据至少能对上。
自定义参数就没这么幸运。不同工具对自定义维度的数量、长度、是否区分大小写要求不同，迁之前要逐条核对，超出限制的合并或降级。
参数表要留版本号。同一个渠道名，今年叫“信息流A”，明年叫“信息流-a”，归因报表就会裂成两个渠道；版本号能让后来的人知道名字改过。
一个实用做法：迁移前把参数表发给运营和投放各一份，新链接一律按新表生成，旧链接在双跑期结束前不动。
▌ 迁移的时间线：从定方案到摘掉旧代码
图 3：最容易压缩的是最后两步，也是最不该压缩的两步。
| 时点 | 做什么 | 谁负责 |
|---|---|---|
| 提前两周 | 备份三样，导出周粒度报表，整理事件清单 | 运营 |
| 提前一周 | 参数表定稿，新链接按新表生成 | 投放 |
| 上线当天 | 新旧代码并行，确认新后台有数 | 前端 |
| 上线第一周 | 每天看一次总量与事件数，记差异 | 运营 |
| 上线第二周 | 对账收口，差异写进说明 | 运营 + 技术 |
| 第三周 | 摘掉旧代码，旧报表归档 | 技术 |
这张表最容易压缩的是最后两行。对账没做完就摘旧代码，等于把参照物删掉；旧报表没归档，半年后复盘只能凭记忆。
时间线的关键在最后一行。很多人对完账就把旧代码删了，报表却没归档，半年后想复盘找不到基线。
▌ 迁移后怎么对账
| 对账项 | 看什么 | 通过条件 |
|---|---|---|
| 总量 | 同一周的 UV、PV | 差异落在可解释范围内，比如过滤规则不同 |
| 来源结构 | 自然搜索、直接访问、外部链接的占比 | 三类排序一致，占比差异能说出原因 |
| 事件数 | 三个高频事件的触发次数 | 量级一致，差异来自触发条件写法 |
| 转化 | 同一漏斗的步骤人数 | 步骤间转化率趋势一致 |
对账至少跑两周。一周不够，因为周中与周末的流量结构差异会掩盖问题。
对账结果要写成一句话存档，比如“总量差 4%，来自过滤规则；事件数一致”。三个月后再有人问起，这句话比一堆截图有用。
双跑期间两边代码同时存在，页面会多一次请求，这是正常代价，别为了省这一次请求提前关掉旧代码。
两周后如果网站流量统计的总量差在 5% 以内、来源结构排序一致，就可以摘掉旧代码；差得多，先查过滤规则与去重键，别急着切换。
（示例数字，需用自有数据校准）
▌ 迁移里最容易被跳过的一步
最容易被跳过的是“迁完之后谁看哪张表”。工具换了，看数的人没换，权限没配，第一周就会出现“我怎么看不到原来那张报表”。
456数据的权限管理按价格页对比表，免费版为“基础”、专业版起为“高级”，子账号可以单独配可见应用，迁移时按岗位分一遍，比事后补权限省事。
456数据的「访问分析 → 来源渠道」把渠道、媒介、计划、单元、关键词五个维度放在一处，迁移后 UTM 表直接对上这一组；「搜索引擎」与「来源关键词」单独成组，自然搜索的变化能分开看。
456数据的网站端免费版 ￥0/月，年额度 100万PV/50万事件量，只含网站数据分析；迁移先用免费版跑通，确认数据能对上，再按需要的端和额度升档。
迁移最怕的不是换错工具，是换完之后没人说得清“上周那个数为什么变了”。把备份、对账、权限三件事按上面的时间线排进日程，这件事就有解。
▌ 什么情况下先不迁
只用了基础流量报表、没有自定义事件、也不做同比复盘的站，迁移收益有限，先把现有报表看顺更划算。
刚做完一次大改版、或者正处在投放高峰期，先别动。迁移期间两套代码并存，出问题不好定位是谁引起的。
团队里只有一个兼职的人在管数据时，也建议晚点迁。迁移期的对账需要有人每天看一次数，没人盯，双跑就变成了“跑着跑着自己忘了”。
▌ 常见问题
迁移要停机吗
不用。两套代码可以并行，迁移期让两边同时收数，对完账再摘掉旧代码，页面全程只有一次额外请求。
历史数据能迁到新工具里吗
原始明细迁不过去。能做的是把周粒度报表导出留档，新工具从切换那天开始积累，同比靠留档的表来算。
UTM 参数需要重新命名吗
不需要。UTM 跟着链接走，命名规则原样沿用即可；换命名反而会让渠道数据断层。
迁移会影响已有的报表链接吗
会。旧报表的分享链接、书签、嵌在周报模板里的链接都会失效，迁移前把这些链接列出来，逐个换成新地址。
双跑要跑多久
两周起步。一周的数据容易受周末影响，两周才覆盖一个完整的流量周期，差异也更容易定位。
▌ 延伸阅读
网站数据分析与流量统计平台：网站端六项能力与三步接入的说明。
网站、App、小程序怎么选统计方案：一张矩阵定档：按端覆盖与档位组合给出的选型矩阵。
四档套餐价格与额度对照：四档的年额度与能力边界逐行对照。
