Offline Conversions no Google Ads: otimize para vendas

A maioria das campanhas B2B no Google Ads é otimizada para o evento errado. O formulário preenchido aparece como conversão, o Smart Bidding aprende com aquele sinal e passa a buscar mais formulários, independentemente de quantos viram receita. Offline conversions existem para corrigir exatamente esse desalinhamento: conectar o clique no anúncio ao desfecho real da venda.

Por que otimizar para leads cria um problema estrutural

Quando o Smart Bidding recebe apenas eventos de preenchimento de formulário, ele trata todos eles como equivalentes. Um lead de um estudante fazendo pesquisa acadêmica pesa o mesmo que um VP de compras em fase de avaliação ativa. O algoritmo não tem como distinguir, a menos que você o ensine.

O efeito prático é previsível: a campanha encontra o caminho de menor resistência, que costuma ser o que gera mais volume, não mais qualidade. Escalar verba nessa configuração aumenta o custo por lead sem aumentar o custo por cliente, e os relatórios de marketing passam a mostrar um desempenho que não se reflete em pipeline.

A solução não é de configuração de anúncio nem de criativo. É de sinal de otimização. O Smart Bidding precisa aprender com os eventos que realmente importam para o negócio, e esses eventos acontecem fora do Google Ads, dentro do CRM.

A arquitetura de identificação de cliques: GCLID, GBRAID e WBRAID

Para importar uma conversão offline, o Google precisa saber a qual clique ela pertence. Três identificadores cumprem esse papel, cada um em um contexto diferente.

GCLID (Google Click ID) é o identificador padrão. Ele é adicionado automaticamente à URL de destino toda vez que alguém clica em um anúncio, desde que o auto-tagging esteja ativo na conta. O GCLID é armazenado no CRM via campo oculto no formulário, e depois enviado de volta ao Google junto com o evento de conversão. O Google mantém o GCLID por 90 dias, depois disso o upload falha.

GBRAID é um identificador de preservação de privacidade criado para dois cenários: sites com deep links medindo conversões em app originadas de campanhas web, e situações em que o GCLID está em risco de ser descartado, principalmente em tráfego do YouTube, Gmail e Google Discover. O GBRAID mede conversões de forma não individual, sem vincular dados a usuários específicos. Atenção: ele é sensível a maiúsculas e minúsculas. Qualquer normalização de texto que converta o parâmetro para minúsculas no backend vai corromper o valor antes do upload.

WBRAID aparece quando o usuário clica em um anúncio em um app iOS e é direcionado para uma página web. É o parâmetro que preenche a lacuna deixada pelas restrições do App Tracking Transparency da Apple em jornadas web-to-web no ecossistema iOS.

A recomendação prática, especialmente em ambientes com restrições de cookies, é capturar os três identificadores em campos ocultos separados no formulário e armazenar todos eles no registro do lead no CRM. Quando o GCLID não sobrevive à jornada do usuário, o GBRAID pode ser o único vínculo com o clique original.

Onde armazenar os identificadores

• Adicione campos ocultos no formulário para GCLID, GBRAID e WBRAID.
• Use localStorage (com janela de 90 dias) para persistir os valores entre páginas, especialmente em jornadas de múltiplas sessões.
• Mapeie esses campos para o CRM no momento do envio do formulário, garantindo que o registro do lead carregue os três valores desde a criação.
• Nunca converta os valores para maiúsculas ou minúsculas no processamento do formulário ou na integração com o CRM.

Como funciona o fluxo de importação: do clique ao CRM ao Google Ads

O fluxo de importação de conversões offline tem quatro etapas. Cada uma pode ser um ponto de falha silenciosa.

1. Captura do identificador no clique: o usuário clica no anúncio, o Google anexa o GCLID (e possivelmente GBRAID ou WBRAID) à URL. O script da página lê o parâmetro e o salva em localStorage e no campo oculto do formulário.
2. Armazenamento no CRM: quando o formulário é enviado, o GCLID é gravado no registro do lead junto com e-mail e telefone. Esses dados de primeiro partido serão usados como chave de correspondência alternativa nas Enhanced Conversions for Leads.
3. Mudança de estágio no CRM: quando o lead avança no funil (MQL, SQL, Oportunidade, Closed Won), o CRM registra o evento com timestamp.
4. Upload para o Google Ads: o GCLID, o nome da ação de conversão, o valor e o timestamp são enviados ao Google via Data Manager, conector nativo (HubSpot, Salesforce) ou API.

Um ponto que gera erros frequentes: não tente subir a conversão imediatamente após o lead ser gerado. O Google precisa de algumas horas para indexar o GCLID. Um upload feito muito cedo retorna erro CLICK_NOT_FOUND mesmo quando o identificador está correto.

Enhanced Conversions for Leads: por que é o caminho recomendado em 2026

O Google passou a tratar o import baseado apenas em GCLID como abordagem legada. A versão atual, Enhanced Conversions for Leads, acrescenta dados de primeiro partido hasheados (e-mail e telefone em SHA-256) como segunda chave de correspondência. Quando o GCLID se perde ao longo da jornada, o dado hasheado ainda pode fazer o match com o usuário que converteu.

Outra mudança relevante de 2026: a partir de abril deste ano, o Google passou a aceitar dados de primeiro partido simultaneamente via tag do site, Data Manager e API. Não é mais preciso escolher um único método de implementação. E desde junho de 2026, o endpoint UploadClickConversions da Google Ads API foi descontinuado para integrações customizadas. O caminho correto agora é o Data Manager API.

Como mapear estágios do funil como ações de conversão separadas

Usar uma única ação de conversão para todo o funil desperdiça o potencial de aprendizado do algoritmo. A prática recomendada é criar uma ação de conversão distinta para cada estágio relevante, com valores monetários diferentes.

Um exemplo de mapeamento para empresas B2B com ciclo de vendas longo:

• MQL (Lead Qualificado pelo Marketing): lead que passou por critérios de qualificação do CRM. Valor exemplo: R$ 150.
• SQL (Lead Qualificado por Vendas): lead aceito pelo time comercial para abordagem ativa. Valor exemplo: R$ 600.
• Oportunidade Aberta: proposta em andamento ou demo realizada. Valor exemplo: R$ 1.500.
• Closed Won: negócio fechado. Valor: ticket real ou ticket médio histórico.

Por que definir valores em cada estágio importa? Porque o Smart Bidding otimiza para o valor esperado da conversão, não apenas para o volume. Um lead que historicamente tem 20% de chance de virar um contrato de R$ 10.000 vale R$ 2.000 no momento em que é qualificado como SQL. Sem esse sinal, o algoritmo trata todos os SQLs como equivalentes a qualquer outro evento de formulário.

Outra razão prática: ciclos de vendas B2B costumam ultrapassar 60 ou 90 dias. Esperar o Closed Won para enviar o primeiro sinal ao Google significa que o algoritmo fica sem feedback por semanas, o que compromete a capacidade do Smart Bidding de ajustar lances em tempo útil. Subir eventos intermediários de funil resolve esse problema.

Value-Based Bidding: como configurar tROAS com dados de funil

Com valores atribuídos a cada estágio de funil, é possível migrar de uma estratégia orientada a volume (Maximizar Conversões, tCPA) para uma orientada a valor (Maximizar Valor de Conversão, tROAS). A lógica muda: em vez de pagar um custo fixo por lead, você instrui o algoritmo a buscar cliques com maior retorno esperado sobre o investimento em mídia.

Dois requisitos de volume precisam ser respeitados para que a estratégia funcione:

• tCPA: mínimo de 30 conversões offline por mês para o algoritmo estabilizar.
• tROAS: mínimo de 50 conversões offline por mês. Abaixo desse volume, o algoritmo não tem sinal suficiente e pode se comportar de forma instável.

Um framework para calcular o valor proxy de cada estágio:

Valor do estágio = Taxa de fechamento histórica × Ticket médio × Probabilidade de avanço nesse estágio

Exemplo: se 15% dos SQLs viram contratos com ticket médio de R$ 20.000, o valor proxy de um SQL é R$ 3.000. Esse número não precisa ser exato; precisa refletir a ordem de grandeza correta para que o algoritmo priorize os segmentos certos.

Uma ressalva importante: não ative o tROAS antes de ter pelo menos um ciclo completo de conversões offline importadas. O algoritmo precisa de dados históricos para calibrar as previsões de valor. Ativar o tROAS com dados insuficientes costuma resultar em contração de volume sem melhora proporcional de qualidade.

Erros comuns que quebram a atribuição sem avisar

A maioria das implementações de offline conversions falha silenciosamente. Os relatórios continuam rodando, as campanhas continuam gastando, mas os sinais enviados ao Google estão incompletos ou errados. Os erros mais frequentes:

• GCLID não capturado no formulário: o campo oculto existe, mas o script de captura não está ativo em todas as páginas ou não funciona em dispositivos móveis com determinados construtores de formulário. Resultado: leads chegam ao CRM sem GCLID e o upload falha para esses registros. Taxa de match abaixo de 50% é um indicador desse problema.
• GCLID corrompido por normalização de texto: o CRM ou o middleware converte o valor para minúsculas como "higiene" automática. Como GCLID e GBRAID são sensíveis a maiúsculas, o valor chega ao Google inválido.
• Upload após a janela de 90 dias: em ciclos de venda longos, o Closed Won pode ocorrer depois que o Google descartou o GCLID. A solução é subir um evento de funil intermediário que aconteça dentro da janela válida.
• Nome da ação de conversão com diferença mínima: o nome no CSV ou na integração precisa ser idêntico ao nome configurado no Google Ads, incluindo maiúsculas, minúsculas e espaços. Uma diferença de um caractere silencia o upload inteiro.
• Upload imediato sem aguardar indexação: o Google leva algumas horas para indexar um novo identificador de clique. Uploads realizados logo após a geração do lead retornam CLICK_NOT_FOUND. A recomendação é aguardar ao menos esse intervalo antes de tentar o envio.
• Usar a ação de conversão como sinal de lances antes de validar o import: ativar o import como coluna de conversão primária antes de confirmar que os dados estão chegando corretamente pode distorcer o Smart Bidding com dados incompletos. Configure primeiro como "conversão secundária" e monitore pelo relatório de diagnóstico.

Arquitetura de referência: do clique ao bid otimizado

A estrutura abaixo representa o modelo funcional mínimo para um ambiente B2B com ciclo de vendas de 30 a 90 dias:

1. Auto-tagging ativo na conta do Google Ads. Pré-requisito para geração de GCLID.
2. Script de captura em todas as páginas do site, incluindo redirecionamentos de mobile. Armazena GCLID, GBRAID e WBRAID em localStorage com validade de 90 dias e injeta nos campos ocultos do formulário.
3. CRM com campos mapeados para os três identificadores, e-mail e telefone do lead no registro original.
4. Ações de conversão separadas no Google Ads para MQL, SQL e Closed Won, cada uma com valor monetário atribuído.
5. Integração via Data Manager com o CRM (HubSpot ou Salesforce têm conectores nativos; para outros CRMs, usar conector SFTP, Google Sheets com atualização programada ou a Data Manager API).
6. Frequência de upload: diária. Para ciclos longos, subir eventos intermediários garante que o algoritmo receba sinal dentro da janela de 90 dias.
7. Enhanced Conversions for Leads ativado, enviando GCLID junto com e-mail e telefone hasheados em SHA-256 como chaves de match redundantes.
8. Monitoramento via relatório de diagnóstico de conversões offline, verificando taxa de match, erros de upload e volume de conversões importadas por ação.
9. Migração para tROAS após 60 dias de uploads consistentes com volume suficiente por campanha.

Esse modelo não exige integração customizada. Para a maioria das empresas com HubSpot ou Salesforce, é possível implementar completamente via Data Manager sem escrever uma linha de código. O trabalho mais complexo costuma estar na parte da captura de identificadores no site e no mapeamento dos campos no CRM.

Quando offline conversions não resolve o problema

Offline conversions é uma ferramenta de sinal, não uma estratégia de aquisição. Se o problema for geração insuficiente de conversões para alimentar o Smart Bidding, ou se o produto ou mercado ainda não tiver dados históricos de taxa de fechamento, o setup técnico vai ser correto mas os resultados do algoritmo serão instáveis.

Em contas com volume de conversões offline abaixo do mínimo para tROAS, a abordagem mais segura é rodar com tCPA apontando para um evento de funil intermediário com volume suficiente, enquanto o histórico de eventos de maior valor é acumulado em paralelo. O objetivo de longo prazo é migrar o sinal de otimização progressivamente para baixo no funil, à medida que o volume permite.

Se sua conta está otimizando para preenchimento de formulário hoje, o primeiro passo não é mudar a estratégia de lance. É capturar o GCLID, mapear os estágios de funil no CRM e começar a subir as conversões offline. Com os sinais corretos chegando ao Google Ads, as decisões de lance têm base para melhorar.