Por que a conversão offline do Google Ads não aparece? CONVERSION_PRECEDES_EVENT e EXPIRED_EVENT

Quando a conversão offline some do Google Ads sem nenhum erro visível, o upload pode ter sido rejeitado dentro de uma resposta que parece de sucesso: com partial_failure ligado, o erro vem no campo partial_failure_error. No caso que medi, a resposta era HTTP 200. Os dois códigos que apareceram foram CONVERSION_PRECEDES_EVENT (a data da conversão veio antes do clique) e EXPIRED_EVENT (o clique está fora da janela da ação de conversão). O primeiro se conserta; o segundo não tem conserto. Nesse caso, havia ainda um problema anterior aos dois: o formulário e a automação liam fontes diferentes.

O que a documentação diz

Conferi as páginas do Google em 10 de outubro de 2026.

• O upload de conversões de clique exige partial_failure ligado. A página de importação diz que o campo "deve ser true" e manda tratar a resposta conforme as diretrizes de partial failure.
• Na página de partial failure, as operações válidas são gravadas e as que falham voltam em partial_failure_error. As operações que falharam aparecem como resultados vazios.
• CONVERSION_PRECEDES_EVENT: o evento importado tem um conversion_date_time anterior ao clique. A documentação pede para conferir o valor e tentar de novo.
• EXPIRED_EVENT: o evento não pode ser registrado porque o clique ocorreu antes da janela de clique da ação de conversão. A orientação é importar dados mais recentes.
• TOO_RECENT_EVENT: o clique tem menos de 6 horas, e a orientação é tentar de novo depois disso.
• EVENT_NOT_FOUND: o evento não pôde ser atribuído a um clique, o que pode acontecer se ele não veio de uma campanha do Google Ads.
• O conversion_date_time precisa ter fuso, no formato yyyy-mm-dd HH:mm:ss+|-HH:mm. O fuso pode ser qualquer valor válido e não precisa ser o da conta; a página recomenda o da conta se você for comparar com os números da interface.

Nenhuma dessas páginas diz quantos dias dura a janela. Ela é uma configuração da ação de conversão. No caso abaixo, os cliques rejeitados com EXPIRED_EVENT tinham mais de 90 dias, e é só isso que eu afirmo.

O que vi em produção

Era um CRM que dispara uma automação a cada alteração de negócio, e a automação enviava as conversões ao Google. O painel de anúncios mostrava zero. Achei quatro causas em camadas, e só enxerguei a seguinte depois de consertar a anterior.

1. Fonte errada. O formulário da página de captação gravava o lead em uma conta do CRM, e a automação lia outra. Os dois nunca se encontravam. Numa varredura da base inteira, achei um único negócio com identificador de clique (gclid), e era um teste manual. Antes de culpar a API do Google, olhe se o lead que ela deveria receber chega ao fluxo.
2. Data anterior ao clique. Depois de apontar a automação para a fonte certa, o Google ainda não contava as vendas. A conversão de "ganho" era datada com a data de criação do contato. Contato reaproveitado tem data antiga, anterior ao clique, e o Google rejeita com CONVERSION_PRECEDES_EVENT. Como o upload usa partial failure, a resposta que vi era HTTP 200 e o nó do n8n marcava sucesso. Perdido e aguardando funcionavam porque eram datados com a hora atual. Em 2 de julho de 2026 passei a datar o ganho com a hora do envio, e um negócio reenviado foi aceito.
3. Janela vencida. Ao incluir um nó que lê o erro dentro do HTTP 200, e que dava erro para qualquer rejeição, a automação estourou dezenas de erros em poucos minutos. Eram negócios ganhos antigos, reprocessados porque o gatilho disparava em qualquer alteração, com cliques fora da janela: EXPIRED_EVENT. Isso é terminal. Reenviar não adianta, porque a conversão não pode mais ser atribuída. Passei a registrar EXPIRED_EVENT como "pulado" e a deixar erro de verdade, como CONVERSION_PRECEDES_EVENT, falhar de forma visível.
4. Filtro que chamava lead de venda. O filtro tratava qualquer etapa marcada como sucesso como "ganho". Uma etapa de lead convertido (qualificado, não venda) tinha mais negócios do que a etapa de venda de fato. Mais da metade do que subia como venda não era venda.

Corrigir a data trocou um código pelo outro nos negócios de clique antigo, porque a conversão continuava perdida. Foi o mesmo prejuízo com outro nome, e não uma regressão.

O mesmo problema, do lado da Meta

No mesmo fluxo, três conversões personalizadas da Meta estavam zeradas havia meses. No que medi, elas só contavam o evento com o nome idêntico, caractere por caractere. Duas tinham diferença de acento, e uma começava com o caractere invisível U+2060 (word joiner), herdado de um cenário antigo. A Meta recebia o evento com outro nome e não ligava os dois. Não vi isso documentado, e não generalizo: é uma observação de produção, de comparar o nome na tela com o enviado. Se um evento personalizado fica zerado com o fluxo funcionando, vale comparar o nome byte a byte, sobretudo se ele foi colado de um chat ou de uma planilha.

O que fazer

1. Confirme que o lead e o identificador de clique chegam à automação antes de olhar o Google.
2. Leia o partial_failure_error na resposta. HTTP 200 não quer dizer aceito.
3. Date a conversão com um instante posterior ao clique e com fuso, e nunca com a data de cadastro de um contato reaproveitado. O ideal é o momento real da venda; no meu caso, a solução prática foi usar a hora do envio.
4. Trate EXPIRED_EVENT como fim da linha e não como falha a repetir.
5. Restrinja "ganho" à etapa de venda, não a qualquer etapa de sucesso do funil.

Se o seu CRM e os seus anúncios não fecham as contas, é um trabalho de vendas e CRM com IA.