A tua analítica diz que o sítio faturou 42 180 no mês passado. A tua base de dados de encomendas diz 39 650. Alguém pergunta qual está certa, e a resposta honesta costuma ser nenhuma, por razões que isoladamente são aborrecidas e no conjunto são caras.
Aqui estão as cinco causas, mais ou menos pela ordem da frequência com que cada uma é a verdadeira, com uma maneira de as distinguir.
1. A página de confirmação dispara mais do que uma vez
Esta é de longe a causa mais comum, e inflaciona sempre o valor.
O evento de compra costuma estar na página de confirmação da encomenda. Essa página é carregada outra vez sempre que alguém a recarrega, carrega em recuar e depois em avançar, a abre a partir do email, ou quando um navegador que reabre separadores no arranque a repõe. Cada uma dessas coisas dispara o evento de novo com o mesmo valor.
Reconhece-se pela forma da discrepância: a analítica está acima da base de dados de encomendas, a diferença é um múltiplo exato num punhado de encomendas grandes, e o efeito é pior no telemóvel, onde a navegação para trás é mais comum.
A solução é um número de encomenda. Envia o número da encomenda com o evento de compra e deixa a analítica eliminar duplicados com base nele. No GA4 o campo é transaction_id; a maior parte das ferramentas usa esse nome porque a convenção do GA ganhou. Se o modelo do teu gestor de etiquetas tem um campo para isso e o deixaste em branco, é aí que está o teu erro.
Vale a pena ser direto quanto ao custo de errar aqui. Uma página de compra que dispara de novo e conta uma única venda quatro vezes não parece um erro num painel. Parece um bom mês.
2. Duas moedas somadas
Se vendes em mais do que uma moeda e a tua analítica reporta um único total de receita, descobre o que ela está a fazer antes de confiares nesse total.
Algumas ferramentas convertem para uma moeda de relatório a uma taxa fixada quando os dados chegaram. Algumas convertem à taxa do dia em que olhas, o que quer dizer que um mês acabado muda de valor conforme o dia em que o abres. Algumas somam pura e simplesmente os números e põem um símbolo à frente, produzindo um valor que não é dinheiro em moeda nenhuma.
O sinal é um total que fica entre o valor convertido correto e a soma ingénua, ou um total que se mexe quando reabres um relatório de um mês que fechou há muito.
O mais seguro é a moeda ficar registada no evento quando ele é gravado e a ferramenta nunca converter. Um relatório com moedas misturadas ou divide por moeda ou se recusa a dar um total, e as duas coisas são mais úteis do que um número errado apresentado com confiança.
3. Devoluções, cancelamentos e cobranças falhadas
A tua base de dados de encomendas está sempre atualizada. Sabe que a encomenda 8814 foi devolvida no dia 14. A tua analítica gravou a compra no dia 2 e, a não ser que lhe tenhas enviado um evento de devolução, continua a acreditar nela.
Ao longo de um mês com taxas de devolução normais isto por si só pode explicar vários pontos percentuais, e é a causa que faz a analítica parecer alta face a um relatório financeiro e não face a uma tabela de encomendas.
Relacionado, e mais fácil de deixar passar: uma encomenda que foi criada e nunca foi cobrada. Se o evento dispara ao carregar a página de confirmação e o pagamento falha depois, ou a encomenda fica por pagar e é cancelada por um limite de tempo, a analítica tem uma venda que a tua contabilidade nunca teve.
4. Eventos bloqueados, perdidos e nunca enviados
Esta reduz sempre o valor, e é por isso que a analítica costuma estar abaixo da tabela de encomendas quando não está a ser inflacionada pelas causas acima.
Os bloqueadores de conteúdo travam o pedido. Algumas redes de empresa também, e alguns filtros ao nível do DNS, e alguns navegadores focados na privacidade de origem. Se a tua analítica precisa de consentimento, toda a gente que recusou também falta. E um evento de compra que dispara no carregamento da página faz uma corrida com o visitante que fecha o separador, coisa que ele faz muitas vezes no instante em que a encomenda é confirmada.
O tamanho da fatia bloqueada varia enormemente com o público (um sítio de ferramentas para programadores perde muito mais do que uma florista), portanto qualquer percentagem publicada não vale nada para o teu caso. Mede o teu: conta as encomendas que a tua base de dados gravou contra os eventos de compra que a analítica gravou, emparelhados pelo número da encomenda, ao longo de uma semana limpa.
Se não os conseguires emparelhar pelo número da encomenda, é a causa número 1 outra vez.
5. Os dois sistemas contam momentos diferentes
Por fim, a causa aborrecida, a que explica o pequeno resto que sobra depois de teres corrigido tudo o resto.
A analítica carimba a hora do evento na sessão do visitante, no fuso horário definido no relatório. A tua base de dados de encomendas carimba a linha quando o processador de pagamentos confirmou, em UTC, possivelmente minutos depois e ocasionalmente do outro lado da meia-noite. Uma mudança de mês transforma isso numa diferença real: sempre no mesmo sentido, sempre pequena.
A atribuição agrava isto. A analítica atribui a receita à sessão que converteu (ou a uma sessão anterior, conforme o modelo de atribuição), enquanto a tua tabela de encomendas não a atribui a coisa nenhuma. Comparar um total de receita por último clique com um total de encomendas em bruto é comparar as respostas a duas perguntas diferentes.
Uma reconciliação que consegues mesmo fazer
- Escolhe uma semana que já tenha fechado.
- Exporta as encomendas: número, data e hora em UTC, moeda, valor líquido depois de devoluções.
- Exporta os eventos de compra com os mesmos campos.
- Junta pelo número da encomenda.
Os quatro grupos que daí resultam são o diagnóstico. Eventos sem encomenda são disparos duplicados ou tráfego de testes. Encomendas sem evento são bloqueio ou uma etiqueta partida. Pares correspondentes com valores diferentes são o tratamento das moedas, ou um desencontro entre valores com e sem imposto. Pares correspondentes em dias diferentes são fuso horário.
Faz isto uma vez, aponta o resto como percentagem, e ficas com uma coisa muito mais valiosa do que um total que bate certo: uma diferença conhecida e estável. Dois sistemas que discordam sistematicamente em 4% são ambos utilizáveis. Dois sistemas que concordam por coincidência não são.
Onde é que a Skomi se posiciona
A Skomi lê o número da encomenda a partir do order_id, e também a partir do transaction_id do GA, portanto um sítio já etiquetado para o GA4 não precisa de mudar nada. Um evento que traga um número que ela já viu não é contado outra vez.
A receita fica registada com a sua moeda no momento em que é gravada, e a Skomi nunca converte entre moedas: um relatório que cubra duas moedas mostra dois valores, porque o valor único seria uma ficção. Há mais na página do Analytics, e instalar o fragmento cobre o envio do evento.
Há duas definições que fazem aqui a maior parte do trabalho: a receita é atribuída à visita que a gerou e não à página em que foi paga, e a moeda da receita é fixada na receção e nunca convertida.