Migrar do Google Analytics para o Matomo
Como migrar do Google Analytics para o Matomo
Migrar do Google Analytics para o Matomo não é uma troca apenas estética. É uma mudança de reporting com consequências, e a versão mais segura de uma migração do Google Analytics para Matomo começa com um escopo reduzido: um site, uma propriedade ou um conjunto de campanhas. Se você tentar mover tudo no primeiro dia, vai passar a primeira semana desembaraçando tags antigas e discutindo números.
Para começar com o pé direito, defina o que significa “concluído” antes de mexer no código de tracking. Um objetivo prático parece simples: os principais relatórios existem no Matomo, a equipe consegue lê-los sem ajuda e o GA continua disponível apenas para comparação durante a transição. Isso basta. Se você não consegue descrever a linha de chegada em uma frase, a migração está ampla demais.
Há uma frase que vale dizer sem rodeios: como migrar do Google Analytics para o Matomo depende menos da ferramenta e mais do escopo de relatórios que você protege. Um pequeno e-commerce pode se preocupar com checkout, visualizações de produto e uso de cupom; um site de conteúdo pode se preocupar com leituras de artigos, profundidade de rolagem e inscrições na newsletter. Site diferente, transição diferente. Mesma disciplina.
1. Defina o que “concluído” significa para esta migração
Comece com um escopo por escrito e mantenha-o enxuto. Nomeie o site, a propriedade e o grupo de campanhas que vão ser migrados primeiro. Se a empresa pedir “a conta inteira”, recuse e escolha apenas um conjunto de relatórios. Uma migração com um alvo é administrável; uma migração com cinco alvos é um projeto que nunca se estabiliza.
Escreva critérios de sucesso que possam ser verificados em 10 minutos, não debatidos por 10 dias. Por exemplo: “O Matomo mostra sessões, conversões e principais landing pages do Site A” e “O GA fica ativo por apenas 2 semanas, só para comparação”. Essas duas linhas dão limites claros para a equipe. Sem elas, alguém vai pedir mais um dashboard no pior momento possível.
Defina também uma linha de falha. Se a configuração do Matomo deixar passar a principal conversão, ou se a empresa não conseguir verificar os números durante o período de sobreposição, a transição ainda não está pronta. Parece duro. Economiza tempo.
2. Inventarie os dados do Google Analytics que você não pode perder
Antes de mover qualquer coisa, faça uma lista dos itens do GA que importam. Inclua os dashboards exatos que as pessoas abrem toda manhã, dimensões personalizadas com valor de negócio, eventos ligados a receita, conversões, públicos, filtros e configurações relacionadas à atribuição. Uma migração sem esse inventário é chute com um nome mais bonito.
Use nomes, não descrições. “Dashboard de pesquisa paga” é melhor do que “coisas de marketing”. “Evento de envio de formulário de leads” é melhor do que “ações de contato”. Se um relatório tem um dono real, escreva o nome dele ao lado. Esse pequeno passo ajuda quando alguém disser depois: “Eu achava que o time de vendas usava esse filtro”.
Alguns itens do GA não merecem uma reconstrução um-para-um. Isso é normal. Um segmento de público pouco usado do ano passado pode não valer a pena reproduzir no Matomo se nunca influenciou uma decisão. O ponto não é preservar cada objeto; o ponto é preservar os 20% que as pessoas realmente usam.
Se você precisar de uma referência simples enquanto reúne a lista, mantenha um checklist separado para páginas incomuns e relatórios de nicho. O mesmo hábito ajuda em outros contextos também; por exemplo, uma equipe que precisa verificar uma página do site pode usar como verificar se um site como um padrão rápido de referência. O nome muda, mas a regra continua a mesma: saber o que precisa ser encontrado antes de procurar por isso.
3. Mapeie os conceitos do GA para equivalentes no Matomo
Crie uma planilha de tradução com 2 colunas: termo do GA e termo ou método do Matomo. Anote o que corresponde diretamente e o que não corresponde. Visualizações de página, eventos, metas, segmentos, dimensões personalizadas e tracking de campanhas devem estar todos na planilha. É aqui que a migração deixa de ser teórica e vira algo concreto.
Alguns mapeamentos são fáceis. Outros, não. Públicos do GA podem precisar virar segmentos do Matomo ou uma regra de relatório diferente. Uma configuração de atribuição do GA pode não ter o mesmo comportamento no Matomo, então talvez seja necessário mudar a pergunta em vez de forçar a resposta antiga para dentro da nova ferramenta. Escreva isso, porque as pessoas esquecem rápido quando os dashboards aparecem na tela.
Mantenha uma coluna para “mesma ideia, lógica diferente”. Essa coluna importa. Se o GA calculava uma métrica de um jeito e o Matomo de outro, a equipe precisa saber disso antes de ver os números. Caso contrário, vão achar que a migração quebrou quando o problema real é uma mudança de definição.
Para equipes que já mantêm páginas de referência estruturadas, esse tipo de mapeamento funciona do mesmo jeito que uma consulta cuidadosa em um diretório como o dicionário dos sonhos com p: um termo, um lugar, um significado. A ferramenta pode ser diferente, mas o hábito é familiar. Primeiro combine, depois discuta.
4. Planeje a transição para uma migração de baixo risco
Escolha a data da migração de forma intencional. Evite lançamentos de produto, picos de campanha e prazos de reporting. Uma transição numa segunda-feira de manhã costuma gerar ruído; um horário tranquilo no meio da semana normalmente é mais fácil de validar. Uma transição de baixo risco é melhor do que uma dramática.
Decida se o período de sobreposição vai durar 3 dias, 1 semana ou mais. A sobreposição deve ser longa o bastante para comparar resultados, mas curta o suficiente para que ninguém mantenha dois sistemas vivos por hábito. Durante esse período, especifique quem verifica os relatórios, quem aprova e quem pode pausar a mudança se os números parecerem errados.
Atribua um único responsável pela validação. Não três. Uma pessoa pode reunir feedback de analytics, produto e marketing, mas uma pessoa deve tomar a decisão. Se todo mundo for dono da transição, ninguém é. É assim que pequenos problemas de tracking ficam por meses.
Pense nas mudanças de acesso só depois que a sobreposição estiver estável. Se você reduzir o acesso ao GA cedo demais, as pessoas entram em pânico e começam a montar planilhas paralelas. Se demorar demais, elas param de usar o Matomo. O timing aqui importa mais do que a formalidade.
5. Reconstrua primeiro os relatórios críticos no Matomo
Não tente copiar toda a visão do GA. Reconstrua primeiro os relatórios do dia a dia: tráfego por origem, páginas principais, conversões principais e os poucos segmentos que a equipe consulta toda semana. Se um relatório não afeta uma decisão, deixe para depois. É aqui que muitas migrações desaceleram sem necessidade.
Use configurações nativas do Matomo sempre que possível. Uma imitação fiel do GA pode parecer mais confortável, mas pode gerar manutenção extra no futuro. Melhor reconstruir a pergunta de negócio, e não a captura de tela antiga. Se o GA tinha quatro abas e o Matomo consegue responder à mesma pergunta em dois painéis, fique com os dois painéis.
Traga primeiro os relatórios mais visíveis, antes que alguém peça por eles. Se vendas quer qualidade dos leads toda manhã e marketing quer tráfego de campanhas toda tarde, esses são os dois primeiros a reconstruir. O restante pode esperar. As pessoas perdoam mais facilmente casos de borda ausentes do que o relatório de segunda-feira ausente.
Algumas equipes gostam de consultar outros fluxos de referência do site enquanto revisam listas de relatórios, especialmente se o conteúdo estiver distribuído em várias páginas. Um exemplo prático é como verificar se um site, que mostra o valor de confirmar exatamente a página que o usuário espera encontrar. Com reporting é parecido: o relatório precisa ser aquele que as pessoas realmente usam.
6. Valide eventos e metas com ações reais do usuário
Teste ações reais, não apenas carregamento de páginas. Envie um formulário, conclua uma compra, baixe um arquivo e clique em um link externo. Depois verifique se o Matomo registrou cada ação da forma que a empresa precisa. Teste rápido é útil, mas teste metódico economiza retrabalho.
Mantenha os casos de teste curtos e específicos. “Envio do formulário de contato na página de preços” é melhor do que “testar o funil”. “Checkout concluído com código de cupom” é melhor do que “teste de compra”. Uma ação clara gera um bug claro. Teste vago cria confusão educada.
Compare os resultados com o GA durante o período de sobreposição, mas não espere identidade perfeita. Ferramentas diferentes podem contar de forma ligeiramente diferente por causa de consentimento, timing ou detalhes de configuração. A pergunta importante é se o Matomo captura a mesma ação de negócio de forma confiável. Se não capturar, corrija a tag ou a regra da meta antes da migração.
Esse também é um bom momento para registrar quaisquer casos de exceção. Por exemplo, um download que abre em uma nova aba pode precisar de um gatilho diferente de um clique em link padrão. Uma única regra raramente captura todo comportamento na primeira tentativa. Isso é normal, e é por isso que a lista de testes deve ser curta o suficiente para repetir numa tarde.
7. Treine a equipe no fluxo de reporting do Matomo
Faça uma apresentação de 30 minutos para analistas e stakeholders e, depois, entregue um caminho por escrito para os 3 ou 4 relatórios que eles mais usam. Mostre onde ficam os segmentos, como as anotações são tratadas e quais hábitos do GA já não se aplicam. As pessoas não precisam de uma aula sobre todos os menus. Precisam saber onde está a resposta de segunda-feira.
Use exemplos reais do site migrado. Abra o relatório de leads, o relatório de produtos e o relatório de landing pages. Navegue pelos filtros. Se você puder mostrar um relatório de campanha com o nome exato que o time de marketing usava no GA, a curva de aprendizado cai imediatamente. Capturas de tela ajudam, mas cliques ao vivo ajudam mais.
Explique as diferenças com clareza. Se um público estilo GA agora é um segmento do Matomo, diga isso. Se um relatório salvo mudou de lugar, diga também. Se um stakeholder pedir uma métrica que não existe mais na mesma forma, responda com o novo fluxo de trabalho, não com uma história sobre a ferramenta antiga. As pessoas se adaptam mais rápido quando a resposta é direta.
Algumas equipes mantêm uma pequena referência para consultas recorrentes, e isso pode incluir páginas de conteúdo também. Se o time trabalha com páginas de conhecimento, um link como dicionário dos sonhos com k lembra que categorias organizadas reduzem o tempo de busca. O treinamento de reporting funciona da mesma forma: um lugar para uma tarefa.
8. Elimine as dependências do GA depois da entrega
Depois que o escopo de reporting acordado estiver estável no Matomo, liste todas as dependências restantes do GA. Isso inclui dashboards, tags, alertas, documentos, SOPs, favoritos do navegador e scripts que ainda apontam para o GA. Não deixe nada sem revisão. Links antigos costumam sobreviver muito depois de a migração ser “concluída”.
Remova ou reescreva os itens um por um. Uma observação no dashboard que diz “verificar no GA” deve virar “verificar no Matomo”. Um runbook que manda comparar com o GA todas as manhãs deve ser atualizado para o novo processo, ou arquivado se não tiver mais utilidade. Pequenas tarefas de limpeza importam aqui porque evitam que velhos hábitos voltem.
Mantenha um último ponto de comparação e, depois, encerre a janela do GA para o escopo migrado. Se a equipe ainda precisar do GA para referência histórica, limite o uso a somente leitura e defina uma data de revisão. Se não precisar, reduza o acesso e remova as verificações rotineiras. Quanto mais tempo o GA continuar fazendo parte do fluxo diário, mais difícil fica saber qual sistema é a fonte da verdade.
Nesta fase, um hábito simples de manutenção ajuda: revise os relatórios ativos todo mês, não a cada trimestre. Uma revisão de 15 minutos identifica dashboards desatualizados antes que eles confundam o próximo responsável por campanha. Uma pequena limpeza agora sai mais barato do que uma segunda migração depois.
