将网站分析从 Matomo 迁移到 Astrina

如何将网站分析从 Matomo 迁移到 Astrina

如果你正在规划如何将网站分析从 Matomo 迁移到 Astrina，先从一个明确且范围较小的目标开始：替换团队每天查看的报表，而不是把 Matomo 历史里存过的每一条细节都搬过去。这个思路很重要，因为小范围迁移更容易验证、更容易解释，也不太可能做到一半就卡住。

本指南默认你会采用一次务实的切换。你可以保留一些 Matomo 导出文件作为参考，但没必要重建每一个自定义维度、每一份归档报表，或那些只有某个人才记得的服务器端特殊逻辑。很好，其他的先放着。

1. 找出可以放心舍弃的 Matomo 功能

先列出大家在正常一周里真正会用到的 Matomo 内容。对很多团队来说，这些通常是页面浏览量、来源、少量目标，以及可能几个事件标签。如果 90 天内没人打开过某个报表，它通常就可以考虑不迁移了。

不要把 Matomo 的每个功能都当成神圣不可动。为三月份某个活动做的自定义细分，和销售每周一都会看的核心转化报表，本来就不是一回事。前者只是记忆，后者才是工作流。

也要看配置复杂度。如果 Matomo 依赖服务器端规则、特殊插件，或者只有因为站点上还留着旧标签才勉强能工作的追踪逻辑，那就很说明问题：这种东西不该原样搬过去。Astrina 最适合那种两分钟就能让另一个人讲明白的简单配置，尤其适合先完成 Astrina 追踪配置与验证，再逐步扩展。

一个很好用的筛选标准是：如果某个 Matomo 功能不会影响决策、会议，或者没人会定期导出的报表，那它大概率可以留在旧系统里。这不是忽视，这是分诊。

2. 只导出你仍然需要参考的最少量 Matomo 数据

只导出你在过渡期间真正会查阅的内容。最近的报表快照通常就足够做对比了，尤其是能覆盖流量、热门页面、目标和事件名称的时候。把它们保存成之后还能搜索的文件。埋在聊天记录里的截图不算记录。

保留一份简短清单，列出目标名称、事件标签，以及任何能解释异常追踪行为的备注。比如，Matomo 里某个按钮点击叫“Lead Form Submit”，但它其实要等感谢页加载后才触发，那就原样记下来。你需要的是准确措辞，不是回忆。

如果你们团队有追踪表格，也一并导出。日期、页面、事件名、目标名和负责人就够了。五列信息，可能能省掉五次会议。

不要因为有导出按钮就把所有内容都导出来。大而全的归档会制造一种虚假的安全感，最后却没人会去打开。小而精的导出更容易审计、更容易比较，也更容易下个月交给别人接手。

对于把技术说明保存在 wiki 里的团队，可以单独建一页写清楚要点：Matomo 跟踪了什么、哪些报表重要，以及哪些数据点是刻意不再保留的。这一页就会成为两个系统之间的桥梁。

3. 以实用方式把 Matomo 概念映射到 Astrina

接下来，把少量 Matomo 项目转换成 Astrina 里的对应概念。页面浏览量还是页面浏览量。目标变成你最关心的转化点。事件仍然是事件，但真正会影响报表或决策的那些，才需要先重建。

要按优先级思考，不要追求完美。如果 Matomo 有 18 个事件标签，而 Astrina 只需要 4 个就能支撑当前团队的工作流，那就先把这 4 个搭起来。其余 14 个，等到有人带着真实使用场景来提需求时再说。

这也是决定哪些内容要主动舍弃的时机。旧的活动维度、过时的测试目标，以及一次性的筛选条件，只要不支持当前报表，就可以不带走。迁移不是博物馆展览。

有些团队想保留 Matomo 的每一套命名习惯，因为这会让他们觉得更安全。但通常这只是在新工具里继续延续旧混乱。如果 Matomo 里的标签本来就含糊，现在就把它修正掉。“CTA click”远不如“定价页演示申请点击”有用。

如果你需要一个参考来理解新系统里的流量来源，可以看看astrina 流量来源数字的含义。当来源名称和旧的 Matomo 标签不完全一致时，这会很有帮助。

4. 只在 Astrina 中重建最关键的追踪

先把 Astrina 的核心分析配置好。也就是团队每周都会查看的页面、事件和转化。你不是在一行一行复刻 Matomo，而是在恢复那些能推动决策的衡量数据。

把 Astrina 追踪代码安装到最适合你技术栈、同时又最简单的位置。如果你的网站使用标签管理器，就把实现保持得尽量小且有文档记录。如果你更喜欢直接放代码，就记清楚代码放在哪里、由谁负责。两个人知道总比没人知道好。

先建立页面浏览量基线，其他都放后面。如果 Astrina 没看到正确的页面，后面所有报表都会很乱。然后一个一个添加最重要的事件，并在浏览器里逐个测试。事件名称里藏着一个小拼写错误，这是迁移里最经典的坑之一。

不要照搬每一个 Matomo 触发条件。只重建当前真正重要的交互：表单提交、定价点击、注册开始、文件下载，或者团队确实在用的其他行为。如果某个历史事件从来没影响过报表，它就不值得重新搭一遍。

如果你的安装需要一条清晰的配置路径，可以直接使用 Astrina 的 agent 安装页面：*。这是从“我们要切换”到“我们已经重新有数据了”最快的方式。

对于从更技术化的 Matomo 部署迁移过来的团队，把书面检查清单放在浏览器标签页旁边会很有用。第 1 步：确认基础页面浏览标签。第 2 步：添加第一个转化。第 3 步：核对事件名称是否和参考表一致。第 4 步：检查来源和落地页是否合理。简单，往往比花哨更好。

5. 验证 Astrina 是否抓到了正确的交互

验证过程应该简短而明确。用真实浏览器打开网站，触发你刚重建的前 3 个交互，确认 Astrina 都有记录。如果注册按钮触发了，但感谢页没有记录，你就在它变成报表错误之前发现了问题。

至少检查 2 到 3 个有代表性的页面浏览量，而不只是首页。博客文章、产品页和联系页通常就足够说明问题。如果这些页面的表现不一样，先修正模式，再把配置交给团队使用。

然后把新数据和你导出的 Matomo 快照做对比。你不是在追求最后一位访问数都完全一致，而是在确认同类型的交互都能看见，而且没有明显丢失。20 分钟的 sanity check，常常能避免一整周的怀疑。

如果你想更深入地看流量质量和结果之间的关系，可以读是否应该信任 astrina 流量。当有人问“访问看起来没问题，为什么线索却没有增长”时，这会很有用。

也要留意机器人流量。如果某个峰值看起来很奇怪，文章如何判断 astrina 是否是可以帮助你把正常波动和可疑流量区分开来。这很重要，因为迁移期间最不该做的，就是把噪音当成成功。

一个实用技巧：先在有明确转化点的页面上测试，再在没有任何转化的页面上测试。如果 Astrina 都能正确记录，说明你的配置大概率已经稳定到可以信任了。如果不行，就先停下来修正标签，再让团队开始看这些数据。

6. 切换后如何处理 Matomo 历史数据

切换之后，通常有三种选择：把 Matomo 保持为只读、归档导出文件，或者在 Astrina 成为主数据源的同时保留一小段回退期。每种方案都有成本，也都应该有意识地选择。

对于较大的团队，只读权限往往就够了。这样大家还能查旧报表，但不会再去修改，也不会在旧工具里养成新的追踪习惯。这能减少混乱，也能降低有人悄悄把数据补错地方的概率。

如果法务、财务或管理层希望保留历史趋势记录，归档导出会更合适。把导出的文件存放在受控位置，并统一文件命名规则和日期。“final_matomo_export”不算命名规则。

如果团队对切换感到不安，或者网站有多个负责人需要时间适应，短期回退期就说得通。但时间要短。Matomo 作为安抚工具存在得越久，大家学习 Astrina 的速度就越慢。

不要让两个系统长期同时用于日常工作。那会造成数字不一致、反复讨论，以及“到底哪个仪表板才对？”这类浪费时间的问题。选一个主数据源，并且明确说明。

7. 把新的分析工作流交接给团队

交接环节往往决定迁移成败。更新内部文档，写上新的报表链接、新的事件名称，以及当追踪出问题时由谁负责修复。把日期也写进去。人们忘记日期的速度，往往比忘记观点更快。

用清楚直接的语言重写团队习惯。如果每周报表以前从 Matomo 开始，现在就把大家引到 Astrina。如果产品经理以前每周五查看一个 Matomo 细分，现在就给他们展示 Astrina 里对应同一问题的报表。尽量沿用同样的会议节奏，新工具更容易嵌入旧习惯。

给团队做一次简短培训，只讲他们实际会看到的那几个关键数字。一次小范围演示，比毫无例子的长时间屏幕共享更有效。告诉他们去哪看页面浏览量、怎么查看事件，以及在哪里检查主要转化点。对大多数岗位来说，这些就够了。

如果你的流程里很看重权限控制，现在就分配角色，而不是以后再说。一个人负责追踪配置，另一个人负责看报表，第三个人在上线前审核修改。这样可以避免误改，也能让责任更清晰。

切换这件事要说得明确。直接告诉大家：Matomo 已归档，Astrina 正在使用，关于旧配置的问题先看迁移说明。清晰的归属能省时间。含糊不清，代价往往比任何仪表板都高。

如果你还在配置阶段，就回到 agent 安装页面，确认当前实现与你们文档里写的一致：*。然后锁定笔记，关闭旧标签页，并在下一个报表周期开始使用新的工作流。