Como verificar a precisão dos dados de análise do site

Como saber se os dados de análise do site são precisos

Os relatórios de análise podem parecer precisos, mas contabilizar a coisa errada. Uma visualização de página pode ser registada duas vezes, o envio de um formulário pode não ser contabilizado ou uma encomenda pode aparecer associada à origem errada. A questão não é se todos os relatórios correspondem exatamente a todos os outros sistemas, mas se os dados refletem as ações que o seu acompanhamento pretende registar. Uma auditoria focada em alguns eventos pode revelar onde os números divergem.

Se quer saber como avaliar a precisão dos dados de análise do site, comece por um teste repetível, em vez de fazer uma revisão abrangente de todos os painéis. Escolha uma pequena amostra, acompanhe cada evento ao longo do processo de recolha e compare-o com uma fonte que registe a ação subjacente. Anote as condições do teste, porque um teste num navegador com sessão iniciada pode ter resultados diferentes de um realizado numa sessão limpa. Para quem procura como verificar a precisão dos dados de análise do site, este método permite distinguir problemas de recolha de diferenças esperadas entre sistemas.

1. Escolha um pequeno conjunto de eventos para auditar

Escolha dois ou três eventos importantes para o objetivo do site. Para uma empresa de serviços, podem ser uma visualização de página, o envio de um formulário de contacto e um clique num número de telefone. Para uma loja online, escolha a visualização de um produto, a ação de adicionar ao carrinho e a conclusão de uma compra. Uma lista curta torna a auditoria mais simples e permite analisar cada evento em detalhe; é um bom ponto de partida para perceber como auditar eventos de acompanhamento de um site.

Para cada evento, anote o que deve desencadeá-lo e que evidências confirmariam que ocorreu. O envio bem-sucedido de um formulário pode exigir uma mensagem de confirmação e um novo registo na caixa de entrada do formulário; uma compra pode exigir uma encomenda concluída no sistema de comércio eletrónico. Não defina uma compra como um clique num botão se o pagamento ainda puder falhar.

• Visualização de página: um carregamento de página deve gerar um único evento de visualização de página.
• Envio de formulário: um envio válido deve gerar um evento e uma resposta armazenada.
• Compra: uma encomenda concluída deve ter um identificador de transação e um valor registado.

Inclua também as condições esperadas. Se o evento do formulário só deve ser acionado após a validação bem-sucedida, uma tentativa falhada não deve ser contabilizada. Esta distinção é importante quando alguém clica em «Enviar» sem preencher um campo obrigatório: o botão foi clicado, mas o formulário não foi enviado.

2. Acompanhe cada evento desde a ação até ao relatório

Acompanhe uma ação de teste em cada etapa do processo: a camada de dados ou o código de acompanhamento do site, o pedido enviado, o sistema de recolha de dados analíticos e, por fim, o relatório. As ferramentas de programador do navegador podem mostrar se foi enviado um pedido e que nome de evento ou parâmetros incluía. Se o pedido não aparecer, o problema provavelmente está no site ou no navegador; se aparecer, mas não constar do relatório, verifique as definições de processamento e de relatórios. Para compreender como auditar eventos de acompanhamento de um site, confirme o resultado em cada uma destas etapas, em vez de se limitar ao painel final.

Por exemplo, envie um formulário de teste e anote o nome do evento, o URL da página e a hora. Verifique se o pedido de análise contém o evento esperado e, em seguida, procure-o na vista em tempo real ou de depuração da plataforma antes de consultar um relatório normal. Os relatórios podem demorar a ser processados, por isso, um relatório vazio poucos segundos após o teste não prova, por si só, que o acompanhamento está avariado. Confirme o tempo de atualização dos relatórios da plataforma antes de considerar essa diferença um problema.

Mantenha o nome do evento consistente em todas as etapas. O site pode enviar form_success, enquanto um relatório está configurado para mostrar generate_lead; ambos os nomes podem ser razoáveis, mas é necessária uma regra de mapeamento ou de relatórios que os associe. Para equipas que gerem várias propriedades, uma ferramenta de monitorização como a plataforma de análise e monitorização de sites pode ajudar a detetar alterações, mas não substitui a verificação do próprio evento.

3. Faça testes controlados numa sessão limpa do navegador

Use um perfil de navegador novo ou uma janela privada, com as extensões desativadas sempre que possível. Isso reduz a interferência de cookies guardados, visitas anteriores e extensões do navegador. Registe os passos exatos e a hora: abra a página de destino às 10h04, consulte um produto, adicione-o ao carrinho e pare. Os registos de hora facilitam a correspondência entre a atividade no navegador, os pedidos de análise e os registos do servidor.

Mantenha o teste simples e focado. Não abra vários separadores, não atualize a página repetidamente nem navegue enquanto o evento está a ser verificado. Essas ações podem gerar visualizações de página adicionais e fazer uma implementação correta parecer duplicada. Se precisar de testar o comportamento de um visitante que regressa, faça-o num teste separado e identifique-o claramente.

Faça um teste com o consentimento para análise aceite e outro com o consentimento recusado, se o site oferecer essa opção. Registe o que mudou. A ausência de um evento de análise após a recusa do consentimento pode ser o comportamento esperado, enquanto a ausência do evento após a aceitação pode indicar um problema de configuração. O resultado só faz sentido se o estado do consentimento fizer parte do registo do teste.

4. Compare os dados de análise com um registo independente

Compare uma amostra limitada com outro sistema que registe a ação subjacente. Para envios de formulários, consulte a caixa de entrada do formulário ou a base de dados. Para encomendas, consulte as transações concluídas no sistema de comércio eletrónico. Os registos do servidor podem ajudar a confirmar que uma página ou um ponto de acesso foi solicitado, mas um pedido registado não significa necessariamente que uma pessoa tenha visto a página ou concluído a ação.

Escolha um intervalo de tempo fixo e um pequeno número de registos de teste. Sempre que possível, associe-os usando um registo de hora, um ID de encomenda ou outro identificador comum. Evite comparar totais gerais de intervalos de datas diferentes: fusos horários, atrasos no processamento, filtros e regras de retenção podem alterar as contagens. Se a análise indicar 12 compras e o sistema de encomendas apresentar 12 encomendas concluídas no mesmo intervalo de teste, isso é uma evidência útil, mas confirme também se os IDs das transações individuais correspondem.

É de esperar algumas diferenças, porque os sistemas registam coisas diferentes. Um registo do servidor pode incluir pedidos automatizados e recarregamentos de páginas; uma plataforma de análise pode omitir visitas em que o acompanhamento foi bloqueado ou o consentimento foi recusado. Para saber mais sobre uma das causas de contagens inflacionadas, consulte porque é que os números de análise do site estão inflacionados. A comparação deve explicar a diferença, não partir do princípio de que um dos sistemas está automaticamente certo.

5. Procure eventos duplicados e em falta

Repita a mesma ação mais de uma vez, mas mantenha cada execução separada. Envie o formulário de teste uma vez, aguarde a confirmação e verifique se foi criado um evento e um registo. Se o evento aparecer duas vezes, verifique se é acionado tanto pelo clique no botão como pela página de confirmação, ou se um novo carregamento da página o envia novamente.

Os percursos interrompidos revelam outro tipo de erro. Inicie o processo de finalização da compra, saia antes do pagamento e confirme que não aparece nenhum evento de compra concluída. Em seguida, conclua uma encomenda de teste e confirme que o evento é acionado uma vez com o identificador de transação correto. Um evento de compra acionado ao clicar em «Fazer encomenda» pode contar compras a mais se o pagamento falhar ou se o cliente voltar à página.

Os eventos em falta podem ser mais difíceis de detetar do que os duplicados. Teste erros de validação, uma ligação lenta e o regresso através do botão «Voltar», se estas situações ocorrerem no site. Um formulário pode guardar uma resposta com sucesso, apesar de um script falhar antes de enviar o evento de análise. Essa diferença é um problema de acompanhamento, não um contacto em falta.

6. Verifique o consentimento, o bloqueio e os efeitos entre domínios

Faça testes nas condições em que os visitantes reais utilizam o site: com o consentimento aceite e recusado, num navegador com proteções de privacidade ativadas e, se for relevante, com um bloqueador de anúncios. Registe o navegador e a opção escolhida em cada teste. Um pedido bloqueado pode nunca chegar à plataforma de análise, mesmo que a página ou o formulário funcionem normalmente. Por isso, nem sempre é possível obter uma correspondência exata, visita a visita, com os registos do servidor.

Os percursos entre domínios precisam de uma verificação à parte. Se um cliente passar da loja para um prestador de serviços de pagamento e regressar, confirme que a configuração de análise trata a transição conforme esperado e que a página de regresso não inicia uma sessão nova e sem relação com a anterior. Teste um percurso concluído e verifique o domínio de referência, os detalhes da sessão e o ID da transação. Se a transferência não estiver configurada corretamente, o prestador de serviços de pagamento pode surgir como origem de referência.

As regras de consentimento e os controlos de privacidade do navegador também podem alterar a informação disponível. Não considere um total de análise inferior como prova de que o site perdeu o mesmo número de transações. Primeiro, determine que ações cada sistema tem autorização e está configurado para recolher; para saber mais sobre alterações nos navegadores, leia o que mudou no suporte a cookies de terceiros.

7. Registe as conclusões e volte a testar após as alterações

Mantenha um registo breve da auditoria com a data, o navegador, a opção de consentimento, os passos executados, o evento esperado, o evento observado e o ID de qualquer registo correspondente. Indique se o resultado veio de um relatório em tempo real, de uma vista de depuração ou de um sistema de back-end. Esse detalhe evita que um colega confunda um atraso temporário no processamento com uma falha confirmada do acompanhamento.

Depois de corrigir o problema, repita o mesmo teste nas mesmas condições. Se o evento era enviado duas vezes, confirme que a versão corrigida o envia uma só vez e que o formulário continua a criar o respetivo registo. Para saber como testar o acompanhamento de conversões, faça também uma compra de teste controlada, confirme o registo independente da encomenda e verifique se o evento de conversão aparece uma única vez com o identificador e o valor corretos. Volte a testar após alterações importantes no site, como a reconstrução de um formulário ou a atualização do processo de finalização da compra, pois essas mudanças podem alterar o acionador, mesmo que o painel de análise não tenha sido alterado.