How to move from Google Analytics to Matomo

How to move from Google Analytics to Matomo

Moving from Google Analytics to Matomo is not a cosmetic switch. It is a reporting change with consequences, and the safest version starts with a narrow scope: one site, one property, or one campaign set. If you try to move everything on day one, you will spend the first week untangling old tags and arguing about numbers.

For a clean start, define what “done” means before you touch the tracking code. A practical target sounds simple: the key reports exist in Matomo, the team can read them without help, and GA remains available only for comparison during the cutover. That is enough. If you cannot describe the finish line in one sentence, the migration is too loose.

There is one phrase worth saying plainly: how to move from Google Analytics to Matomo depends less on the tool and more on the report scope you protect. A small e-commerce site may care about checkout, product views, and coupon use; a content site may care about article reads, scroll depth, and newsletter signups. Different site, different cutover. Same discipline.

1. Decide what “done” means for this migration

Start with a written scope, and keep it narrow. Name the site, the property, and the campaign group that will move first. If the business asks for “the whole account,” push back and choose one reporting set. A migration with one target is manageable; a migration with five targets is a project that never settles.

Write success criteria that can be checked in 10 minutes, not debated for 10 days. For example: “Matomo shows sessions, conversions, and top landing pages for Site A,” and “GA stays live for 2 weeks only for comparison.” Those two lines give the team a boundary. Without them, someone will ask for one more dashboard at the worst possible moment.

Set a failure line too. If the Matomo setup misses the main conversion, or if the business cannot verify the numbers during the overlap period, the cutover is not ready. That sounds harsh. It saves time.

2. Inventory the Google Analytics data you must not lose

Before you move anything, make a list of the GA items that matter. Include the exact dashboards people open every morning, custom dimensions that carry business meaning, events tied to revenue, conversions, audiences, filters, and attribution-related settings. A migration without this inventory is guesswork with a nicer name.

Use names, not descriptions. “Paid search dashboard” is better than “marketing stuff.” “Lead form submit event” is better than “contact actions.” If a report has a real owner, write the owner’s name beside it. That small step helps when someone later says, “I thought the sales team used that filter.”

Some GA items will not deserve a one-to-one rebuild. That is normal. A rarely used audience segment from last year may not be worth reproducing in Matomo if it never drove a decision. The point is not to preserve every object; the point is to preserve the 20% that people actually use.

If you need a simple reference while you gather the list, keep a separate checklist for odd pages and niche reports. The same habit helps elsewhere too; for example, a team that needs to verify a site page can use how to check if a website as a quick reference pattern. The name changes, but the rule stays the same: know what must be found before you search for it.

3. Map GA concepts to Matomo equivalents

Create a translation sheet with 2 columns: GA term and Matomo term or method. Put down what matches directly and what does not. Page views, events, goals, segments, custom dimensions, and campaign tracking should all be on the sheet. This is where the migration becomes concrete instead of theoretical.

Some mappings are easy. Others are not. GA audiences may need to become Matomo segments or a different reporting rule. A GA attribution setting may not have the same behavior in Matomo, so you may need to change the question rather than force the old answer into the new tool. Write that down, because people forget fast once dashboards are on screen.

Keep one column for “same idea, different logic.” That column matters. If GA calculated a metric one way and Matomo calculates it another way, the team needs to know before they see the numbers. Otherwise, they will assume the migration is broken when the real issue is a definition change.

For teams that already keep structured reference pages, this kind of mapping works the same way as a careful lookup in a directory such as the dream dictionary starting with p: one term, one place, one meaning. The tool may be different, but the habit is familiar. Match first, debate later.

4. Plan the cutover for a low-risk transition

Pick the migration date deliberately. Avoid product launches, campaign peaks, and reporting deadlines. A Monday morning cutover often creates noise; a quiet midweek slot is usually easier to validate. One low-risk transition is better than a dramatic one.

Decide whether the overlap period will last 3 days, 1 week, or longer. The overlap should be long enough to compare results, but short enough that no one keeps two systems alive out of habit. During that period, specify who checks the reports, who signs off, and who can pause the move if the numbers look wrong.

Assign one owner for validation. Not three. One person can collect feedback from analytics, product, and marketing, but one person should own the call. If everyone owns the cutover, no one does. That is when small tracking issues linger for months.

Think about access changes only after the overlap is stable. If you reduce GA access too early, people will panic and start building side spreadsheets. If you wait too long, they will stop using Matomo. Timing matters here more than ceremony.

5. Rebuild your critical reports in Matomo first

Do not try to copy every GA view. Rebuild the daily reports first: traffic by source, top pages, main conversions, and the few segments the team checks every week. If a report does not affect a decision, leave it for later. This is where many migrations slow down for no good reason.

Use Matomo-native settings where possible. A close imitation of GA may look comforting, but it can create extra maintenance later. A better move is to rebuild the business question, not the old screenshot. If GA had four tabs and Matomo can answer the same question in two panels, take the two panels.

Bring the most visible reports in before anyone asks for them. If sales asks for lead quality every morning and marketing asks for campaign traffic every afternoon, those are the first two to rebuild. The rest can wait. People forgive missing edge cases faster than missing their Monday report.

Some teams like to check other site-reference workflows while they work through report lists, especially if their content is spread across several pages. A practical example is how to check if a website, which shows the value of verifying the exact page a user expects to find. Reporting is similar: the report must be the one people actually use.

6. Validate event and goal tracking against real user actions

Test real actions, not just page loads. Submit a form, finish a purchase, download a file, and click an outbound link. Then check whether Matomo recorded each action the way the business needs it to. Fast testing is useful, but methodical testing saves rework.

Keep the test cases short and specific. “Contact form submit from the pricing page” is better than “test the funnel.” “Checkout completed with coupon code” is better than “purchase test.” A clear action makes a clear bug. Vague testing creates polite confusion.

Compare results against GA during the overlap period, but do not expect perfect identity. Different tools can count slightly differently because of consent handling, timing, or setup details. The important question is whether Matomo captures the same business action reliably. If it does not, fix the tag or goal rule before you cut over.

This is also a good moment to write down any edge cases. For example, a download that opens in a new tab may need a different trigger from a standard link click. A single rule rarely catches every behavior on the first pass. That is normal, and it is why the test list should be short enough to repeat in one afternoon.

7. Train the team on Matomo’s reporting workflow

Give analysts and stakeholders a 30-minute walkthrough, then give them a written path for the 3 or 4 reports they use most. Show where segments live, how annotations are handled, and which GA habits no longer apply. People do not need a lecture on every menu. They need to know where Monday’s answer is.

Use real examples from the migrated site. Open the lead report, the product report, and the landing page report. Click through the filters. If you can show a campaign report with the exact name the marketing team used in GA, the learning curve drops immediately. Screenshots help, but live clicks help more.

Explain the differences plainly. If a GA-style audience is now a Matomo segment, say so. If a saved report changed location, say that too. If a stakeholder asks for a metric that no longer exists in the same form, answer with the new workflow, not a story about the old tool. People adapt faster when the answer is direct.

Some teams keep a small reference for recurring lookups, and that can include content pages too. If the team works with knowledge pages, a link like dream dictionary starting with k is a reminder that organized categories reduce search time. Reporting training works the same way: one place for one task.

8. Retire GA dependencies after the handoff

After the agreed reporting scope is stable in Matomo, list every lingering GA dependency. That includes dashboards, tags, alerts, docs, SOPs, browser bookmarks, and scripts that still point to GA. Leave none of them unexamined. Old links have a habit of surviving long after the migration is “done.”

Remove or rewrite the items one at a time. A dashboard note that says “check GA” should become “check Matomo.” A runbook that tells someone to compare against GA every morning should be updated to match the new process, or archived if it no longer serves a purpose. Small cleanup tasks matter here because they prevent old habits from coming back.

Keep one final comparison checkpoint, then close the GA window for the migrated scope. If the team still needs GA for historical reference, limit it to read-only use and set a review date. If not, reduce access and remove the routine checks. The longer GA remains part of the everyday workflow, the harder it is to tell which system is the source of truth.

At this stage, a simple maintenance habit helps: review the active reports every month, not every quarter. A 15-minute review catches stale dashboards before they confuse the next campaign owner. Small cleanup now is cheaper than a second migration later.