Sua tag de conversão do Google Ads dispara quando uma compra acontece — exceto quando não dispara. O Intelligent Tracking Prevention do Safari encurta a vida dos cookies, bloqueadores de anúncio removem a tag por completo, banners de consentimento a suprimem, e o cliente que clica no celular e compra no notebook parece dois estranhos sem relação. O clique aconteceu. A venda aconteceu. O relatório não mostra nada — e os Lances inteligentes, que aprendem com esse relatório, passam a otimizar sobre um retrato incompleto da realidade.
As conversões otimizadas (Enhanced Conversions) são a resposta do Google para esse buraco. Este guia cobre o que elas são, o que recuperam, a diferença entre web e leads, quais dados saem do seu site e os dois caminhos de configuração — para você escolher o certo, não o mais fácil.
O Que São as Conversões Otimizadas, de Fato
Conversões otimizadas são um complemento à sua tag de conversão, não um substituto. A tag continua disparando como sempre disparou. Em paralelo, você envia ao Google um dado próprio (first-party) que o cliente já entregou a você — em geral, o e-mail digitado no checkout ou num formulário de lead — transformado em hash SHA-256 antes de sair da sua página ou do seu servidor.
O Google pega esse hash e o compara com a lista de hashes das contas Google conectadas. Se o cliente estava logado quando clicou no seu anúncio, a correspondência reconecta a conversão ao clique, mesmo quando o cookie que faria essa ponte já desapareceu faz tempo.
A propriedade central: é um dado que o cliente entregou de propósito, numa transação com você. As conversões otimizadas não coletam nada novo — elas mudam o destino de um campo que você já tem (documentação do Google).
Onde Suas Conversões Somem
Quatro vazamentos drenam a mensuração baseada em tag, e eles se acumulam:
- Restrições de cookies nos navegadores. O Safari limita a vida dos cookies criados após cliques em anúncios. Quem clica na segunda-feira e compra na semana seguinte pode voltar sem cookie nenhum para atribuir.
- Bloqueadores de anúncio e proteção contra rastreamento. Se o
gtag.jsnunca carrega, a conversão nunca é reportada, com ou sem cookie. - Banners de consentimento. O visitante que recusa o rastreamento suprime a tag na sessão inteira — inclusive na compra do final dela.
- Jornadas entre dispositivos. Clique no celular, compra no desktop. Cookies vivem por dispositivo; a conta Google logada é a única ponte.
O estrago não é só um número menor no painel. Como conta ilustrativa — não um benchmark — imagine que suas campanhas geram 100 conversões reais e a tag enxerga só 80. Seu CPA reportado parece 25% pior do que a realidade, e os Lances inteligentes reduzem lances em campanhas que eram lucrativas. Dado faltando não fica neutro: ele direciona orçamento para o lugar errado.
Web vs. Leads: Um Nome, Dois Produtos Diferentes
O Google entrega duas variantes sob o mesmo rótulo, e confundi-las custa uma semana de configuração:
| Conversões otimizadas para web | Conversões otimizadas para leads | |
|---|---|---|
| Problema que resolve | Conversões online que a tag perdeu | Vendas offline fechadas no seu CRM |
| Conversão acontece | No seu site, na sessão ou depois | Dias ou semanas depois — ligação, contrato |
| Dado capturado em | Página de conversão (e-mail do checkout) | Envio do formulário de lead (e-mail/telefone) |
| O que substitui | Mensuração degradada por cookies | Importações offline baseadas em GCLID |
| Usuário típico | E-commerce, SaaS self-service | Geração de leads, B2B, ticket alto |
Web é o que a maioria dos anunciantes quer dizer: a compra acontece no site, a tag pode perdê-la, e o e-mail em hash recupera a atribuição. Leads inverte o fluxo: você captura o e-mail em hash no envio do formulário e, quando aquele lead vira receita no CRM semanas depois, reporta a venda de volta usando o e-mail como chave de junção — sem ginástica de planilha com GCLID.
Se a sua receita cai num checkout, você quer a versão web. Se cai num CRM depois que um humano fala com o lead, você quer a versão para leads. Alguns negócios precisam legitimamente das duas.
O Que É Enviado, Exatamente
O payload é mais estreito do que a maioria das revisões de privacidade espera:
- E-mail — em minúsculas, sem espaços, e então transformado em hash SHA-256. É a chave principal de correspondência.
- Telefone — normalizado para o formato E.164 (
+5511...) e então em hash. - Nome e endereço — opcionais, em hash campo a campo, usados para melhorar a taxa de correspondência quando o e-mail sozinho é fraco.
O hash acontece antes da transmissão — no navegador, nas configurações via tag; no seu servidor, nas configurações via API. O Google recebe o hash, não o texto puro. Um hash que não bate com nenhuma conta Google não atribui nada.
Duas ressalvas honestas. Primeira: hash não é anonimização — o Google consegue fazer a correspondência justamente porque tem os mesmos e-mails do lado dele; esse é o mecanismo inteiro. Segunda: o envio ainda exige base legal — sua política de privacidade precisa cobrir o compartilhamento de dados de clientes em hash com plataformas de anúncio, e seu gerenciamento de consentimento precisa condicioná-lo onde LGPD e GDPR se aplicam. Estar em hash não significa estar isento.
Dois Caminhos de Configuração: Tag vs. API
Via tag é a pista rápida. No Google Ads ou no Google Tag Manager, você ativa as conversões otimizadas na ação de conversão e deixa a detecção automática encontrar o campo de e-mail na página, ou o mapeia manualmente com seletores CSS ou uma variável de dataLayer. Dá para estar no ar numa tarde. A fragilidade é estrutural: um redesign do checkout que renomeia um campo quebra a captura em silêncio, e nada avisa.
Via API (server-side, pela Google Ads API) significa que o seu backend envia os dados em hash depois que o pedido foi de fato confirmado. É mais engenharia — e é melhor em tudo que importa em escala: sobrevive a redesigns, funciona quando o checkout mora em outro domínio, permite enviar só pedidos pagos em vez de tentativas, e dá um lugar para tratar reembolsos. Esse padrão server-side — pedidos verificados vindos dos webhooks do seu próprio checkout, devolvidos à plataforma — é a arquitetura que o Decisa usa para o pushback de conversões, porque o pedido que o seu provedor de pagamento confirmou é um sinal estritamente melhor do que o que uma tag de navegador conseguiu observar.
Regra prática: via tag para validar o valor rápido, via API como destino final.
Configure Ainda Esta Semana
- Escolha a variante — web para checkout no site, leads para receita fechada no CRM.
- Ative na ação de conversão no Google Ads e aceite os termos de dados de clientes.
- Conecte o dado — mapeie o campo de e-mail na configuração da tag, ou faça o backend enviar os dados em hash via API na confirmação do pedido.
- Confira a guia de diagnóstico da ação de conversão depois de alguns dias; ela mostra se o Google está recebendo e correspondendo seus dados.
- Atualize a política de privacidade e o fluxo de consentimento para que o compartilhamento em hash esteja divulgado e devidamente condicionado.
Conversões otimizadas não vão fazer seu painel bater com seu extrato bancário — só atribuição first-party faz isso. O que elas fazem é impedir que o algoritmo de lances do Google voe meio cego por causa de conversões que os navegadores engoliram. Alimente-o com a verdade, e ele gasta o seu dinheiro visivelmente menos errado.