Após Schrems II, várias Autoridades Europeias de Proteção de Dados concluíram que Google Analytics criou problemas ilegais de transferência de dados entre a UE e os EUA sob o antigo mecanismo de transferência.
O EU-U.S. Data Privacy Framework desde então mudou a base legal para provedores americanos certificados, mas muitos proprietários de sites que priorizam a privacidade ainda evitam o GA4 porque ele permanece vinculado ao ecossistema de publicidade do Google, ao fardo do consentimento e às questões de processamento transfronteiriço.
Para sites que querem uma configuração de privacidade mais limpa, a resposta prática é mover a análise do GA4 para algo auto-hospedado, em um datacenter na UE, com rastreamento de primeira parte e menos questões de processamento transfronteiriço.
Quatro opções aparecem constantemente em comparações: Umami, Matomo, Fathom Lite e Ackee. Duas estão ativas e valem seu tempo. Uma tem recursos congelados e poucas atualizações. Uma está ativa mas é de nicho. Esta publicação compara as quatro, dá uma regra de decisão por arquétipo e corresponde cada ferramenta ao plano VPS que a executa bem.
Resumo rápido
A versão curta não é complicada. A maioria dos sites deveria começar com Umami, migrar para Matomo apenas para necessidades de relatórios mais pesadas, ignorar Fathom Lite e tratar Ackee como uma escolha de preferência de nicho.
- Usar Umami para blogs pessoais, SaaS independentes e qualquer coisa onde o painel de análise precise ser legível por não engenheiros. Funciona confortavelmente em um VPS com 1 GB RAM. Licenciado com MIT. Sem cookies por padrão.
- Usar Matomo quando você realmente precisa de funis, rastreamento de e-commerce, mapas de calor ou gravação de sessão em uma única ferramenta. A superfície completa de recursos custa mais em RAM e atenção operacional. O mínimo realista é 2 GB RAM para sites pequenos; 4 GB para sites de tráfego moderado com recursos padrão habilitados.
- Não use Fathom Lite. A imagem Docker de código aberto não foi atualizada há cinco anos. Os mantenedores migraram completamente para o Fathom Analytics comercial. Executá-lo como um serviço exposto à internet em 2026 é um risco de segurança e compatibilidade.
- Ackee está ativo, mas com velocidade menor que o Umami. Escolha-o apenas se a estética do painel for especificamente importante para você. Caso contrário, opte pelo Umami como padrão.
Os quatro concorrentes, brevemente
A lista curta é menor do que parece. Umami e Matomo são as escolhas sérias para a maioria das configurações de análise auto-hospedadas. Fathom Lite ainda aparece em listas mais antigas, mas a versão open source ficou muito para trás. Ackee ainda funciona, mas agora está mais próximo de uma escolha de preferência do que de uma recomendação padrão.
Umami
Umami é uma aplicação Node.js suportada pelo PostgreSQL. Licenciada MIT. Desenvolvimento ativo com commits semanais e releases com tags regulares ao longo de 2025 e entrando em 2026. O release estável atual é v3.1.0.
O processo Node está ocioso em cerca de 200 MB de RAM. O Postgres adiciona mais 150-250 MB, dependendo da configuração. A pilha completa roda confortavelmente em 1 GB total. O script de rastreamento tem aproximadamente 2 KB. Sem cookies por padrão; sem identificadores de terceiros; nenhum banner de consentimento necessário segundo a maioria das interpretações dos reguladores da UE.
- Principal ponto forte: o painel mais limpo de todas as ferramentas deste conjunto, menor atrito na configuração, menor pegada operacional.
- Principal ponto fraco: os recursos de funil e mapa de calor são menos robustos que os do Matomo, e a interface de gerenciamento de múltiplos sites funciona, mas é menos madura em escala de agência.
Matomo
Matomo é uma aplicação PHP de 15 anos apoiada por MySQL ou MariaDB. O projeto era anteriormente chamado Piwik. GPL v3 para o núcleo; alguns plugins avançados (heatmaps, gravação de sessão, testes A/B) são comerciais. A versão estável atual é v5.10.0.
O mínimo realista de RAM é de 1,5-2 GB no total: os workers do PHP-FPM consomem 50-80 MB cada, o MariaDB quer 512 MB para funcionar confortavelmente, o nginx é pequeno mas presente, e o cron job de arquivamento causa picos periódicos tanto de CPU quanto de memória.
- Principal ponto forte: maior superfície de funcionalidades de qualquer ferramenta de analytics open-source. Funis, multi-atribuição, e-commerce, metas, dimensões personalizadas, segmentos, atribuição de marketing, relatórios no estilo GA4.
- Principal ponto fraco: o painel é denso (alguns usuários o acham parecido com o Excel) e a atenção operacional necessária é real. Você precisará saber o que é um cron job de arquivamento.

Fathom Lite
Fathom Lite é a implementação Go de código aberto original de Jack Ellis e Paul Jarvis. Licenciada MIT. O repositório ainda existe no GitHub, e a versão mais recente do GitHub é v1.3.1. A imagem Docker ainda pode ser baixada.
A imagem Docker no Docker Hub não foi atualizada há mais de cinco anos. A branch master do repositório teve apenas commits esporádicos e sem lançamentos nesse período. O README diz que a versão Lite não receberá mais novos recursos, embora os mantenedores ainda a descrevam como mantida para bugs a longo prazo. O produto em desenvolvimento ativo é o Fathom Analytics comercial.
Executar em 2026 um aplicativo de análise com recursos congelados e uma imagem Docker pública desatualizada é um risco. O comportamento dos scripts de rastreamento no navegador evoluiu. As atualizações de runtime e dependências que projetos ativos lançam regularmente não aparecem no caminho de lançamento público do Lite.
Se você encontrar o Fathom Lite recomendado em uma lista de 2026, verifique a data da imagem do Docker e o histórico de versões antes de tratá-lo como uma escolha de produção.
O SaaS comercial Fathom Analytics em usefathom.com é um produto diferente. Tudo bem se você aceitar que é SaaS e não auto-hospedado. Não é sobre isso que este post trata.
- Principal ponto forte: binário minúsculo, rastreador pequeno, ideia de produto original e simples.
- Principal ponto fraco: base de código open source com funcionalidades congeladas, imagem Docker desatualizada, caminho de versões pouco claro e nenhuma razão forte para implantá-lo como um serviço de análise exposto à internet em 2026.
Ackee
Ackee é uma ferramenta de análise Node.js + MongoDB. Licença MIT. A versão atual é v3.6.0. O mantenedor lança correções de bugs e atualizações de dependências. O trabalho em funcionalidades principais diminuiu. O painel é minimalista, o rastreador é pequeno e o consumo de recursos é comparável ao do Umami.
Ackee funciona. A razão pela qual está na coluna de nicho é que o Umami está pelo menos um nível de velocidade acima dele em cada eixo relevante: ritmo de desenvolvimento, ecossistema, documentação de terceiros, integrações disponíveis.
Se você já tem uma boa razão para preferir o Ackee (testou ambos e gostou mais do painel), use-o. Caso contrário, escolha o Umami e siga em frente.
- Principal ponto forte: painel limpo, tracker pequeno, baixo consumo de recursos, ainda mantido.
- Principal ponto fraco: ritmo de desenvolvimento mais lento que o Umami, ecossistema menor, menos integrações e menos documentação de terceiros para pessoas que precisam de ajuda após a instalação.
Estrutura de decisão: escolha por arquétipo
O arquétipo importa mais do que a grade de funcionalidades. Um blog pessoal não precisa da mesma stack de analytics que um produto SaaS ou uma agência que gerencia contas de clientes. Comece com o proprietário do painel, a profundidade dos relatórios e a quantidade de trabalho no servidor que você está disposto a assumir. A escolha da ferramenta se torna muito mais simples depois disso.
Blog pessoal ou proprietário de um único site
Escolha o Umami. A configuração é um único arquivo Docker Compose. O tracker é um script de uma linha no seu <head>. O painel é legível no celular. RAM e armazenamento são preocupações triviais nesta escala.
Não é necessária uma segunda ferramenta. Se você está saindo do GA4 por razões principiológicas ou para remover o banner de cookies, o Umami encerra o caso.
Fundador de SaaS independente ou pequena equipe de produto
Opte pelo Umami como padrão. Adicione o Matomo apenas se tiver identificado especificamente um recurso ausente.
A razão mais comum para adicionar o Matomo aqui é o relatório de funil nos fluxos de inscrição e upgrade que o Umami ainda não faz tão bem. A questão de decisão é se alguém na equipe quer ativamente operar a maior superfície do Matomo.
Se a resposta for não, o Umami mais algumas consultas ao banco de dados do seu produto fornecerá 90% dos insights de funil a 10% do custo operacional. Se seu produto for intenso em eventos e você quiser uma UI de funil nativa, instale o Matomo. O custo operacional é uma stack maior: Matomo, um banco de dados, uma camada de servidor web, Redis opcional, mais RAM e um job de arquivamento para gerenciar.
Agência Gerenciando 10+ Propriedades de Clientes
Escolha o Matomo. O gerenciamento multi-site é maduro. Permissões por usuário e login por cliente são recursos de primeira classe. Os plugins pagos de mapa de calor e gravação de sessão são diferenciais que as agências realmente cobram.
A interface multi-site do Umami funciona, mas parece mais enxuta em escala de agência: filtragem entre muitos sites, atribuição de acesso por cliente, exportação de relatórios personalizados. A interface do Matomo é densa, mas essa densidade oferece os recursos que o trabalho exige.
Se a agência tiver um portfólio de sites principalmente com baixo tráfego e o trabalho principal for relatórios de tráfego mensais em vez de otimização de taxa de conversão, o Umami ainda é uma escolha defensável e economizará custos de infraestrutura. A decisão é sobre o teto de recursos, não sobre a ferramenta errada.
Comparação recurso a recurso
| Capacidade | Umami | Matomo | Fathom Lite | Ackee |
|---|---|---|---|---|
| Licença | MIT | GPL v3 (plugins pagos comerciais) | MIT | MIT |
| Pilha | Node + PostgreSQL | PHP + MySQL ou MariaDB | Go + MySQL ou SQLite | Node + MongoDB |
| Desenvolvimento ativo (2026) | Sim, commits semanais | Sim, equipe em tempo integral | Não, ~5 anos desatualizado | Sim, baixa atividade |
| Sem cookies por padrão | Sim | Configurável (sinalizador necessário) | Sim | Sim |
| Gerenciamento de múltiplos sites | Sim, básico | Sim, maduro | Sim, básico | Sim, básico |
| Funis e metas | Limitado | Completo | Nenhum | Nenhum |
| Rastreamento de e-commerce | Nenhum | Completo | Nenhum | Nenhum |
| Mapas de calor e gravação de sessão | Replay de sessão; sem heatmaps nativas | Sim (plugin pago) | Nenhum | Nenhum |
| Tamanho do script de rastreamento | ~2 KB | ~22 KB | ~1 KB | ~2 KB |
| Piso de RAM realista | 1 GB total | 2 GB total | n/a (não implantar) | 1 GB total |
| Complexidade operacional | Baixa | Média | n/a | Baixa |
| Recomendação | Padrão para a maioria | Quando o teto de funcionalidades importa | Evitar | Nicho |
Dimensionamento de VPS em números claros
A ferramenta certa depende em parte do quanto você está disposto a pagar pelo servidor que a executa.
| Configuração | RAM realista | CPU | O armazenamento | Boa base para VPS |
|---|---|---|---|---|
| Umami + Postgres, tráfego baixo | 512 MB-1 GB | 1 vCPU | 20-25 GB NVMe | VPS pequeno |
| Umami + Postgres, margem de crescimento | 1-2 GB | 1-2 vCPU | 40-60 GB NVMe | VPS pequeno a médio |
| Ackee + MongoDB | 1 GB | 1 vCPU | 20-25 GB NVMe | VPS pequeno |
| Matomo + MariaDB, site pequeno | 1.5-2 GB | 1-2 vCPU | 40-60 GB NVMe | VPS Intermediário |
| Matomo + MariaDB, tráfego moderado, recursos padrão | 2-4 GB | 2 vCPU | 80-120 GB NVMe | VPS médio a grande |
| Matomo + MariaDB + mapa de calor ou gravação de sessão | 4 GB+ | 2-4 vCPU | 120 GB+ NVMe | VPS maior |
Por que esses mínimos importam:
O pequeno tamanho do Umami é intencional. O Umami armazena eventos de análise leves no PostgreSQL em vez de logs completos de solicitações do servidor web, portanto o crescimento do banco de dados permanece modesto para sites pequenos e médios.
O processo Node fica abaixo de 250 MB mesmo quando vários milhares de visitantes acessam o site diariamente. O crescimento do Postgres é modesto.
Um VPS de 1 GB com 25 GB de NVMe armazena muitos anos de análises para um site típico de solopreneur. Rodo Umami em um VPS de 1 GB em Frankfurt para um projeto pequeno; a latência de Lagos é de cerca de 110 ms, o painel responde em menos de 400 ms e o servidor tem funcionado sem problemas por meses.
A pegada do Matomo é maior porque a arquitetura é mais antiga e mais geral. Cada worker PHP-FPM consome 50-80 MB. O MariaDB tem desempenho ruim com menos de 512 MB alocados.
O cron de arquivamento horário recomendado pelo Matomo pode causar picos de CPU e memória, portanto o VPS precisa de margem além do uso normal de PHP e banco de dados. Um VPS de 1 GB tecnicamente executa o Matomo para instalações muito pequenas, mas o painel fica lento e o risco de OOM durante o arquivamento é real. O mínimo de 2 GB não é uma restrição arbitrária. É o ponto onde a ferramenta para de lutar contra você.
O crescimento do armazenamento raramente é o gargalo. Um disco NVMe de 60 GB armazena muitos anos de dados do Matomo mesmo com a retenção de log bruto padrão ativada. Se você ativar a gravação de sessão, planeje cerca de dez vezes mais espaço em disco por mês e revise o tamanho do plano anualmente.
Pro Tip
If you are running Umami today on a 1 GB VPS and your traffic is growing, the upgrade path is straightforward. Snapshot the VPS, resize to 2 GB, restart. The extra RAM gives Postgres and the Node process more headroom.
Datacenters da UE e o ângulo do RGPD

O problema do Schrems-II e da transferência de GA4 mencionado na introdução é o contexto legal aqui. O auto-hospedagem não torna os analytics automaticamente conformes, mas remove o padrão padrão do GA4: dados do visitante saindo do seu site, entrando na pilha de analytics do Google e levantando questões sobre processamento transfronteiriço.
Hospedar sua analytics dentro da UE mantém a pilha mais simples no nível de jurisdição. Não é um código de trapaça de conformidade. Os dados são coletados pelo seu tracker, enviados diretamente ao seu servidor, processados e armazenados na região que você escolheu.
Seu provedor de VPS ainda pode ser um processador, portanto os termos do processador, controles de segurança, regras de retenção e avisos de privacidade ainda importam. O ponto é mais estreito: não há um provedor de SaaS de analytics no meio, e nenhuma transferência transatlântica de analytics padrão no estilo GA4.
A escolha do datacenter deve seguir seus visitantes e sua postura de conformidade. Frankfurt é a escolha padrão para públicos alemão, austríaco e da UE em geral. Amsterdam é uma opção natural para o tráfego do Benelux.
London funciona para casos de UK GDPR, mas está fora da UE, portanto não é a mesma resposta para requisitos de residência de dados exclusivamente na UE. Zurich funciona para públicos suíços e necessidades de privacidade específicas da Suíça, mas também está fora da UE.
Pro Tip
Putting a US-headquartered CDN or proxy in front of your analytics endpoint can reintroduce transfer analysis and processor-review work. If the whole point is EU-only analytics handling, terminate TLS directly on the VPS or document the CDN setup carefully.
Visão geral dos mecanismos de configuração
Esta é a estrutura de implantação, não um tutorial. Os guias completos passo a passo são publicações separadas.
Umami: Um arquivo Docker Compose. Dois containers: Umami (Node) e PostgreSQL. Uma variável de ambiente: DATABASE_URL. Porta padrão 3000. Proxy reverso na frente para TLS (Caddy é a opção de menor fricção; nginx-proxy-manager e Traefik também funcionam). Adicione o script de rastreamento (uma linha) ao <head> de cada página que você deseja rastrear. As atualizações são docker compose pull && docker compose up -d.
Matomo: Docker Compose com três a quatro containers: Matomo (matomo:fpm-alpine), nginx (ou Apache) na frente do PHP-FPM, MariaDB e opcionalmente Redis para cache. O assistente de configuração baseado em navegador da primeira vez gerencia a conexão do banco de dados, o usuário administrador e a configuração do primeiro site. O script de rastreamento é um trecho JS gerado pelo Matomo colado no <head>. Obrigatório: um job cron para arquivamento. A opção padrão de acionar o arquivamento via URL (?force_archiving=1) funciona para sites pequenos, mas produz dashboards visivelmente mais lentos. As atualizações envolvem docker compose pull mais uma invocação de console core:update.
Ambos: TLS via reverse proxy é o padrão. Ambos os projetos publicam guias de atualização oficiais. Ambos têm receitas de backup funcionais (pg_dump para Umami, mariadb-dump para Matomo).
É aqui que O marketplace da Cloudzy realmente importa. Pode implementar Umami or Matomo num VPS sem partir de um servidor em branco, escrever o ficheiro Compose você mesmo, ou passar a primeira hora a montar o stack base.
O VPS ainda precisa de ser o servidor certo. A analítica gosta de discos rápidos, RAM previsível e uma região próxima das pessoas que carregam o seu script de rastreamento. A Cloudzy dá-lhe Armazenamento NVMe, DDR5 RAM, até 40 Gbps redes, acesso root completo acesso, dedicado IPv4 e IPv6, 12+ regiões globais, 99.95% disponibilidade, e um Reembolso em 14 dias garantia.
Para o Umami, o benefício é a rapidez: lance, associe o seu domínio, coloque TLS à frente e cole o script de rastreamento.
Para o Matomo, o benefício é evitar o trabalho no servidor em branco antes mesmo de chegar ao arquivamento, retenção, backups e configurações de rastreamento.
Quando o Auto-Alojamento É a Decisão Errada
Você é um fundador solo não técnico, sem experiência em Linux e sem tempo para aprendê-lo. A resposta certa é Plausible Cloud por $9-19 por mês. É compatível com o RGPD, o painel é excelente e você não precisa gerenciar um servidor.
O cálculo do self-hosting só funciona se o seu tempo for mais barato que a taxa do SaaS ou se você genuinamente quiser a prática operacional. Para um fundador solo não técnico, essa conta não funciona.
Você precisa de trilhas de auditoria em tempo real no nível SOC2 ou HIPAA no seu processador de análise. Nem Umami de código aberto nem Matomo de código aberto entregam isso direto da caixa. Você pode construir a postura de auditoria por conta própria, mas o trabalho é real e o processo de certificação é seu próprio projeto. Compre conformidade como serviço para este caso.
Sua stack de marketing requer GA4 ou atribuição do Google Ads que depende dos cohortes e pixels de remarketing do Google. A analytics auto-hospedada não é a categoria de ferramentas certa para otimização de AdWords ou Meta-Ads.
Os dados de conversão precisam fluir de volta ao Google ou Meta para retreinar os algoritmos de lances. A analytics auto-hospedada substitui o caso de uso de analytics descritiva (o que aconteceu no meu site), não o caso de uso de atribuição de anúncios (quais anúncios devo veicular).
Conclusão
A regra de decisão é curta. Opte pelo Umami por padrão para blogs pessoais, SaaS indie e pequenas equipes de produto. Mude para o Matomo quando funis, e-commerce ou mapas de calor forem indispensáveis e você tiver atenção operacional para dedicar.
Pule o Fathom Lite. Escolha o Ackee somente se já o testou e preferiu o painel. Execute o servidor em Frankfurt ou Amsterdam se a jurisdição da UE importar; caso contrário, onde seu tráfego estiver.
O custo de infraestrutura para um deployment de analytics auto-hospedado funcional está entre $7 e $30 por mês para o VPS. O custo de mão de obra é um ficheiro Docker Compose e um reverse proxy. A maior parte da dificuldade está em decidir, não em executar.
Perguntas frequentes
Qual é a Melhor Ferramenta de Analytics Auto-Hospedada em 2026?
Umami é a recomendação padrão para blogs pessoais, SaaS independente e pequenas equipas de produto. É licenciado MIT, ativamente desenvolvido, sem cookies por padrão e corre confortavelmente em 1 GB de RAM. Escolha Matomo para funis, ecommerce ou mapas de calor. Evite Fathom Lite.
O Fathom Lite ainda é mantido?
Não. A imagem Docker open-source não é atualizada há mais de cinco anos, e a atividade no GitHub é esporádica e sem lançamentos. Os responsáveis focam-se agora no Fathom Analytics comercial. A versão Lite não deve ser executada como um serviço exposto à internet em 2026.
O Analytics Auto-Hospedado Pode Substituir o Google Analytics para a Conformidade com o RGPD?
Sim, condicionalmente. Umami ou Matomo auto-hospedado num VPS na UE mantém os dados de analytics na sua região escolhida e remove o padrão de transferência padrão do GA4. Não coloque uma CDN baseada nos EUA como a Cloudflare à frente do endpoint de analytics se a conformidade com o RGPD é a razão.
De quanto VPS preciso para executar o Matomo?
O mínimo realista é 2 GB de RAM para um site Matomo pequeno. Para tráfego moderado com funcionalidades predefinidas, planeie 4 GB. Mapas de calor e gravação de sessão aumentam esse requisito. O mínimo existe porque PHP-FPM, MariaDB, nginx e arquivamento partilham o mesmo servidor.
O Umami Precisa de um Banner de Cookies na UE?
Segundo a maioria das interpretações dos reguladores da UE, não. O Umami não escreve um cookie de rastreamento por padrão. Utiliza dados de pedidos de primeira parte e agrega-os do lado do servidor. Algumas jurisdições podem ainda exigir uma notificação, por isso consulte as orientações da APD local se a conformidade for a razão principal.
Como o Umami se Compara ao Plausible Auto-Hospedado?
A história de auto-alojamento do Umami é mais suave. A Plausible Community Edition existe, mas o foco comercial do Plausible é a Cloud. O Umami trata o auto-alojamento como a principal via de distribuição. Para um deployment self-hosted-first, o Umami é a escolha mais segura. Para SaaS, tanto o Plausible Cloud como o Umami Cloud funcionam.
Qual localização de datacenter é melhor para analytics auto-hospedada na UE?
Frankfurt é a escolha padrão para públicos alemão, austríaco e da UE em geral. Amsterdam é adequada para tráfego Benelux. London funciona para o RGPD do Reino Unido, mas não para requisitos de residência de dados exclusivos da UE. Escolha a região mais próxima dos seus visitantes, a menos que as necessidades de conformidade apontem para um local mais específico.