Como construir um painel de administração RGPD sozinho

Um desenvolvedor solo precisa de métricas tanto quanto uma equipe de 50 pessoas. Talvez até mais. Quando você está sozinho gerenciando o backend, o frontend, o marketing e o suporte, você não pode se dar ao luxo de adivinhar o que está acontecendo. Você precisa ver: quantos usuários estão ativos, quais funções estão sendo usadas, se o backend está suportando a carga, se o pipeline de voz está falhando.

Eu construí um painel de administração completo para TAMSIV, um sistema de alertas por e-mail para incidentes críticos e um rastreamento de análises em conformidade com o RGPD. Veja como tudo isso se encaixa e por que cada peça é essencial quando você opera sozinho.

Pontos-chave a serem lembrados:
- Um painel de administração não é um luxo — é vital para um desenvolvedor solo em produção
- GA4 com Consent Mode permite conformidade com o RGPD sem sacrificar as métricas
- Alertas por e-mail (AlertService) detectam problemas antes dos usuários
- O consentimento de cookies com 3 opções e versionamento é o mínimo RGPD na Europa
- O rastreamento duplo (GA4 + Supabase) cobre métricas da web E métricas de negócios

Por que um desenvolvedor solo precisa de um painel de administração?

A resposta curta: porque você não tem uma equipe SRE, nem um gerente de produto, nem um analista. Você é tudo isso ao mesmo tempo. E sem visibilidade do que está acontecendo em seu aplicativo, você toma decisões às cegas.

Antes do painel, eu descobria os problemas através do feedback dos usuários (quando eles se davam ao trabalho de escrever). Uma falha no pipeline de voz podia passar despercebida por horas. Um pico de inscrições passava sem ser notado. Uma funcionalidade que ninguém usava continuava a me custar tempo de manutenção.

O painel de administração mudou isso. Acessível em /admin/dashboard em tamsiv.com, ele me dá uma visão em tempo real de tudo o que importa:

• Usuários: Inscrições diárias, usuários ativos (DAU/WAU/MAU), retenção
• Funcionalidades: Uso do ditafone, criação de tarefas/memos/eventos, gamificação
• Infraestrutura: Latência WebSocket, taxa de erro STT, fallbacks LLM acionados
• Negócios: Conversões Free → Pro, receitas RevenueCat, taxa de cancelamento

Como construir um painel de administração com Recharts e Supabase?

O painel é construído com Recharts, uma biblioteca de gráficos React baseada em D3.js. Por que Recharts? Porque ele se integra nativamente com React, suporta SSR (importante para Next.js) e a renderização é limpa sem configuração complexa.

A arquitetura é simples:

1. Dados: Tudo vem do Supabase via funções RPC. Cada gráfico tem sua própria RPC que agrega os dados no lado do servidor.
2. Cartões de estatísticas: No topo do painel, os cartões mostram os KPIs em tempo real (total de usuários, ativos hoje, tarefas criadas, etc.).
3. Gráficos temporais: Curvas de inscrições diárias, uso por funcionalidade, histogramas de retenção.
4. Tabelas: Lista dos últimos eventos (inscrições, erros, alertas).

Um ponto importante: as RPCs do Supabase usam parâmetros com o prefixo p_ (convenção do projeto). Por exemplo, p_start_date, p_end_date, p_metric_type. Essas RPCs fazem os cálculos de agregação diretamente no PostgreSQL — muito mais performático do que buscar milhares de linhas no lado do cliente.

O painel é protegido por uma verificação de função de administrador no middleware Next.js. Apenas usuários com a função admin no Supabase Auth podem acessá-lo.

O que é o AlertService e por que ele é crítico em produção?

O painel é para quando você está na frente da sua tela. Mas os incidentes não esperam que você abra o painel. O AlertService é meu sistema de monitoramento automático que me envia um e-mail quando algo anormal acontece.

Aqui estão os alertas configurados:

• Fallback LLM acionado: Quando o modelo principal (via OpenRouter) falha e o fallback assume. Isso indica um problema no provedor ou um pico de carga.
• Erros repetidos no pipeline de voz: Se o STT ou o TTS falharem mais de X vezes em Y minutos, eu recebo um e-mail. Isso pode indicar uma falha no Deepgram ou um problema de cota no OpenAI.
• Rate limiting excessivo: Se um usuário ou um IP acionar o rate limiter repetidamente, pode ser um abuso ou um bot.
• Falha de inscrição: Se o fluxo de inscrição (e-mail ou código QR) falhar para vários usuários, provavelmente há um bug.

Os e-mails são enviados via Resend, um serviço de e-mail transacional simples e confiável. Cada alerta também é registrado em uma tabela do Supabase para histórico — posso encontrar o histórico de incidentes no painel de administração.

Como implementar o GA4 com o Consent Mode do RGPD?

O RGPD (Regulamento Geral sobre a Proteção de Dados) é inegociável para um site europeu. Isso significa: sem rastreamento sem consentimento explícito. O Google Analytics 4 suporta nativamente o Consent Mode, um mecanismo que ajusta seu comportamento de acordo com o consentimento do usuário.

Veja como funciona em tamsiv.com:

1. Inicialização no modo "denied": O GA4 é carregado na inicialização do site, mas com analytics_storage: 'denied' e ad_storage: 'denied'. Nenhum dado é coletado.
2. Consentimento explícito: Quando o usuário aceita os cookies de análise no banner, o consentimento é atualizado via gtag('consent', 'update', { analytics_storage: 'granted' }).
3. Modelagem: Com o Consent Mode, o Google usa a modelagem para estimar os dados dos usuários que não consentiram. Você obtém tendências confiáveis mesmo que 50% dos visitantes recusem o rastreamento.

A tag GA4 (G-VVLHW673V3) é inicializada apenas uma vez, no primeiro carregamento da página. O consentimento é persistido em um cookie de primeira parte e restaurado a cada visita. Se o usuário mudar de ideia, ele pode modificar suas preferências no banner de cookies acessível no rodapé.

Como projetar um consentimento de cookies em conformidade com o RGPD?

O banner de cookies do TAMSIV tem 3 opções, cada uma com uma função precisa:

• Necessários (sempre ativos, não desativáveis): Sessão de autenticação, preferências de idioma, o próprio consentimento de cookies. Sem esses cookies, o site não funciona.
• Análise (desativado por padrão): GA4, métricas de navegação do Supabase. Ativo apenas após consentimento.
• Marketing (desativado por padrão): Previsto para o futuro (retargeting, pixels de publicidade). Desativado por enquanto, pois não é usado.

Um ponto frequentemente negligenciado: o versionamento do consentimento. Se a política de cookies mudar (adição de um novo rastreador, modificação das finalidades), o banner deve reaparecer para todos os usuários, mesmo aqueles que já consentiram. Eu implementei isso com um número de versão armazenado no cookie de consentimento. Quando a versão muda, o banner é exibido novamente.

Por que usar um rastreamento duplo GA4 + Supabase?

O GA4 é excelente para métricas web padrão: visualizações de página, taxa de rejeição, fontes de tráfego, conversões. Mas há métricas que o GA4 não consegue capturar, ou não com a precisão necessária:

• Jornada de conversão detalhada: O caminho exato de um visitante da landing page à inscrição, com as interações intermediárias (clique em CTA, abertura de FAQ, mudança de idioma).
• Métricas de negócios: Número de tarefas criadas via web vs. aplicativo móvel, taxa de conclusão de tarefas, atividade de gamificação.
• Atribuição multi-dispositivo: Um usuário que descobre o site no desktop e baixa o aplicativo no celular. O GA4 não faz essa conexão. O Supabase, com o UUID de autenticação, sim.

O rastreamento do Supabase funciona com um UUID anônimo por visitante (gerado no primeiro carregamento, armazenado no localStorage). Cada interação significativa é registrada em uma tabela do Supabase. Quando o visitante se inscreve, o UUID anônimo é vinculado à sua conta de autenticação — o que permite reconstruir a jornada completa, do primeiro clique à inscrição.

Esse rastreamento duplo me dá duas leituras complementares: GA4 para tendências macro (de onde vêm os visitantes, quais páginas têm bom desempenho) e Supabase para insights micro (qual é a jornada típica que leva a uma conversão).

Quais métricas priorizar para um aplicativo móvel?

Quando você está começando, você é tentado a medir tudo. Má ideia — você se afoga em dados sem agir. Aqui estão as métricas que eu priorizo no painel do TAMSIV:

1. DAU (Daily Active Users): O pulso do aplicativo. Se cair, algo está errado.
2. Taxa de retenção D1/D7/D30: Quantos usuários retornam. Esta é a métrica mais importante para um produto de produtividade.
3. Taxa de conclusão da primeira tarefa: Os novos usuários conseguem criar sua primeira tarefa? Se não, o onboarding tem um problema.
4. Conversão Free → Pro: O cerne da batalha. Quantos usuários gratuitos se tornam pagantes e após quantos dias de uso.
5. Taxa de erro do pipeline de voz: A porcentagem de conversas de voz que falham. Deve permanecer abaixo de 2%.

Cada uma dessas métricas tem seu gráfico no painel, com uma tendência de 7 e 30 dias. Um sistema de limites coloridos (verde/laranja/vermelho) me permite ver rapidamente se tudo está bem.

Como os alertas por e-mail salvaram minha produção?

Exemplo concreto: em um sábado à noite, recebi um e-mail "Fallback LLM acionado — 12 vezes em 15 minutos". O modelo principal no OpenRouter estava sobrecarregado. Sem o alerta, eu teria descoberto na segunda-feira, olhando as métricas. Graças ao alerta, verifiquei se o fallback estava funcionando corretamente (estava) e pude me comunicar proativamente, se necessário.

Outro exemplo: um pico de rate limiting em um IP específico. Ao investigar, descobri um script automatizado que tentava criar contas em massa. O rate limiter fez seu trabalho, mas o alerta me permitiu bloquear o IP e reforçar a proteção.

O AlertService é minha rede de segurança. Ele não substitui o monitoramento (também uso os logs do Railway para o backend), mas me avisa sobre os incidentes mais críticos sem que eu precise monitorar ativamente.

FAQ

É necessário um painel de administração desde o lançamento?

Não necessariamente no dia 1, mas assim que você tiver usuários em produção, sim. Eu o construí algumas semanas antes do lançamento e ele me salvou várias vezes. No mínimo, configure os alertas por e-mail — isso é mais urgente do que o painel visual.

O GA4 é compatível com o RGPD sem consentimento?

Não. Mesmo com o Consent Mode no modo "denied", o GA4 envia pings anônimos para o Google. Para ser 100% compatível, você deve exibir um banner de cookies e carregar o GA4 apenas após o consentimento, ou usar o Consent Mode que ajusta o comportamento. O Consent Mode é a solução recomendada pelo Google e aceita pela maioria das DPAs europeias.

Por que Recharts em vez de Chart.js ou D3 diretamente?

Recharts é um wrapper React em torno do D3. A vantagem: os gráficos são componentes React declarativos, não código imperativo. É mais natural em um projeto Next.js. O Chart.js também funciona, mas requer mais código de integração com o React.

Quanto custa o sistema de alertas por e-mail com Resend?

O plano gratuito do Resend inclui 3000 e-mails por mês. Para alertas (algumas dezenas por mês em operação normal), é mais do que suficiente. O custo é, portanto, zero para um pequeno projeto em produção.

O rastreamento do Supabase não duplica o GA4?

Não, eles medem coisas diferentes. O GA4 se destaca no tráfego da web (fontes, comportamento, conversões). O Supabase mede o comportamento no aplicativo (tarefas criadas, funcionalidades usadas, jornada multi-dispositivo). Os dois são complementares, não redundantes.