Porque é que o GA4 não bate certo com as suas encomendas e que parte da diferença se pode recuperar

Abre o relatório de compras do GA4, abre a listagem de encomendas do PrestaShop, e os números não batem certo. Quase sempre o GA4 regista menos. Às vezes, mais. E nas plataformas de anúncios a diferença é ainda maior.

A primeira ideia que convém ter clara: nunca vão coincidir a cem por cento, e não devem. A analítica mede o que o navegador do visitante vê; o back-office regista o que aconteceu de facto. O útil é saber de onde vem cada parte da diferença, qual é legítima e qual é uma falha que se pode corrigir.

Causa 1: o consentimento

Se o seu banner de cookies funcionar como deve, o visitante que recusa a analítica não envia dados completos. Com o Consent Mode v2, a Google recebe sinais sem cookies e pode estimar parte dessas conversões, mas isso é um modelo, não uma contagem.

Esta diferença é legítima: é o preço de cumprir. Nenhuma técnica a deveria contornar. Se alguém lhe prometer «recuperar» compras de quem recusou o seguimento enviando-as na mesma com os seus dados, está a propor-lhe um problema legal.

Causa 2: bloqueadores e navegadores restritivos

Os bloqueadores de anúncios impedem que as etiquetas de analítica e de publicidade sejam carregadas, mesmo que o visitante tenha aceitado os cookies. Alguns navegadores, além disso, encurtam a vida dos cookies definidos pelo navegador, de modo que um visitante que volta dias depois parece novo e a sua compra é mal atribuída.

Esta parte pode ser melhorada respeitando o consentimento: enviando a conversão a partir do seu servidor, que o bloqueador não vê, e guardando os identificadores de campanha num cookie definido pelo servidor.

Causa 3: o cliente não volta da plataforma de pagamento

Em muitas lojas o evento de compra é disparado na página de confirmação. Mas há clientes que pagam na plataforma de pagamento ou na app do banco e nunca voltam à loja: fecham o separador, o telemóvel muda de aplicação, o redirecionamento falha. A encomenda existe, porque a plataforma de pagamento avisou o servidor, mas o GA4 não sabe de nada.

É uma das causas maiores e menos conhecidas. Afeta sobretudo métodos com autenticação fora da página (cartão com verificação na app do banco, pagamentos pelo telemóvel). Só se corrige enviando a compra quando o servidor sabe que a encomenda está paga, e não quando o navegador chega a uma página.

Causa 4: compras a mais

Quando o GA4 regista mais do que o back-office, verifique:

• Recarregamentos da página de confirmação que voltam a disparar a compra.
• Dois módulos ou uma etiqueta do Tag Manager a enviar o mesmo evento.
• Encomendas com pagamento falhado que são contadas ao serem criadas, embora depois não sejam cobradas.
• Navegador e servidor a enviar a mesma compra sem um identificador comum para a plataforma eliminar duplicados.

Causa 5: não está a comparar o mesmo

Antes de procurar falhas técnicas, confirme que compara valores equivalentes:

E os reembolsos: se não os enviar para o GA4, as receitas lá ficam inflacionadas enquanto o back-office já as descontou.

Como fazer a comparação, passo a passo

Para saber quanto perde de facto, faça esta verificação com um período fechado, por exemplo o mês anterior:

1. Extraia do PrestaShop as encomendas pagas do período, sem canceladas nem reembolsadas, com a respetiva referência ou identificador.
2. Extraia do GA4 as transações do mesmo período com o respetivo ID de transação. Se a sua etiquetagem não envia o identificador da encomenda como ID de transação, essa é a primeira correção.
3. Cruze por identificador, não por totais. Os totais escondem compensações: dez compras perdidas e dez duplicadas dão uma diferença de zero.
4. Agrupe as encomendas em falta por método de pagamento e por dispositivo. Se quase todas forem de um método concreto ou do telemóvel, já sabe onde procurar.
5. Agrupe as que estão a mais pelo número de vezes que aparecem: as repetidas apontam para recarregamentos ou etiquetas duplicadas.

Repita a verificação depois de cada alteração na etiquetagem ou nos módulos de pagamento. Uma atualização de um módulo de pagamento que muda a página de retorno pode estragar a medição sem que ninguém dê por isso.

O que o server side traz e o que não traz

Enviar as conversões a partir do servidor da loja (ou de um servidor intermédio) para o GA4, a Meta ou o Google Ads:

• Recupera as compras que se perdem por causa dos bloqueadores e dos clientes que não voltam da plataforma de pagamento.
• Permite enviar a compra quando é cobrada, e não quando se vê uma página.
• Envia também reembolsos e cancelamentos, que o navegador nunca vê.
• Não recupera aquilo que o visitante não consentiu. O servidor tem de respeitar a mesma decisão que o banner.
• Não corrige uma má etiquetagem: se o navegador envia a compra duas vezes sem identificador comum, o servidor só acrescenta uma terceira.

Como resolver isto no PrestaShop

O RKR API Conversions Pro envia as conversões do seu servidor para a Meta, o GA4, o Google Ads, o TikTok e outras plataformas, com o mesmo identificador de evento que o navegador, para que não sejam contadas duas vezes. As compras podem ser enviadas quando a encomenda é cobrada (o que vem por omissão nas instalações novas), e seguem também os reembolsos parciais, os cancelamentos e as encomendas criadas no back-office. Aplica o Consent Mode v2 com o consentimento restaurado antes de carregar as etiquetas, guarda os identificadores de clique num cookie próprio definido pelo servidor, e tem semáforos de estado por plataforma e uma conciliação diária de encomendas. Se não quiser montar nem manter o servidor, o RKR Relay (planos Esencial e Profesional) recebe os eventos assinados pelo módulo e entrega-os a cada plataforma a partir do nosso servidor, com fila, novas tentativas, credenciais cifradas, dados pessoais com hash e o estado de cada entrega visível na loja.