Enhanced Conversions do Google Ads: o que é e como implementar sem perder correspondência

A mensuração de conversão baseada apenas em cookies de navegador vem perdendo confiabilidade de forma estrutural. Bloqueio de cookies de terceiros, restrições de armazenamento em navegadores, extensões de privacidade e, sobretudo, a exigência legítima de consentimento fazem com que uma parcela crescente das conversões reais nunca seja atribuída à campanha que as gerou. O resultado prático é conhecido de qualquer pessoa que opera mídia paga: você sabe que houve venda ou lead, mas a plataforma de anúncios não consegue casar aquele evento com o clique que o originou. Sem essa correspondência, o algoritmo de lances otimiza com dados parciais e o retorno reportado subestima o real.

O Enhanced Conversions (Conversões Otimizadas, na tradução do Google Ads) é a resposta do Google a esse problema. Em vez de depender só do identificador de clique guardado num cookie, ele usa dados first-party que o próprio usuário forneceu — e-mail, telefone, nome, endereço — enviados de forma hasheada e segura para reforçar a atribuição. Este guia explica o que é o recurso, como a correspondência funciona por baixo, os modos disponíveis, os caminhos de implementação e as boas práticas de normalização, hashing e consentimento que separam uma integração que funciona de uma que silenciosamente descarta seus dados.

O problema que o Enhanced Conversions resolve#

Toda conversão no Google Ads tradicional depende de amarrar dois pontos: o clique no anúncio e o evento de conversão no site. Essa amarração é feita historicamente pelo GCLID (Google Click Identifier), gravado num cookie first-party quando o usuário chega pelo anúncio, e lido de volta quando ele converte. O elo quebra em várias situações comuns: o usuário não deu consentimento para cookies de marketing; o cookie expirou ou foi apagado entre a visita e a compra; a conversão acontece em outro dispositivo ou em outro navegador; ou o caminho passa por um ambiente onde o script de conversão não roda de forma confiável.

Quando o elo quebra, a conversão vira o que se chama de conversão não observada. Ela aconteceu, gerou receita, mas não entra na conta que a campanha reporta. Ao longo de milhares de eventos, essa perda distorce o CPA e o ROAS aparentes e, pior, priva os algoritmos de Smart Bidding de sinal de treino. Lances automáticos aprendem com conversões; conversões faltantes empobrecem o modelo e reduzem a eficiência de toda a conta.

O Enhanced Conversions ataca isso adicionando um segundo caminho de correspondência. Além do GCLID, ele envia dados de identificação que o usuário digitou no seu próprio formulário — os chamados user-provided data. O Google recebe esses dados já transformados em hash irreversível e tenta casá-los com contas Google que estavam logadas quando viram ou clicaram no anúncio. Onde o cookie falhou, a correspondência por dados first-party pode recuperar a conversão.

O que são, de fato, Enhanced Conversions#

Enhanced Conversions é um recurso que complementa suas tags de conversão existentes. Ele não substitui a tag de conversão nem o GCLID; soma a eles. A tag continua disparando como sempre, e o recurso anexa a esse disparo um pacote de dados de identificação do usuário, normalizado e hasheado, para melhorar a taxa de correspondência.

O ponto conceitual central é a correspondência (matching). O Google mantém a associação entre contas Google logadas e as impressões e cliques de anúncios servidos a elas. Quando você envia um e-mail hasheado junto da conversão, o Google aplica o mesmo hash sobre os e-mails das contas que interagiram com seus anúncios e procura por igualdade entre os hashes. Havendo correspondência, a conversão é creditada ao clique correspondente. Como a comparação é feita entre hashes, o Google nunca precisa ver o dado em texto claro para casar os registros — e você nunca envia o dado em claro.

Vale reforçar o que isso não é. Não é envio de listas de clientes para segmentação. Não é rastreamento cross-site por cookies de terceiros. É reforço de atribuição de eventos que já pertencem à sua propriedade, usando dado que o usuário entregou a você numa relação direta.

Os modos: "for web" e "for leads"#

Existem dois modos, e escolher o certo importa.

Enhanced Conversions for web é para conversões que acontecem no seu site — uma compra, um cadastro concluído, um formulário enviado. Os dados first-party são capturados na própria página, no momento da conversão, geralmente a partir dos campos que o usuário acabou de preencher, e enviados junto do evento. É o modo que melhora a atribuição das conversões online já existentes.

Enhanced Conversions for leads é para o ciclo de geração de leads que se fecha offline ou fora do site. O usuário preenche um formulário; você captura e hasheia o e-mail dele; mais tarde, quando o lead vira cliente no seu CRM, você faz o upload da conversão offline usando aquele mesmo e-mail hasheado como chave. O Google casa o e-mail do upload com o e-mail capturado no envio do formulário, e este com o clique. É o mecanismo que fecha a malha entre o clique no anúncio e uma venda que só acontece dias depois, por telefone ou no balcão, sem depender de GCLID armazenado.

Em resumo: "for web" reforça a conversão que ocorre na página; "for leads" liga a conversão offline de volta ao lead original pelo dado hasheado.

Como funciona a correspondência com dados hasheados#

A mecânica tem três etapas. Primeiro, você coleta os dados de identificação — tipicamente e-mail e/ou telefone, e opcionalmente nome, sobrenome, país e CEP. Segundo, você normaliza cada campo segundo regras fixas e aplica SHA-256. Terceiro, você envia os hashes junto do evento de conversão.

Do lado do Google, o mesmo processo de normalização e hashing é aplicado aos dados de identidade das contas Google que estavam logadas ao serem expostas aos seus anúncios. A comparação acontece hash contra hash. Como SHA-256 é determinístico, o mesmo e-mail normalizado sempre produz o mesmo hash; e como é irreversível na prática, o hash não revela o dado original. Por isso a normalização precisa ser idêntica dos dois lados: qualquer diferença — um espaço, uma maiúscula, um ponto a mais — produz um hash diferente e a correspondência simplesmente não acontece. Uma integração que normaliza mal não dá erro; ela apenas casa menos, silenciosamente.

Endereço de e-mail e número de telefone são os identificadores mais fortes por serem únicos e estáveis. Nome e endereço postal ajudam como sinais adicionais, mas isolados têm poder de correspondência baixo. A recomendação prática é priorizar e-mail, incluir telefone quando disponível em formato E.164, e adicionar os demais campos apenas como reforço.

Métodos de implementação#

Há três caminhos, e eles não são mutuamente exclusivos. A escolha depende de onde você tem controle sobre o dado e sobre o hashing.

Via Google Tag (gtag.js)#

No caminho gtag, você fornece os dados do usuário à tag antes de o evento de conversão disparar. A forma recomendada é passar os dados via set com a chave user_data, deixando o hashing a cargo do próprio gtag quando os dados vão em texto claro por um canal seguro, ou enviando você mesmo os campos já hasheados. O exemplo abaixo mostra o pacote de user-provided data que acompanha a conversão:

```javascript // Fornece os dados do usuário à Google Tag antes do evento de conversão. // Os campos vêm dos inputs que o usuário acabou de preencher no formulário. gtag('set', 'user_data', { 'email': 'usuario@exemplo.com', 'phone_number': '+5511998877665', // E.164, com código do país 'address': { 'first_name': 'maria', 'last_name': 'silva', 'street': 'rua das flores 123', 'city': 'sao paulo', 'region': 'sp', 'postal_code': '01001000', 'country': 'BR' } });

// A tag de conversão dispara normalmente; o pacote acima é anexado a ela. gtag('event', 'conversion', { 'send_to': 'AW-CONVERSION_ID/CONVERSION_LABEL', 'value': 199.90, 'currency': 'BRL', 'transaction_id': 'pedido-000123' // deduplica a conversão }); ```

Quando os dados trafegam em claro até o gtag, eles são hasheados no navegador antes de sair. Ainda assim, muitas equipes preferem hashear na origem — sobretudo em contextos server-side — para que o dado em claro nunca deixe o servidor.

Via Google Tag Manager#

No GTM, o recurso é ativado na própria tag de conversão do Google Ads, habilitando a seção de conversões otimizadas e apontando de onde vêm os dados do usuário. Há duas formas de fornecer o dado: seleção manual, em que você mapeia variáveis do GTM para cada campo (e-mail, telefone, etc.), ou a leitura automática a partir do código da página quando os campos estão acessíveis no DOM ou na camada de dados. O GTM cuida da normalização e do hashing. A recomendação sólida é alimentar os campos por variáveis da camada de dados (data layer) populadas de forma controlada, em vez de depender de heurística de leitura do DOM, que é frágil a mudanças de layout.

Via Google Ads API / server-side#

O caminho server-side é o mais robusto para qualidade de dado e privacidade, e é o natural para o modo "for leads" e para conversões offline. Aqui você mesmo normaliza e hasheia os identificadores no backend e envia os eventos pela Google Ads API (ou por upload de conversões offline). O dado em claro nunca sai do seu servidor; só o hash trafega. Esse modelo também facilita governança de consentimento e retenção, porque tudo passa por um ponto único de controle no seu ambiente. É o equivalente, no ecossistema Google, ao envio de eventos de servidor que você faz para outras plataformas.

Requisitos de dados e consentimento#

O recurso só é legítimo com base legal para tratar os dados de identificação com finalidade de mensuração de publicidade. Isso significa consentimento válido do usuário onde ele for exigido, política de privacidade transparente sobre o uso desses dados e respeito às regras da plataforma quanto a que dados podem ser enviados. Nunca envie dado de identificação sem base legal, e nunca envie dado de categorias sensíveis.

Dois pontos técnicos de qualidade merecem atenção. Primeiro, envie o transaction_id (ou identificador de pedido equivalente) sempre que possível: ele deduplica a mesma conversão quando ela chega por mais de um caminho, evitando contagem dobrada. Segundo, colete o dado no momento em que ele é mais confiável — o e-mail digitado no checkout ou no formulário — e não valores derivados ou inferidos.

Normalização e hashing SHA-256 na prática#

A normalização é a parte que mais quebra na prática, porque erros nela não geram falha visível, apenas correspondência baixa. As regras essenciais: remover espaços em branco no início e fim; converter para minúsculas; para telefone, usar o formato E.164 (+ seguido de código do país e número, sem espaços, hífens ou parênteses); para e-mail, aparar espaços e usar minúsculas. Só depois de normalizar é que se aplica SHA-256, e o hash é representado em hexadecimal minúsculo. O exemplo abaixo mostra a normalização e o hashing de um e-mail e de um telefone:

```javascript const crypto = require('crypto');

// Normaliza e-mail: apara espaços e força minúsculas antes do hash. // Onde: chamada na borda do servidor, antes de montar o evento de conversão. function hashEmail(raw) { const normalized = raw.trim().toLowerCase(); return sha256Hex(normalized); }

// Normaliza telefone para E.164 (só dígitos com prefixo do país) e hasheia. // Onde: mesma borda; assume que o país foi validado no formulário. function hashPhoneE164(raw, countryCode = '55') { let digits = raw.replace(/\D/g, ''); // remove tudo que não é dígito digits = digits.replace(/^0+/, ''); // tira zeros à esquerda if (!raw.trim().startsWith('+')) { digits = countryCode + digits; // garante o código do país } return sha256Hex('+' + digits); }

// Aplica SHA-256 e devolve hexadecimal minúsculo — o formato esperado. function sha256Hex(value) { return crypto.createHash('sha256').update(value, 'utf8').digest('hex'); }

// Exemplo de uso: // hashEmail(' Usuario@Exemplo.com ') -> hash do e-mail normalizado // hashPhoneE164('(11) 99887-7665') -> hash de +5511998877665 ```

A regra de ouro: normalize dos dois lados exatamente igual. Se o Google normaliza o e-mail para minúsculas e sem espaços, e você envia com uma maiúscula ou um espaço remanescente, os hashes divergem e a conversão não casa. Padronize a normalização num único ponto de código e reutilize-o em todos os caminhos de envio para não haver divergência entre, por exemplo, o web e o upload offline.

Relação com conversões offline e Consent Mode#

Enhanced Conversions e conversões offline são complementares, não concorrentes. As conversões offline tradicionais dependem de capturar o GCLID no momento do lead e carregá-lo de volta quando a venda fecha. O modo "for leads" resolve o caso em que você não tem o GCLID guardado, usando o e-mail hasheado como chave de reconciliação. Na prática, uma operação madura usa ambos: GCLID quando disponível e dados hasheados como rede de segurança.

O Consent Mode é a peça que orquestra tudo isso sob consentimento. Ele sinaliza ao Google o estado de consentimento do usuário para armazenamento de anúncios e de analytics, e ajusta o comportamento das tags conforme esse estado. Quando o consentimento para armazenamento de anúncios é negado, cookies não são gravados, mas o Google ainda pode usar modelagem para estimar conversões. Enhanced Conversions opera dentro dessa lógica de consentimento: o envio de dados de identificação deve respeitar o estado sinalizado, e a combinação de Consent Mode bem configurado com Enhanced Conversions é o que permite manter mensuração útil sem violar a escolha do usuário. Configure o Consent Mode antes ou junto do Enhanced Conversions; não trate um como substituto do outro.

Comparação conceitual com a Meta CAPI#

Quem já trabalhou com a Conversions API da Meta reconhece o padrão imediatamente. A CAPI envia eventos do servidor para a Meta com identificadores de usuário hasheados (e-mail, telefone, e outros) para melhorar a correspondência de eventos que o pixel do navegador perderia. O Enhanced Conversions faz o mesmo movimento conceitual dentro do ecossistema Google: complementar o sinal do navegador com dados first-party hasheados enviados de forma mais confiável, para recuperar atribuição perdida pela erosão dos cookies.

As diferenças estão nos detalhes de implementação — nomes de campos, chaves de deduplicação, formato de payload e a chave de correspondência (a Meta casa contra usuários da plataforma; o Google, contra contas Google logadas). Mas a intuição transfere direto: normalizar bem, hashear com o algoritmo esperado, deduplicar por um identificador de transação e respeitar consentimento valem nos dois mundos. Se você já domina a CAPI, o Enhanced Conversions é a mesma disciplina aplicada a outra plataforma.

Como validar a implementação#

Implementar sem validar é enviar às cegas. Alguns passos práticos de verificação: confira, nas ferramentas de diagnóstico da tag de conversão do Google Ads, se o status de conversões otimizadas indica dados sendo recebidos e correspondidos. Verifique no console do navegador ou no modo de visualização do GTM se o pacote de user-provided data está sendo montado antes do disparo do evento de conversão, e não depois. Inspecione o payload para garantir que os campos vão hasheados quando devem ir, e que a normalização foi aplicada — um e-mail com maiúscula no payload é sinal de bug.

Para o modo "for leads", faça um teste ponta a ponta: submeta um formulário com um e-mail conhecido, complete a conversão offline com o mesmo e-mail e confirme a correspondência. Acompanhe, ao longo dos dias seguintes à ativação, se a taxa de correspondência reportada sobe e se o volume de conversões atribuídas aumenta em relação ao baseline. Uma queda ou estagnação inesperada normalmente aponta para normalização inconsistente entre caminhos — o ponto único de código para normalizar e hashear existe justamente para eliminar essa classe de erro.

Fechando a malha#

Enhanced Conversions não é um truque de última hora contra o fim dos cookies; é a forma correta de sustentar mensuração num mundo em que o navegador guarda cada vez menos estado e o consentimento manda. A lógica é direta: use o dado first-party que o usuário lhe entregou de boa-fé, trate-o com respeito — hash irreversível, consentimento, normalização rigorosa — e devolva à plataforma o sinal de que ela precisa para otimizar. Feito com disciplina de normalização e um caminho server-side onde a qualidade importa, o recurso recupera conversões que hoje você perde e devolve aos seus lances o combustível de que eles dependem para aprender.