Auditoria do rastreamento de eventos em apps gerados por IA — torne-os confiáveis

Por que a análise dá errado em apps gerados por IA

Análises ruins normalmente não são sutis. Você verá taxas de conversão de checkout acima de 100%, um pico aleatório às 3h da manhã, ou um funil onde todo mundo “vê preços” mas quase ninguém “começa o trial”. Às vezes uma etapa chave está totalmente ausente, então o painel conta uma história bonita que nunca aconteceu.

Protótipos gerados por IA frequentemente chegam com rastreamento pela metade, porque o objetivo era “fazer funcionar” para uma demo, não “fazer mensurável” em produção. Uma ferramenta de IA pode copiar um snippet de rastreamento para uma página e não para as outras, disparar eventos de múltiplos lugares, ou misturar nomes antigos e novos de eventos após um refactor. Também pode acionar eventos no momento errado, como rastrear “purchase” quando o botão é clicado em vez de quando o pagamento realmente é confirmado.

Isso quebra a tomada de decisão rapidamente. Se inscrições forem contadas em excesso, você pode achar que o onboarding está ok e gastar dinheiro em anúncios. Se trials forem subcontados, pode mudar preços ou remover recursos que não eram o problema. Se a atribuição estiver bagunçada, você pode pausar uma campanha boa e reforçar uma ruim.

Análise confiável é simples de descrever: a mesma ação do usuário produz o mesmo evento, uma vez, com o mesmo significado toda vez. Você consegue explicar onde ele é disparado no código, reproduzi-lo em uma conta de teste e ver que bate com os logs e o banco de dados do app.

Quando algo parecer estranho, faça uma checagem rápida. O evento foi disparado somente após o sucesso (não no clique)? Poderia estar disparando duas vezes (cliente e servidor, ou dois listeners)? O nome é consistente entre páginas e ambientes? As contagens conferem com uma fonte da verdade como sua tabela de pedidos? Bots, tentativas repetidas ou recarregamentos estão inflando os totais?

Se você herdou um app criado por ferramentas como Bolt, v0, ou Replit, esses problemas são comuns. A equipe da FixMyMess costuma ver rastreamento emaranhado com código de UI, handlers duplicados e eventos que disparam mesmo quando as requisições falham.

Decida o que você realmente precisa medir

Antes de mexer no código ou nos painéis, decida como é “progresso real” no seu produto. Muitos apps gerados por IA falham na análise porque tentam rastrear tudo, mas perdem as poucas ações que explicam crescimento e receita.

Comece com um conjunto pequeno de ações críticas para o negócio. Para muitos produtos, é alguma versão de: signup (conta criada com sucesso), activation (primeira tarefa relevante), purchase (dinheiro trocou de mãos ou plano pago iniciado), retention (usuário volta e faz a ação chave de novo), e às vezes referral/compartilhamento.

Defina cada evento em uma frase que responda duas perguntas: quando ele dispara e por que você se importa. Exemplo: "signup_completed" dispara depois que o usuário confirma o e-mail, porque este é o ponto mais cedo em que podemos confiar que a conta é real.

Escolha um estilo de nomeação e mantenha-o. Nomes simples e legíveis vencem os engenhosos. Escolha um formato (como verbo_substantivo), mantenha o tempo verbal consistente e evite nomes que soem como elementos da UI (por exemplo, blueButtonClick).

Mantenha ações do usuário separadas de eventos do sistema. Uma ação do usuário é “projeto_criado” ou “trial_iniciado”. Um evento de sistema é “email_enviado” ou “webhook_recebido”. Quando mistura os dois, funis deixam de significar o que você pensa.

Escreva também o que significa sucesso para cada evento. Pode ser uma contagem, uma taxa de conversão ou um tempo até a ação. Isso facilita auditorias depois, especialmente se você herdou código gerado por IA e precisa provar o que os usuários fizeram.

Mapeie eventos para ações reais do usuário

Boa análise começa com um mapa simples: o que uma pessoa real faz, passo a passo, e o que você espera registrar em cada passo. Se pular isso e ir direto aos painéis, você acaba medindo cliques que não significam nada.

Escreva seus fluxos de usuário principais em linguagem simples. Mantenha apenas as ações que importam, não todo botão. Um conjunto típico é: primeira visita, cadastro, login, sua funcionalidade principal (a ação que prova valor) e checkout.

Para cada passo, capture três coisas: (1) o nome esperado do evento, (2) o momento em que deve disparar, e (3) onde deve disparar (cliente, servidor ou ambos). Isso transforma “rastreamento está quebrado” em algo que você pode apontar e consertar.

Os casos de borda são onde apps gerados por IA frequentemente se afastam da realidade. Um modal pode disparar um evento ao abrir e de novo ao submeter. Um redirect pode disparar views de página duplicadas. Um formulário multi-etapas pode registrar um evento de conclusão em cada etapa porque o estado é reiniciado.

Ao mapear cada fluxo, anote os casos que você precisa testar: atualizar ou botão Voltar, tentativas repetidas (duplo clique, reenvio, retry de pagamento), redes lentas, conexões instáveis e diferenças entre mobile e desktop.

Exemplo: um usuário faz signup, é redirecionado para um dashboard, então o app restaura a sessão ao carregar. Se tanto o handler de sucesso do signup quanto o código de restauração de sessão enviarem "signup_completed", seu funil mostra dois signups para uma pessoa.

Entenda de onde os eventos vêm

Quando você audita rastreamento, a primeira tarefa é simples: encontre a linha exata de código que dispara cada evento. Em apps gerados por IA, essa linha pode se mover rápido conforme a ferramenta reescreve componentes, adiciona helpers ou duplica lógica.

Eventos no cliente vs no servidor

Eventos do lado do cliente (navegador ou app móvel) são melhores para ações de UI e contexto, como cliques, views de página e passos de formulário. Eles capturam o que o usuário viu e fez, mas são mais fáceis de bloquear ou perder (ad blockers, erros de script, redes instáveis).

Eventos do lado do servidor (sua API, jobs backend, webhooks) são melhores para coisas que você precisa confiar, como pagamentos confirmados, mudanças de assinatura ou criação de conta. São mais difíceis de falsificar e geralmente mais confiáveis, mas podem perder a intenção de UI (por exemplo, o usuário tentou pagar e desistiu).

Em código gerado por IA, eventos frequentemente são acionados a partir de alguns lugares repetidos: handlers de UI (onClick, onSubmit), hooks e efeitos (useEffect), wrappers de API, gerenciadores de estado e utilitários compartilhados como uma função genérica track().

Duplicatas normalmente vêm de código que roda mais do que você imagina: rerenders que rebindam handlers, múltiplos listeners anexados à mesma ação, logging otimista na UI somado à confirmação do servidor, ou requisições que fazem retry e logam cada tentativa.

Eventos que faltam tendem a ser menos dramáticos mas igualmente comuns: retornos antecipados antes da chamada de tracking, exceções que pulam a linha, scripts bloqueados pelo navegador ou condições de corrida onde o app navega antes do evento ser enviado.

Uma checagem rápida: se “Signup Completed” é enviado por um efeito React que depende do estado do usuário, um refresh pode dispará-lo de novo. Se for enviado pelo servidor somente após o registro ser criado, ele vai disparar uma vez, mas você ainda vai querer um Signup Started separado para entender abandono.

Passo a passo: audite um evento de ponta a ponta

Escolha um fluxo de usuário que importe e mantenha pequeno. Um bom começo é signup, depois verificação de e-mail (se houver), depois a primeira ação chave (como criar um projeto ou salvar um rascunho). Quando confiar nesse fluxo, o resto fica mais fácil.

Antes de testar, escreva o que você espera em linguagem simples: qual evento deve disparar, exatamente quando, e o que deve conter. Essa é a menor especificação útil de evento.

Aqui está uma rotina ponta a ponta que funciona mesmo em codebases bagunçadas geradas por IA:

1. Rode o fluxo como um usuário real e observe eventos em tempo real enquanto faz isso.
2. Pause em cada momento que deveria disparar um evento e confirme que ele acontece naquele momento.
3. Repita a mesma ação duas vezes para pegar disparos duplos. Um clique deve significar um evento.
4. Abra o payload do evento e verifique o básico: user_id (ou anonymous_id), session_id, plano ou tier, origem (web/app/referral), nome da tela/página e qualquer estado de erro.
5. Após o processamento, confirme que o mesmo evento aparece nos relatórios com as mesmas contagens e segmentações.

Use um cenário concreto de “falha” enquanto testa. Se você submeter o formulário de cadastro e receber um erro de validação, deve ver um evento de falha (ou uma propriedade de erro) sem também ver um evento de sucesso. Se ambos aparecerem, seu funil ficará melhor do que a realidade.

Ao seguir para o próximo fluxo, mantenha notas: nome do evento, momento esperado, momento real, duplicatas, propriedades faltando e qual arquivo ou componente parece responsável.

Encontre disparos duplicados e eventos faltantes

Eventos duplicados são uma das maneiras mais rápidas de perder confiança nos números. Comece comparando o que você vê nos painéis com o que consegue reproduzir em um teste manual rápido.

Como identificar duplicatas (e por que acontecem)

Duplicatas normalmente aparecem como o mesmo nome de evento com as mesmas propriedades-chave disparando dentro de um ou dois segundos. Views de página que aumentam mesmo sem navegação são outro sinal.

Sinais comuns: eventos idênticos repetidos, funis onde passos finais têm mais conclusões que os anteriores, picos repentinos que não correspondem ao tráfego e métricas que mudam muito ao atualizar a página.

Causas raízes em apps gerados por IA costumam ser simples: loops de rerender em React, tracking adicionado tanto no componente quanto num handler global, listeners anexados duas vezes ou retries de rede que reenviam o mesmo evento sem idempotência.

Como identificar eventos faltantes

Eventos faltantes aparecem como quedas que não batem com o que você vê nos testes. Se você consegue completar “Adicionar ao carrinho” na prática mas o funil mostra uma lacuna grande, provavelmente o rastreamento nunca dispara, dispara só às vezes ou dispara antes da ação terminar.

Correções que costumam funcionar são diretas: adicionar uma proteção para que um evento só possa disparar uma vez por ação, debouncer em handlers de clique, mover o rastreamento para uma camada única (frequentemente o handler final de submit), adicionar uma chave de idempotência (como order_id ou request_id) para que retries não criem duplicatas, e rastrear após o sucesso em vez de no clique (especialmente para auth e pagamentos).

Confirme a correção executando o mesmo fluxo novamente e comparando antes e depois. Teste também em rede lenta, porque retries são onde duplicatas e eventos faltantes costumam se esconder.

Verifique identidade, sessões e atribuição

Se seus gráficos parecem “quase certo” mas os funis estão errados, tratamento de identidade e sessões costuma ser a razão. Apps gerados por IA frequentemente misturam trackers client-side, bibliotecas de auth e correções rápidas que não concordam sobre quem é o usuário.

Identidade: escolha uma fonte de verdade

Defina uma única estratégia confiável de user ID e aplique-a em todo lugar. Na maioria dos apps isso significa rastrear anonimamente até o login ou signup completar, e então trocar para um ID interno estável (não um e-mail, não um display name).

Um bug comum é a mesclagem incorreta de usuários anônimos e logados. Exemplo: um usuário visita anonimamente, se cadastra, faz logout e depois entra novamente em uma nova aba. Se seu código reutiliza o antigo anonymous ID, você pode mesclar duas pessoas em um perfil ou dividir uma pessoa em várias.

Ao testar identidade, foque em alguns cenários: signup e refresh (ID deve permanecer estável), logout e login de novo (ID logado deve ser o mesmo; comportamento do anonymous ID deve ser consistente), mesma ação em uma aba nova (um usuário com duas sessões, não dois usuários) e comparar janela anônima ou outro dispositivo (não mescle sem um login real).

Sessões e atribuição: mantenha simples

Fronteiras de sessão devem bater com comportamento real: nova sessão após um longo intervalo, não a cada refresh. Se seu tracker cria nova sessão no reload, você infla “novas sessões” e quebra funis.

Para atribuição, capture o básico consistentemente: source, campaign e referrer na primeira entrada significativa. Armazene isso uma vez por sessão (ou primeiro toque) e reutilize, em vez de reler a URL a cada página. Isso evita sobrescritas acidentais quando usuários navegam, pagam ou retornam de um provedor externo.

Cheque propriedades de evento e segurança dos dados

Bons nomes são só metade do trabalho. Se propriedades estiverem bagunçadas ou arriscadas, seus gráficos mentirão e você pode criar um problema de privacidade sem perceber.

Comece escrevendo um conjunto curto e estrito de propriedades obrigatórias para cada evento. Mantenha apenas o que você realmente usa em relatórios, funis ou alertas. Campos extras parecem inofensivos, mas viram lixo inconsistente rapidamente.

Uma lista simples de obrigatórios pode incluir:

• user_id (ou anonymous_id quando deslogado)
• source (onde a ação começou, tipo "pricing" ou "settings")
• plan ou product_id (só se você usar)
• value (um número, mesma unidade sempre)
• environment (prod vs staging)

Depois verifique tipos e consistência. Um app pode enviar value: "19.99" como string, outro envia value: 19.99 como número, e um terceiro envia value: null quando a UI falha. Escolha um formato, aplique e decida o que fazer quando faltar dado (dropar o evento, usar default ou marcar inválido).

Segurança dos dados é inegociável. Eventos são logados, reproduzidos em ferramentas de debugging e armazenados por muito tempo. Escaneie payloads do cliente e logs do servidor por sinais de alerta como senhas, códigos de uso único, links de reset, tokens de acesso, chaves de API, números completos de cartão, CVV, dados bancários completos, bodies de requisição que incluam segredos ou propriedades de “debug” que espelhem objetos inteiros.

Faça eventos de erro úteis sem vazar dados. Em vez de despejar stacks e payloads, capture o que ajuda a consertar: onde falhou (tela, passo, nome do endpoint), o que o usuário viu (mensagem curta) e um código de erro seguro.

Alinhe dashboards com a verdade

Um painel só é útil se cada gráfico responder uma pergunta clara. Se um gráfico mistura objetivos (como “signups e ativações”), fica difícil notar quando o rastreamento quebra. Nomeie a pergunta primeiro e então garanta que a matemática do gráfico bate com suas definições de evento.

Um hábito simples que mantém painéis honestos é escrever uma definição de uma linha sob cada métrica chave. Exemplo: “Ativados esta semana = usuários que completaram o onboarding E criaram o primeiro projeto.” Isso força clareza e evita passos de funil “mais ou menos”.

Antes de confiar nos números, faça uma checagem de alinhamento:

• Confirme que cada gráfico usa um evento (ou um conjunto claramente definido) e uma janela de tempo.
• Verifique filtros como ambiente, plataforma, país e versão do app para não esconder ou duplicar dados acidentalmente.
• Garanta que os passos do funil mapeiem 1:1 para sua taxonomia de eventos.
• Adicione pelo menos uma checagem externa (contagens do banco, logs do servidor, exportações do provedor de pagamento).
• Decida como excluir bots e tráfego interno, e escreva a regra.

Exemplo: seu painel mostra 1.200 “Novos signups” ontem, mas o banco tem só 900 novos registros. Isso frequentemente significa que o evento de signup dispara em “conta criada” e também em “email verificado”, ou faz retry no refresh. Corrija o evento para disparar uma vez (de preferência server-side) e atualize o gráfico para contar apenas o evento corrigido.

Exemplo: consertando um funil de signup e checkout quebrado

Um app criado por IA mostra 90% de conversão de signup no painel, mas a receita está estagnada. O fundador acha que o marketing é o problema. Na realidade, os números estavam mentindo porque o funil foi montado a partir de snippets copiados e tracking misturado entre cliente e servidor.

O que achamos nos dados

“Signup Completed” disparava duas vezes para muitos usuários: uma vez quando o formulário era submetido e outra quando o app redirecionava para a página de boas-vindas. Alguns usuários acionavam uma terceira vez no refresh.

Ao mesmo tempo, “Payment Confirmed” estava ausente para uma parte grande das compras reais. O checkout usava uma página de pagamento de terceiros, mas o app nunca registrava o webhook final de sucesso como evento, então o painel não conseguia ligar signups a usuários pagantes.

O resultado foi previsível: eventos de signup inflados por disparos duplicados no cliente, sucesso de pagamento subcontado porque o servidor não logou, e o funil pareceu saudável enquanto o negócio não estava.

Como consertamos

Movemos “Signup Completed” para um único handler que roda apenas depois do servidor confirmar que o registro do usuário foi criado. Depois tornamos o evento server-side “Payment Confirmed” idempotente (o mesmo purchase ID só pode ser contado uma vez), para que retries e reenvios de webhook não criem receita duplicada.

Para validar, rodamos um pequeno conjunto de usuários de teste (novo navegador, navegador de retorno, rede lenta) e comparamos signups reais no banco vs eventos “Signup Completed”, cobranças bem-sucedidas vs eventos “Payment Confirmed”, e contagens do funil antes e depois.

Após a correção, a conversão de signup caiu para um número mais realista, e o funil mostrou a queda verdadeira no pagamento. As decisões ficaram mais fáceis: consertar o atrito do checkout, não gastar mais em ads.

Verificações rápidas e próximos passos

Se só fizer uma coisa esta semana, audite as poucas ações das quais seu negócio depende (signup, activation, pagamento, upgrade). Pequenos erros aqui podem fazer todo relatório parecer aleatório.

Use esta checklist em qualquer evento chave:

• Dispara uma vez (sem duplo envio em refresh, botão voltar, retries ou cliente+servidor)
• Dispara no momento certo (após a ação realmente ter sucesso, não quando o botão é clicado)
• Tem as propriedades certas (plano, preço, moeda, tela, motivo de erro) e sem valores lixo
• Tem a identidade do usuário correta (IDs estáveis, sem mesclagem ou divisão acidental)
• Aparece no painel como você espera (contagens batem com ações reais que você pode reproduzir)

Quando um evento for “verdadeiro”, escreva o que ele significa em linguagem simples: nome do evento, quando ele dispara, propriedades obrigatórias e o que nunca incluir (senhas, tokens completos, dados brutos de cartão). Essa nota única torna mudanças futuras mais seguras, especialmente quando o código é editado por ferramentas de IA.

Para evitar deriva, faça uma rechecagem pequena mensal: reteste seus eventos principais ponta a ponta em staging ou conta de teste, compare uma amostra de sessões reais com os totais do painel, revise mudanças recentes que tocaram tracking ou auth e remova eventos que ninguém usa.

Se seu app foi gerado por Lovable, Bolt, v0, Cursor ou Replit, uma revisão de tracking a nível de código vale a pena. Esses projetos costumam terminar com handlers duplicados, tracking misturado cliente/servidor e bugs de identidade que só aparecem com tráfego real. Se quiser uma segunda opinião, a FixMyMess (fixmymess.ai) pode começar com uma auditoria de código gratuita para apontar disparos duplicados, eventos faltantes e captura de dados arriscada antes de você escalar.