Conversões offline Google Ads: do clique ao CRM

Para implementar conversões offline no Google Ads, capture o identificador do clique, grave-o com o lead no CRM e devolva cada avanço relevante com nome, horário, valor e Código do pedido. O ponto decisivo não é importar todos os estágios: é escolher como ação primária o evento que representa qualidade comercial sem chegar tarde demais ou com pouco volume para o Smart Bidding.

O envio do formulário informa que alguém se cadastrou. A conversão offline informa o que aconteceu depois. Assim, você deixa de tratar um cadastro inválido e uma venda como resultados equivalentes. Se o problema ainda é descobrir por que chegam contatos ruins, faça primeiro a auditoria de leads desqualificados no tráfego pago. Este guia começa no ponto seguinte: devolver a qualidade confirmada ao Google Ads.

Como funcionam as conversões offline no Google Ads?

Conversões offline ligam um evento registrado fora do site ao clique original do anúncio. O Google Ads usa identificadores de clique, dados próprios fornecidos pelo usuário ou ambos para atribuir lead qualificado, reunião, oportunidade e venda à campanha correspondente.

Com a codificação automática ativa, o clique pode acrescentar GCLID à URL. Em contextos compatíveis, GBRAID ou WBRAID podem cumprir a função de identificador. Você captura esse valor antes que uma troca de página, um formulário incorporado ou a saída para o WhatsApp o faça desaparecer. Depois, salva o identificador no registro do CRM e o envia com o evento posterior.

O Google recomenda que novas implementações comecem por conversões otimizadas para leads, em vez da importação offline legada. Nesse modelo, dados próprios normalizados e com hash ajudam a fazer a correspondência entre formulário, CRM e resultado comercial. Segundo o Google Ads, anunciantes que enviaram dados próprios junto com GCLIDs tiveram aumento médio de 10% nas conversões medidas em comparação com importações offline padrão. Isso é ganho de mensuração informado pelo Google, não promessa de aumentar vendas.

A atribuição permite analisar campanha, palavra-chave e data relacionadas ao clique, mas os relatórios podem oferecer visões diferentes. A coluna padrão organiza resultados conforme a atribuição do anúncio; a coluna Conversões por momento da conversão ajuda a conferir o dia em que o avanço comercial realmente ocorreu. Defina qual visão será comparada com o CRM antes de declarar que existe discrepância.

Como capturar GCLID, GBRAID e WBRAID no formulário?

Ative a codificação automática, leia os identificadores na URL e mantenha um único conjunto por sessão de atribuição. Um novo clique identificado deve substituir atomicamente o conjunto anterior, com horário de captura e expiração; depois, grave esse conjunto no backend junto com o lead.

1. Crie no formulário os campos ocultos `gclid`, `gbraid` e `wbraid`.
2. Na página de entrada, leia os parâmetros com `URLSearchParams`. Se houver qualquer identificador novo, substitua o conjunto anterior inteiro, em vez de atualizar cada chave isoladamente.
3. Grave no conjunto o horário de captura e uma expiração coerente com a janela usada pela operação. Ao expirar, apague todos os identificadores juntos.
4. Recupere apenas o conjunto ainda válido em cada etapa e preencha os formulários que podem gerar o lead.
5. Se o formulário for montado depois do carregamento da página, execute o preenchimento após a montagem ou observe a inserção dos campos no DOM.
6. Envie os campos ocultos ao backend, à automação ou ao webhook junto com o identificador interno do lead e grave-os no CRM.
7. Impeça que visitas posteriores sem identificador apaguem a atribuição válida já associada ao lead.
8. Se houver saída para WhatsApp, troca de domínio ou redirecionamento, grave o registro no backend antes do salto e use o identificador interno para reconciliar a conversa com o lead.

Um código de referência é: `const K='google_click_attribution',ks=['gclid','gbraid','wbraid'],p=new URLSearchParams(location.search),now=Date.now(),ttl=Number(document.documentElement.dataset.attributionTtlMs),incoming=Object.fromEntries(ks.map(k=>[k,p.get(k)]).filter(([,v])=>v));if(Object.keys(incoming).length){if(!Number.isFinite(ttl)||ttl<=0)throw new Error('Configure attributionTtlMs');localStorage.setItem(K,JSON.stringify({ids:incoming,capturedAt:now,expiresAt:now+ttl}));}let a;try{a=JSON.parse(localStorage.getItem(K));}catch(e){localStorage.removeItem(K);}if(a&&a.expiresAt<=now){localStorage.removeItem(K);a=null;}const fill=()=>ks.forEach(k=>document.querySelectorAll('[name="'+k+'"]').forEach(el=>el.value=a?.ids?.[k]||''));const watch=()=>{fill();new MutationObserver(fill).observe(document.body,{childList:true,subtree:true});};document.body?watch():addEventListener('DOMContentLoaded',watch,{once:true});`. O prazo fica em configuração, não espalhado no script. Quando chega um clique identificado, `incoming` substitui o objeto inteiro; assim, um GCLID novo não é combinado com GBRAID ou WBRAID antigos. A função `fill` também preenche campos adicionados depois por modal, widget ou aplicação cliente.

Esse `localStorage` é apenas persistência temporária no cliente. Ele pertence à origem atual, pode ser apagado pelo usuário e não é um registro confiável do lead. Uma landing page em um domínio também não compartilha o valor automaticamente com um formulário em outro. O script só alcança campos disponíveis no DOM da página; um formulário incorporado em outro domínio precisa receber os identificadores pela integração do próprio formulário ou pelo backend. Antes de redirecionar para outro domínio, subdomínio ou WhatsApp, envie o conjunto válido ao backend e associe-o ao `lead_id`; não presuma que o armazenamento do navegador atravessou o salto.

Em um funil de quiz, salve o identificador desde a entrada, não apenas na tela de captura. Quando o visitante concluir as respostas, envie ao CRM o GCLID disponível, o `lead_id`, a pontuação, o resultado de qualificação e os dados de contato. A conclusão do quiz não deve virar automaticamente uma conversão primária: o sinal útil é a qualificação calculada por critérios comerciais.

Como organizar o CRM e deduplicar os eventos?

O CRM precisa guardar separadamente a identidade do lead, a origem publicitária e o histórico de eventos. Para deduplicar, crie uma chave imutável para cada combinação de lead e estágio e use a mesma chave em qualquer envio por automação, planilha ou API.

No Google Ads, o ID exclusivo da conversão offline aparece como Código do pedido e corresponde ao ID da transação. Segundo a documentação do Google, se duas conversões da mesma ação usam o mesmo ID da transação, a segunda é rejeitada como duplicada. Uma chave como `lead_id + estágio` impede que o reprocessamento da mesma qualificação conte novamente, mas ainda permite que reunião e venda sejam eventos distintos.

Não gere um novo Código do pedido a cada tentativa. Isso transforma retentativas técnicas em conversões novas. Gere a chave quando o marco comercial ocorrer, salve-a no CRM e reutilize-a em todo o fluxo. Zapier pode acionar uma automação; Google Sheets ou BigQuery podem atuar como fonte ou área intermediária; o Google Ads Data Manager ou a integração própria faz a ingestão compatível. Esses componentes não devem criar chaves diferentes, e a enumeração não significa que todos enviem conversões diretamente ao Google Ads. O Google também informa que uma conversão com a mesma combinação de identificador, nome, data e hora não é importada mais de uma vez, mas o Código do pedido oferece uma regra explícita e controlável.

Modele eventos como histórico, não apenas como o estágio atual. Se um vendedor mover uma oportunidade para trás e depois para frente, o CRM precisa saber se houve um novo fato comercial ou apenas uma correção. Sem esse registro, uma automação disparada por mudança de coluna pode reenviar o mesmo evento com outro horário e escapar da deduplicação básica.

Qual evento importar: lead qualificado, reunião ou venda?

Importe todos os marcos confiáveis para análise, mas escolha como primário o evento que melhor combina qualidade, velocidade e volume. A venda é o sinal mais próximo da receita, porém pode ser tardia ou rara; o lead qualificado costuma ser melhor para lances quando aplica um critério comercial consistente e acontece cedo.

O Google Ads substituiu a antiga meta de leads importados por leads qualificados e leads convertidos. Lead qualificado é o contato gerado pelo Google que foi qualificado fora da plataforma. Lead convertido é aquele que concluiu uma etapa definida, como venda ou transação fechada. Use nomes que reflitam o fato registrado no CRM, em vez de chamar qualquer cadastro de MQL.

Ações primárias entram na coluna Conversões e podem orientar os lances. Ações secundárias permanecem em observação e aparecem em Todas as conversões, salvo o comportamento específico de metas personalizadas. Portanto, não torne formulário, lead qualificado, reunião e venda primários ao mesmo tempo sem entender a consequência: um único lead pode somar vários objetivos e misturar sinais de valores diferentes.

Para avaliar Smart Bidding, o Google recomenda períodos com pelo menos 30 conversões; para ROAS desejado, 50 conversões. Esses números são critérios de avaliação informados pelo Google, não garantia de desempenho. Se a venda fechada não alcança volume suficiente no período analisado, mantenha-a como secundária e use um estágio anterior comprovadamente correlacionado com receita.

Campanhas de Pesquisa também usam conversões offline; o recurso não é exclusivo de Display. Para geração de demanda já existente, combine essa implementação com a escolha correta entre Pesquisa e Performance Max para geração de leads. O evento de qualidade precisa representar a mesma intenção que a campanha pretende capturar.

Como preparar o envio das conversões ao Google Ads?

Prepare um evento canônico entre o CRM e o Google Ads antes de escolher o conector. Esse esquema permite ligar uma fonte compatível ao Google Ads Data Manager ou criar um adaptador para a Data Manager API sem espalhar regras de negócio pela integração. A conexão escolhida ainda precisa mapear o evento canônico para os campos aceitos pelo caminho atual.

Um envelope interno pode seguir esta estrutura: `{"event_id":"<lead_id>:qualified","event_name":"qualified_lead","event_time":"<data-hora-com-fuso>","click_ids":{"gclid":"<valor-ou-nulo>","gbraid":null,"wbraid":null},"user_data":{"email":"<permitido-ou-nulo>","phone":"<permitido-ou-nulo>"},"value":null,"currency":null,"consent_status":"<estado-registrado>"}`. Esse exemplo é o contrato entre CRM e integração, não uma requisição pronta da Data Manager API. O adaptador deve transformar cada campo conforme a documentação atual da conexão escolhida, sem alterar `event_id`, `event_name` ou `event_time` durante retentativas.

A mudança de infraestrutura de 2026 precisa entrar no projeto. Desde 15 de junho de 2026, uploads de conversões offline e conversões otimizadas para leads foram migrados para a Data Manager API e bloqueados na Google Ads API, salvo acesso legado permitido. Se uma integração própria ainda chama o serviço antigo, confirme o acesso legado ou planeje a migração; não use objetos e serviços da Google Ads API como referência para uma integração nova na Data Manager API.

Desde abril de 2026, o Google Ads aceita simultaneamente dados fornecidos pelo usuário vindos de tags, Data Manager e conexões de API em uma configuração unificada. Isso facilita combinar captura no site e resultado do CRM, mas aumenta a necessidade de uma chave única. Se tag, fonte intermediária e API puderem relatar o mesmo marco, todos devem reutilizar o mesmo Código do pedido.

1. Crie uma ação separada para cada marco que precisa ser analisado, com nomes estáveis e correspondentes aos usados pelo evento canônico.
2. Configure o novo evento inicialmente como ação secundária.
3. Faça o CRM gerar um registro imutável do evento com `event_id`, `event_name`, `event_time`, identificadores disponíveis, dados próprios permitidos, valor, moeda e estado de consentimento.
4. Escolha entre uma conexão compatível no Google Ads Data Manager e um adaptador próprio para a Data Manager API.
5. Na opção escolhida, mapeie cada campo do evento canônico para o campo aceito pela conexão atual; não envie literalmente os nomes internos sem esse mapeamento.
6. Valide o evento antes da transmissão: rejeite ausência de nome, horário ou Código do pedido e não misture identificadores capturados em cliques diferentes.
7. Envie o evento somente quando a regra do estágio for satisfeita e o mesmo `event_id` ainda não tiver sido aceito.
8. Grave a resposta, o status e o erro. Em uma retentativa, reutilize o mesmo `event_id` e os mesmos dados do fato comercial.
9. Consulte o diagnóstico de dados offline e reconcilie os eventos aceitos, rejeitados e pendentes com o histórico do CRM.

É possível trabalhar sem GCLID usando dados próprios, como e-mail ou telefone, dentro de conversões otimizadas para leads. Porém, não presuma que todas as conexões atuais do Google Ads Data Manager e da Data Manager API usam o mesmo procedimento de normalização, hash ou payload. O requisito documentado no material técnico deste artigo — normalizar os dados, aplicar hash, preencher objetos `ClickConversion` e enviar pelo `ConversionUploadService` — pertence ao procedimento legado da Google Ads API e só deve orientar integrações com acesso legado permitido. Para uma implementação atual, mantenha no evento canônico apenas os dados próprios permitidos e faça o adaptador seguir o formato exigido pela conexão escolhida. Hash não encerra as obrigações de consentimento, segurança ou governança.

Para contatos que saem do formulário e continuam no WhatsApp, preserve um `lead_id` comum entre a captura e o CRM. O telefone sozinho pode sofrer alteração de formato, compartilhamento ou erro de digitação. O desenho operacional de reconciliação está no guia de rastreamento de leads no WhatsApp até a venda.

Como validar e trocar a meta primária com segurança?

Valide o novo evento como secundário, compare CRM e Google Ads e só depois o torne primário. Ao mesmo tempo, rebaixe o envio do formulário para evitar que o Smart Bidding continue otimizando pelos dois sinais sem uma decisão explícita.

Checklist de teste ponta a ponta

• Faça um clique real de teste e confirme se GCLID, GBRAID ou WBRAID aparece e é persistido.
• Confirme que um novo clique substitui atomicamente o conjunto anterior e que um conjunto expirado não preenche o formulário.
• Passe por todas as páginas, redirecionamentos, subdomínios e formulários incorporados do caminho real.
• Abra modais e widgets carregados depois da página e confirme que os campos ocultos foram preenchidos após a montagem.
• Inspecione os campos ocultos antes do envio e confirme os mesmos valores no CRM.
• Mova o lead para o estágio testado e confira nome da conversão, horário, fuso, valor, moeda e Código do pedido.
• Reprocesse o mesmo evento e confirme que ele não cria uma conversão adicional.
• Verifique diagnóstico, rejeições e taxa de correspondência sem confundir evento enviado com evento atribuído.
• Compare o CRM com as colunas Conversões, Todas as conversões e Conversões por momento da conversão.
• Documente quem pode corrigir um estágio e como a correção afeta eventos já enviados.

O processamento costuma levar menos de 12 horas, mas conversões associadas a GBRAID ou WBRAID podem demorar até 72 horas, segundo o Google Ads. Não refaça o upload imediatamente porque o relatório ainda não apareceu. Consulte o diagnóstico e o status do lote antes de reprocessar.

Conversões offline enviadas mais de 90 dias após o último clique não são importadas; para conversões otimizadas para leads, o limite informado pelo Google é 63 dias. O Google também informa que mantém o GCLID por somente 90 dias e recomenda enviar outro evento intermediário quando a conversão final acontecer depois desse prazo. Em ciclos longos, não espere apenas a venda: use oportunidade ou outro avanço real e verificável.

Depois da troca da ação primária, evite mudanças simultâneas em orçamento, segmentação, criativos e critérios do CRM. O Google informa uma fase padrão de aprendizado de 7 a 14 dias para Smart Bidding. Preserve uma janela de observação, acompanhe atraso de conversão e compare qualidade comercial, não apenas o total exibido na campanha.

A estratégia de lances depende do sinal disponível. Use Maximizar conversões ou CPA desejado quando os eventos primários representam resultados comparáveis. Considere Maximizar valor da conversão ou ROAS desejado somente quando os valores enviados são consistentes e refletem diferença econômica real entre resultados. Atribuir valores arbitrários a MQL, reunião e venda pode fazer o algoritmo otimizar uma convenção interna em vez de receita.

A fronteira é clara: conversões offline não corrigem qualificação subjetiva, CRM abandonado ou equipe que atualiza estágios apenas no fim do mês. Também não recuperam identificadores que nunca foram capturados. Antes de automatizar, defina o que torna um lead qualificado, quem registra o avanço e em que momento o evento se torna imutável.