A tua analítica diz que o sítio fez 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 evento de compra costuma viver 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 lhe é reposta por um navegador que reabre separadores no arranque. 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 redondo 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 desduplicar por ele. 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, é esse o teu defeito.
Vale a pena ser direto quanto ao que errar isto custa. 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 nele.
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 arranjo mais seguro é a moeda ser carimbada 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 com ar de confiante.
3. Devoluções, cancelamentos e cobranças falhadas
A tua base de dados de encomendas é um registo vivo. 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 sozinho pode explicar vários por cento, e é a causa que faz a analítica parecer alta contra um relatório financeiro em vez de contra 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 o teu livro-razão nunca teve.
4. Eventos bloqueados, deitados fora e nunca enviados
Esta desinflaciona sempre, 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 por omissão. 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 corre contra o visitante a fechar 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 imenso 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, casados pelo número da encomenda, ao longo de uma semana limpa.
Se não os conseguires casar pelo número da encomenda, é a causa número 1 outra vez.
5. Os dois sistemas contam momentos diferentes
Por fim, a aborrecida 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 para que o relatório estiver definido. 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 fronteira de mês transforma isso numa diferença real: sempre no mesmo sentido, sempre pequena.
A atribuição acrescenta-lhe ainda mais. 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 baldes que daí saem são o diagnóstico. Eventos sem encomenda são disparos a dobrar ou tráfego de testes. Encomendas sem evento são bloqueio ou uma etiqueta partida. Pares casados com valores diferentes são o tratamento das moedas, ou um desencontro entre valores com e sem imposto. Pares casados 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 por uns coerentes 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 é carimbada com a moeda dela 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 ganhou e não à página em que foi paga, e a moeda da receita é carimbada na receção e nunca convertida.