Publicar uma landing page não encerra o trabalho. A URL no ar abre uma etapa diferente: entender quem chegou, por onde entrou, o que conseguiu acessar e onde a experiência pode estar falhando.

Um agente de IA ajuda a consultar, organizar e comparar esses sinais. Ele não transforma pageviews em certeza sobre o comportamento das pessoas. A análise melhora quando você separa dado observado, hipótese e decisão de produto.

Este guia mostra como usar o Analytics do Site no Ar no painel ou pelo MCP, interpretar as métricas disponíveis e pedir melhorias sem inventar conclusões.

O que o Analytics do Site no Ar mostra

O Analytics é um recurso do plano Pro. Cada Site tem seu próprio resumo, com janelas de 7, 30 ou 90 dias.

O painel e a ferramenta MCP get_site_analytics entregam:

  • pageviews e visitantes no período;
  • média de tempo de engajamento;
  • série diária de pageviews e visitantes;
  • páginas mais vistas;
  • principais origens de tráfego identificadas;
  • países e tipos de dispositivo;
  • total de respostas 404 e caminhos quebrados mais frequentes.

O recorte é por Site ID, não por nome de campanha solto. Isso evita misturar a landing correta com outro Site de slug parecido.

Uma publicação muito recente pode aparecer com zeros enquanto os primeiros eventos são agregados. Zero também pode significar que ainda não houve acesso. Antes de diagnosticar um problema, confirme se a URL foi compartilhada e se o período escolhido cobre a campanha.

Comece pela pergunta, não pelo gráfico

Uma tela cheia de números convida a procurar qualquer variação interessante. O caminho mais útil é registrar a pergunta antes da consulta.

Exemplos:

  • a campanha realmente levou pessoas para a URL publicada?
  • qual página recebeu mais acessos?
  • o tráfego identificado veio das origens esperadas?
  • a maior parte dos acessos aconteceu em celular ou desktop?
  • existe um caminho quebrado consumindo tráfego?
  • a mudança publicada alterou um sinal de forma consistente?

Cada pergunta pede uma leitura diferente. Se o objetivo é encontrar um link quebrado, respostas 404 são mais importantes que o total de visitantes. Se o objetivo é revisar responsividade, a distribuição por dispositivo orienta o teste, mas não prova que a experiência mobile está boa ou ruim.

Como interpretar cada métrica

Pageviews e visitantes

Pageviews contam visualizações de página. Visitantes representam pessoas distintas dentro da medição do período. As duas métricas respondem perguntas diferentes.

Mais pageviews que visitantes pode indicar retornos ou navegação entre páginas. Também pode refletir recarregamentos. O número, sozinho, não revela a intenção.

Compare os dois com o contexto da campanha:

Sinal observado Hipóteses para investigar O que conferir
visitantes abaixo do esperado distribuição não aconteceu, URL errada ou período inadequado canal, link divulgado e janela
muitas views por visitante retorno, navegação ou recarregamento top pages e fluxo real da landing
pico em um único dia disparo de campanha ou tráfego incomum calendário e origem
queda depois de republicar mudança de distribuição ou problema na experiência deploy, URL, 404 e canais

Evite chamar pageview de conversão. O Analytics não informa, por si só, se uma venda, lead ou agendamento foi concluído.

Tempo de engajamento

O tempo médio ajuda a perceber se houve permanência suficiente para interagir com a página. Ele não mede compreensão, satisfação ou compra.

Uma landing curta pode cumprir o objetivo rapidamente. Uma página longa pode exigir mais tempo. Compare versões da mesma experiência e mantenha oferta, origem e período em mente.

Use a métrica como ponto de partida:

  • tempo baixo e muitos acessos mobile: teste carregamento, primeira dobra e legibilidade no celular;
  • tempo baixo em uma origem específica: confira se anúncio e página fazem a mesma promessa;
  • tempo maior sem resultado comercial: revise CTA, objeções e integração de conversão fora deste painel.

Páginas mais vistas

Em um Site com múltiplas Pages, o ranking mostra quais caminhos concentram acesso. Ele ajuda a encontrar uma rota que merece revisão prioritária ou uma página importante que quase não recebe visitas.

Antes de mudar a arquitetura, confirme:

  • se todos os caminhos esperados foram publicados;
  • se a navegação aponta para as rotas corretas;
  • se a campanha divulgou a URL pretendida;
  • se as páginas fazem parte do mesmo funil.

Origens do tráfego

As origens identificadas mostram referers como sites, redes e mecanismos de busca. Acesso direto ou uma origem que não envia referer pode não aparecer nessa lista.

Por isso, não some as origens esperando reproduzir o total de pageviews. Use-as para encontrar padrões, não para forçar uma atribuição completa de marketing.

Quando uma origem está trazendo público, abra o contexto dessa promessa. A landing precisa continuar a conversa iniciada no link, no post ou no resultado de busca.

Países e dispositivos

País e dispositivo ajudam a priorizar testes. Se celular domina o período, revise primeira dobra, tamanho de texto, área de toque, formulário e velocidade em tela pequena antes de polir detalhes exclusivos do desktop.

País não deve ser tratado como perfil completo da pessoa. Use o sinal para conferir idioma, condições comerciais e destinos que realmente variam por região.

Respostas 404

Uma resposta 404 é o sinal mais diretamente acionável do painel. Ela indica que alguém tentou abrir um caminho inexistente.

Para cada caminho quebrado:

  1. identifique de onde o link pode ter vindo;
  2. decida se a rota deveria existir;
  3. corrija o link ou publique a página ausente;
  4. republique o mesmo Site quando houver mudança;
  5. abra a URL e teste o caminho;
  6. acompanhe o período seguinte.

O checklist de QA para landing pages criadas com IA ajuda a evitar esses erros antes da publicação. O Analytics mostra o que ainda escapou no uso real.

Peça uma análise que preserve evidência

Com o MCP configurado, um pedido útil inclui Site, período, objetivo e formato da resposta.

Analise o Site [site_id] no período de 30 dias.
Use get_site_analytics e retorne:
1. fatos observados, com os valores recebidos;
2. anomalias ou mudanças que merecem investigação;
3. hipóteses separadas dos fatos;
4. checks que podem confirmar ou rejeitar cada hipótese;
5. no máximo três melhorias priorizadas por impacto e evidência.
Não trate pageview como conversão.
Não invente benchmark, meta ou causa.
Não altere nem republique a página nesta etapa.

Essa primeira rodada é somente leitura. Depois que a equipe escolhe uma hipótese, a mudança vira uma tarefa separada, com escopo e critério de sucesso.

Compare períodos sem criar uma falsa experiência

O Analytics oferece janelas móveis de 7, 30 e 90 dias. Elas ajudam a enxergar curto, médio e longo prazo, mas não formam automaticamente um teste A/B.

Uma comparação antes e depois pode ser afetada por:

  • volume e mix de canais;
  • dia da semana;
  • oferta e preço;
  • sazonalidade;
  • mudança no público;
  • campanha pausada ou ampliada;
  • republicações além da alteração analisada.

Registre a versão e o momento do deploy. O fluxo de republicação com agente de IA mostra como manter o mesmo Site ID e a mesma URL entre ajustes.

Transforme sinal em uma mudança pequena

Evite pedir ao agente para “otimizar tudo”. Escolha uma hipótese observável.

Exemplo:

Fato: celular representa a maior parte dos acessos no período.
Hipótese: a primeira dobra está densa demais em tela pequena.
Mudança: reduzir somente a densidade da primeira dobra no mobile,
sem alterar oferta, prova, CTA, tracking ou layout desktop.
Validação: rodar os checks do projeto, revisar em largura pequena,
republicar o mesmo Site e abrir a URL final.

Depois da publicação, aguarde dados suficientes e compare com o contexto registrado. Se a mudança não responder à pergunta, reverta ou formule outra hipótese.

O que o Analytics não decide

O painel não substitui:

  • a definição de conversão do negócio;
  • a integração com CRM, checkout ou formulário;
  • a política de consentimento e privacidade;
  • pesquisa qualitativa com clientes;
  • aprovação de oferta, copy ou identidade;
  • um experimento desenhado para atribuir causalidade.

Ele oferece evidência operacional para fazer perguntas melhores. O agente reduz o trabalho de consultar e resumir. A equipe continua responsável por decidir o que significa sucesso.

Um ciclo simples de pós-publicação

Use este ciclo:

  1. publique e verifique a URL;
  2. registre Site ID, deploy, data e objetivo;
  3. aguarde a janela adequada;
  4. consulte o Analytics;
  5. separe fatos de hipóteses;
  6. escolha uma mudança pequena;
  7. execute o QA antes de republicar;
  8. republique o mesmo Site;
  9. confira a URL e registre a nova versão;
  10. volte aos dados com o contexto preservado.

Uma landing page melhora quando o ciclo produz aprendizado, não apenas mais versões. Conecte o agente pela documentação de Configuração, consulte o Site correto e trate cada métrica como um sinal que ainda precisa de contexto.