从 Google Analytics 迁移到 Matomo 的实用步骤
如何从 Google Analytics 迁移到 Matomo
从 Google Analytics 迁移到 Matomo，不只是换个界面这么简单。它会改变你的报表体系，而且是有后果的；最稳妥的做法，是先从小范围开始：一个站点、一个属性，或者一组活动。如果一上来就想全部迁移，第一周大概率都会耗在清理旧标签和争论数据上。这也是很多人搜索 Matomo 迁移教程 时最先需要弄清楚的事。
想要顺利起步，先在动手改追踪代码之前定义好“完成”是什么意思。一个务实的目标其实很简单：Matomo 里已经有关键报表，团队不用别人帮忙也能看懂，而 GA 只在切换期间保留作对照。这样就够了。如果你一句话说不清终点，说明这次迁移的范围定得太松了，也说明你还没真正回答 GA 转 Matomo 如何设置 这个问题。
有一句话值得直说：如何从 Google Analytics 迁移到 Matomo，关键不在工具本身，而在你要保护的报表范围。小型电商可能更关心结账、商品浏览和优惠券使用；内容站点可能更关心文章阅读、滚动深度和订阅留资。站点不同，切换方式就不同；但原则是一样的。
1. 先确定这次迁移里的“完成”到底指什么
先写一份范围说明，而且要尽量收窄。明确写出先迁移哪个站点、哪个属性、哪一组活动。如果业务方要求“整个账号一起上”，就要及时挡回去，只选一组报表先迁。只有一个目标的迁移可控；有五个目标的迁移，往往会变成一个永远收不住的项目。
把成功标准写成 10 分钟内能核对完的内容，而不是要争论 10 天的内容。比如：“Matomo 中能看到 Site A 的会话、转化和访问量最高的落地页”，以及“GA 只在接下来 2 周内保留用于对照”。这两句话就足够给团队划出边界。没有边界的话，总会有人在最不合适的时候再加一个看板需求。
同时也要写清失败线。如果 Matomo 没有抓到最关键的转化，或者业务方在重叠期无法核对数据，那就说明还没准备好切换。听起来有点严，但这能省下很多时间。
2. 盘点你不能丢的 Google Analytics 数据
在迁移任何东西之前，先列出所有重要的 GA 项目。把大家每天早上都会看的仪表盘、承载业务含义的自定义维度、和收入绑定的事件、转化、受众、过滤器，以及与归因相关的设置都列进去。没有这份清单就做迁移，本质上只是换一种说法的猜测。
写名称，不要写笼统描述。比如“付费搜索看板”比“营销相关内容”清楚得多；“表单提交事件”比“联系动作”更明确。如果某个报表真有人负责，就把负责人的名字写在旁边。这样以后有人说“我以为销售团队在用那个过滤器”时，你就知道该找谁确认。
并不是所有 GA 项都值得一比一重建，这很正常。去年很少有人用的受众分群，如果从来没影响过决策，可能就不值得在 Matomo 里再造一遍。重点不是保留所有对象，而是保住那 20% 真正在被使用的内容。
如果你在整理清单时需要一个简单的参考，也可以单独保留一份给奇怪页面和小众报表用的检查清单。类似的习惯在别处也很有用；比如，需要核对站点页面时，可以把 如何检查网站 当成一种快速参考模板。名字会变，但规则不变：先知道要找什么，再开始找。
3. 把 GA 概念映射到 Matomo 的对应项
做一张双列表：左边写 GA 术语，右边写 Matomo 术语或实现方式。哪些能直接对应、哪些不能直接对应，都写清楚。页面浏览、事件、目标、分群、自定义维度、活动追踪，这些都应该放进去。迁移从这一刻开始，才算真正落地，而不是停留在概念阶段。
有些映射很简单，有些就没那么直接。GA 的受众可能需要在 Matomo 里变成分群，或者改成另一种报表规则。GA 的归因设置在 Matomo 里未必有完全相同的行为，所以有时候不是硬搬旧答案，而是要重新定义问题。把这些写下来，因为一旦看板上线，大家很快就会忘记差异。
专门留一列写“意思相同，但逻辑不同”。这列很重要。如果 GA 和 Matomo 对某个指标的计算方式不同，团队必须在看到数字之前就知道。否则他们会以为迁移坏了，实际上只是定义变了。
如果团队平时就习惯保留结构化的参考页，这种映射方式其实和在目录里认真查找很像，比如 以 p 开头的梦境词典：一个词条、一个位置、一个含义。工具可能不同，但习惯是相通的。先对齐，再讨论。
4. 把切换安排成低风险过渡
迁移日期要认真挑。避开产品发布、活动高峰和报表截止日。周一上午切换通常最吵，周中安静时段往往更容易验证。一次低风险切换，远比一次轰轰烈烈的切换更靠谱。
要决定重叠期持续多久：3 天、1 周，还是更久。重叠期要足够长，方便对比结果；但也不能太长，不然大家会因为习惯继续同时维护两套系统。这个阶段里，要明确谁看报表、谁签字确认，以及如果数据不对，谁可以暂停切换。
验证只指定一个负责人，不要三个人。一个人可以收集分析、产品和营销的反馈，但最终拍板的人只能有一个。如果人人都“负责”切换，那就等于没人负责。这时候，小的追踪问题往往会拖上几个月。
访问权限的调整，最好等重叠期稳定之后再做。如果太早收紧 GA 权限，大家会慌，然后开始自己做表格补数据；如果拖太久，大家又会一直不去用 Matomo。这里时间点比仪式感更重要。
5. 先在 Matomo 里重建最关键的报表
不要试图把每一个 GA 视图都复制过来。先重建每天都要看的报表：来源流量、热门页面、主要转化，以及团队每周都会检查的那几个分群。如果某个报表不会影响决策，就先放一边。很多迁移之所以拖慢，并不是因为难，而是因为一开始就把所有东西都当成必须。
尽量使用 Matomo 原生设置。照搬 GA 的样子虽然看起来熟悉，但后续维护可能会更麻烦。更好的做法，是重建业务问题，而不是旧截图。如果 GA 需要四个标签页，而 Matomo 用两个面板就能回答同样的问题，那就用两个面板。
优先把最显眼的报表拿出来，别等别人来催。比如销售每天都要看线索质量，营销每天都要看活动流量，那这两个报表就应该最先重建。其余的可以稍后。大家通常能接受边角情况暂时缺失，但不能接受周一该看的报表不见了。
有些团队在梳理报表清单时，也会顺手查看别的站点参考流程，尤其当内容分散在多个页面上时更是如此。一个实用的例子是 如何检查网站，它说明了核对用户真正预期找到的页面有多重要。报表也是一样：必须是大家真正会用的那一份。
6. 用真实用户动作验证事件和目标追踪
测试要测真实动作，不只是打开页面。提交表单、完成购买、下载文件、点击外链，然后检查 Matomo 有没有按业务需要记录下来。快速测试有用，但系统化测试更能减少返工。
测试用例要短，而且要具体。“价格页提交联系表单”比“测试漏斗”更好；“使用优惠码完成结账”比“购买测试”更好。动作越清楚，问题越清楚。模糊的测试只会制造礼貌性的困惑。
在重叠期，把结果和 GA 对照，但不要指望完全一致。不同工具因为同意管理、计时方式或配置细节，可能会有轻微差异。更重要的问题是 Matomo 能不能稳定抓到同样的业务动作。如果不能，就在切换前先修标签或目标规则。
这个阶段也很适合把边缘情况记下来。比如，一个在新标签页打开的下载，可能需要和普通链接点击不同的触发方式。单一规则很少能第一次就覆盖所有行为，这很正常；所以测试清单最好短到一个下午就能重复跑完。
7. 训练团队使用 Matomo 的报表流程
先给分析师和相关方做一个 30 分钟的快速演示，然后再给他们一份书面路径，列出他们最常用的 3 到 4 个报表。告诉他们分群在哪、注释怎么处理、以及哪些 GA 的习惯已经不再适用。大家不需要听每个菜单的讲解，他们只需要知道周一答案在哪里。
用迁移后的真实站点举例。打开线索报表、产品报表和落地页报表，现场点一遍筛选条件。如果你能展示一个和营销团队在 GA 里使用的名称完全一致的活动报表，学习成本会立刻下降。截图有帮助，但现场点击更有用。
把差异说清楚。如果 GA 里的受众现在对应的是 Matomo 分群，就直接说明。如果已保存的报表位置变了，也要明确告诉大家。如果相关方想要一个不再以相同形式存在的指标，就直接给出新的流程，不要绕着旧工具讲故事。回答越直接，大家适应得越快。
有些团队会为经常查询的内容准备一个小型参考表，这也可以包括内容页。如果团队会处理知识类页面，那么像 以 k 开头的梦境词典 这样的链接，就是一个提醒：把内容分类整理好，能大大减少搜索时间。报表培训也是一样：一件事放在一个地方。
8. 交接后，逐步清理对 GA 的依赖
当 Matomo 中约定好的报表范围已经稳定后，就要列出所有还在依赖 GA 的地方。包括看板、标签、提醒、文档、SOP、浏览器书签，以及仍然指向 GA 的脚本。一个都不要漏查。旧链接往往会在你以为“都迁完了”之后，继续存活很久。
逐项删除或改写这些内容。写着“检查 GA”的看板备注，要改成“检查 Matomo”。如果某份操作手册要求每天早上都对照 GA，那就要么更新成新的流程，要么在它已无用途时直接归档。这里的清理工作虽然小，但很重要，因为它能防止旧习惯回潮。
保留最后一次对照检查，然后关闭这部分迁移范围内的 GA 窗口。如果团队还需要 GA 作为历史参考，就把它限制为只读，并设定复查日期；如果不需要，就收紧权限，去掉日常检查。GA 在日常流程里停留得越久，越难判断哪个系统才是唯一可信来源。
到了这个阶段，一个简单的维护习惯会很有帮助：每个月检查一次在用报表，而不是每个季度才看一次。15 分钟的检查，就能在下一个活动负责人接手前发现过时看板。现在做一点小清理，远比以后再来一次迁移便宜得多。
