Se você já mexeu em campanhas do Google Ads, provavelmente já passou pela seguinte cena: o Smart Bidding não entrega os resultados esperados e a primeira reação é trocar de estratégia, baixar metas ou brigar internamente sobre qual conversão deveria ser a principal. Mas, muitas vezes, o problema real está lá atrás, na origem: as conversões que alimentam o algoritmo simplesmente não são confiáveis. Não se trata de escolher a conversão errada para otimizar, e sim de saber se o que você está contando de fato corresponde a um usuário real. Quando essa base de dados quebra, o número de conversões continua aparecendo bonitinho no relatório, a campanha parece estar indo bem, mas o algoritmo está sendo treinado com um sinal degradado, distorcido ou incompleto.
Erro 1: dados pessoais mal formatados no hash
As conversões aprimoradas (enhanced conversions) funcionam pegando dados próprios que você coleta, como e-mail ou telefone, transformando isso em hash e comparando com usuários logados no Google. É assim que se recupera conversões que os cookies não conseguem capturar. O problema é que esse hash só funciona se a informação estiver normalizada antes de ser processada.
Você precisa garantir que o e-mail esteja em letras minúsculas e sem espaços em branco antes de gerar o hash. Já o telefone precisa seguir o formato internacional E.164, com código do país e sem pontuação. Se você enviar uma string crua, com espaço sobrando, letras maiúsculas misturadas ou telefone em formato local, o hash até é gerado normalmente, só que fica completamente inútil. O hash de ” João@Exemplo.com ” nunca vai bater com o hash de “joao@exemplo.com”, então a correspondência simplesmente não acontece. E o pior: nada dá erro visível. A conversão continua sendo registrada pelo seu rastreamento padrão, só que sem aquele match aprimorado, deixando sua taxa de correspondência bem abaixo do ideal enquanto tudo parece normal na superfície.
Para identificar esse problema, vale a pena conferir a taxa de correspondência (match rate) no diagnóstico da sua ação de conversão. Se ela estiver muito abaixo do que o Google costuma indicar como padrão, desconfie primeiro de um problema de normalização. Uma boa prática é enviar uma conversão de teste com um endereço logado conhecido e verificar se o match acontece de fato.
Erro 2: modo de consentimento configurado errado
Se você atua com público no Espaço Econômico Europeu, Reino Unido ou Suíça, sabe que os dados de conversões aprimoradas passam pelo Consent Mode. A falha mais comum aqui não é a tag deixar de disparar — é que os parâmetros ad_user_data e ad_personalization nunca foram mapeados corretamente para “concedido” no momento em que o usuário aceita, então os sinais que autorizam o match ficam ausentes mesmo quando houve consentimento. O Google verifica isso em tempo real e, sem essa configuração, simplesmente não libera a chave de correspondência.
Vale diferenciar: o Consent Mode básico é um problema menor, porque ele ainda mede integralmente o usuário que consentiu. O que você perde ali são os dados de quem recusou, além da qualidade da modelagem. Já o Consent Mode avançado resolve melhor a recuperação de dados, mas ocupa um espaço bem controverso do ponto de vista de privacidade: mesmo sem consentimento, um ping ainda é disparado, sem armazenar cookies, mas carregando tipo de navegador, tipo de dispositivo, país, URL da página e campos que você mesmo configura, como ID do pedido e valor da conversão — tudo isso alimenta uma modelagem agregada que só fica visível quando você ultrapassa os limites de dados do Google.
Se esse tipo de payload é uma anonimização limpa ou ainda é dado sendo enviado sem consentimento explícito é exatamente o que profissionais da área discutem até hoje. Como responsável pelos dados, a responsabilidade pelo processamento do Google recai sobre você de qualquer forma. Essa não é uma decisão para tomar sozinho só porque melhora sua taxa de match — é uma conversa que precisa envolver quem cuida de privacidade no seu negócio ou no do seu cliente.
Existe ainda uma armadilha mais sutil, que pega até configurações aparentemente corretas: o status de consentimento nem sempre é atualizado no instante em que o usuário clica em aceitar. Em algumas implementações, essa atualização só acontece no próximo carregamento de página. Ou seja, a conversão que dispara na página atual — justamente a compra ou o lead que o usuário acabou de concluir — sai registrada com o status anterior ao consentimento. O banner registrou o aceite, mas a conversão mais importante já tinha saído antes do sinal “concedido” chegar.
Tem também um fator que está acima de tudo isso: a taxa de consentimento em si não é fixa. O layout do banner, o texto usado e como as opções de aceitar e recusar são apresentadas mudam bastante a taxa de aceitação — e, na União Europeia, essa é frequentemente a maior limitação de quantos dados chegam até o Smart Bidding. De nada adianta uma configuração tecnicamente perfeita se 40% dos usuários recusam o banner: você continua trabalhando com apenas 60% do seu tráfego. Melhorar o banner costuma ser uma alavanca maior do que qualquer ajuste técnico, mas é algo que muita gente trata como resolvido só porque o jurídico aprovou uma vez.
Para checar isso, confirme qual versão do Consent Mode você está rodando — avançado ou básico — e se os sinais de consentimento realmente mudam para “concedido” após o aceite. Depois, teste especificamente o timing: aceite o consentimento e complete uma conversão na mesma sessão de página, verificando se o sinal “concedido” já está ativo antes da conversão disparar, e não só depois de uma nova navegação. Essa lacuna de tempo é o detalhe que sobrevive mesmo em configurações aparentemente corretas.
Erro 3: valor de conversão que não bate com o que foi vendido
Esse problema é específico de quem trabalha com Target ROAS e talvez seja o mais direto financeiramente entre todos. Se o valor enviado junto com a conversão não reflete o que o cliente realmente pagou, o Target ROAS está otimizando em cima de uma ficção. As causas mais comuns são um valor fixo cadastrado quando, na prática, as transações variam, ou moedas enviadas de forma inconsistente, misturando denominações diferentes na mesma coluna.
Para quem trabalha com e-commerce, a maior armadilha é a questão de valor bruto versus líquido, e se o frete está incluído no número. Isso pode parecer só uma preferência de relatório, mas não é — isso muda diretamente quais clientes o Smart Bidding vai considerar valiosos.
Pense em dois pedidos que aparecem com o mesmo valor de R$ 200. Um é uma venda a preço cheio. O outro é majoritariamente de itens com desconto, que ainda vão gerar devolução parcial. Se você trabalha com valor bruto, o algoritmo trata os dois como idênticos e passa a buscar mais clientes parecidos com o segundo caso. O frete funciona do mesmo jeito: um pedido com R$ 15 de frete embutido no valor acaba “vencendo” outro pedido idêntico com frete grátis, mesmo esse valor sendo um custo para você, não margem.
O ideal é trabalhar com receita líquida e sem frete embutido, porque isso fica mais próximo da margem que realmente sobra no seu bolso. Você até pode optar por valor bruto com frete incluso e o Smart Bidding vai otimizar de forma consistente mesmo assim — mas, a partir daí, todo cálculo posterior, seu ROAS real, sua meta de equilíbrio, suas comparações entre canais, precisa ser refeito para tirar o que foi embutido a mais. Na prática, poucos times fazem esse ajuste, então o desempenho relatado vai se distanciando do dinheiro que realmente entra no caixa, sem que ninguém tenha decidido isso conscientemente.
Existe também uma questão de tempo envolvida. O valor que estava certo no momento da compra deixa de ser correto quando o cliente devolve parte do pedido ou cancela tudo. Se você nunca atualiza esse dado, o Smart Bidding continua tratando um pedido de R$ 200 que virou R$ 140 como uma venda completa, e segue buscando clientes parecidos com uma devolução que você já teve prejuízo. É aqui que entram os ajustes de conversão: você pode reduzir o valor em caso de devolução parcial ou retirar completamente a conversão em caso de cancelamento. Para negócios com taxa de devolução relevante, uma conta sem esses ajustes está, na prática, treinando o algoritmo para atrair justamente os piores clientes possíveis.
Depois de garantir que o valor está líquido e correto, o próximo passo é pensar em lucro de fato — usando dados de carrinho nas conversões, que mostram o que realmente foi vendido por pedido, combinados com um feed de custo de mercadoria vendida no Merchant Center.
Com informações de searchenginejournal.com.
