Conversões off-line do Google Ads no WordPress

Se os seus formulários no WordPress ainda enviam leads qualificados por uma integração nova, ou fora da lista de permissões, da API Google Ads, o site pode parecer saudável enquanto o upload da conversão off-line falha depois. O formulário é enviado. O CRM recebe o contato. A equipe comercial atualiza o lead. O Google Ads não recebe o resultado.

Esse risco aumentou depois de 15 de junho de 2026. O Google direcionou as importações de conversões off-line e as conversões otimizadas para leads para a API Data Manager. O ponto principal não é apenas o endpoint de upload. O WordPress precisa preservar evidências suficientes de aquisição e consentimento no momento em que o lead é criado, para que o CRM ou um worker no servidor consiga associar a venda posterior à interação original com o anúncio.

Este guia apresenta o contrato de dados completo: o que capturar no WordPress, onde deve terminar a responsabilidade do navegador, como preparar um evento da API Data Manager e como verificar cada transição sem expor credenciais nem dados de clientes.

Principais conclusões

• A mudança de 2026 afeta o caminho do upload, não a necessidade de captura precisa no WordPress.
• Integrações novas, ou fora da lista de permissões, devem usar a API Data Manager. Alguns tokens de desenvolvedor que já estavam ativos podem manter acesso legado à API Google Ads.
• Um status posterior no CRM, como qualified_lead ou converted_lead, só é útil se ainda puder ser associado ao envio original do WordPress.
• O Google aceita identificadores de clique como gclid, gbraid e wbraid, além de dados próprios normalizados e com hash.
• As importações off-line padrão têm uma janela de 90 dias após o último clique associado. As conversões otimizadas para leads têm 63 dias.
• O transactionId deve ser estável e único dentro da ação de conversão, para que novas tentativas não criem conversões duplicadas.
• O código no navegador captura e encaminha as evidências permitidas. Um conector no servidor, CRM ou worker controla autenticação, hash, novas tentativas e entrega à API Data Manager.

O que mudou nas conversões off-line do Google Ads em 2026

A documentação do Google sobre importações de conversões off-line informa que, a partir de 15 de junho de 2026, os uploads dessas conversões e das conversões otimizadas para leads são migrados para a API Data Manager e bloqueados na API Google Ads. O guia para desenvolvedores da API Google Ads acrescenta um detalhe importante: os uploads falham para tokens de desenvolvedor que não enviaram solicitações qualificadas durante a janela de atividade definida pelo Google, entre janeiro e junho de 2026. Tokens ativos anteriormente podem continuar na lista de permissões do caminho legado.

Essa diferença precisa fazer parte da auditoria de uma integração existente:

O Google também unificou, em abril de 2026, a configuração das conversões otimizadas para a web e para leads. Essa configuração pode receber dados fornecidos pelo usuário por tags, pela Central de Dados e por conexões de API. Ela não elimina a necessidade de preservar o registro original do lead no WordPress ou no CRM.

A API Data Manager muda o transporte, não o problema de atribuição

O evento comercial normalmente acontece depois da sessão no site:

1. A pessoa clica no anúncio e chega a uma landing page no WordPress.
2. O WordPress cria um lead ou pedido.
3. A equipe comercial qualifica o lead horas ou dias depois.
4. O CRM ou backend emite uma conversão off-line.
5. O Google tenta associar a conversão a uma interação qualificada com o anúncio.

Se a etapa 2 descartar o ID do clique, o estado do consentimento ou a chave estável do lead, nenhuma reformulação posterior da API conseguirá reconstruir esses dados com confiança. Um endpoint mais completo não corrige dados de origem ausentes.

As janelas de envio fazem parte da arquitetura

As diretrizes de importação do Google documentam dois limites importantes, medidos a partir do último clique associado:

• Conversões off-line padrão enviadas depois de 90 dias não são importadas.
• Conversões otimizadas para leads enviadas depois de 63 dias não são importadas.

Esses prazos não são metas para a fila. São limites máximos. Uma integração confiável envia o evento logo após a mudança no CRM e reserva tempo para diagnosticar e repetir falhas temporárias.

O que o WordPress precisa preservar

Pense no envio do formulário como um envelope de atribuição ao redor do lead. O CRM pode acrescentar qualificação, receita e horários do ciclo de vida depois, mas não deveria precisar adivinhar como a pessoa chegou ao site.

Separe a captura bruta da atribuição calculada

Um registro prático tem duas camadas:

• Captura bruta: identificadores exatos da URL, página de entrada permitida, referenciador, horário e evidência de consentimento conforme observados.
• Atribuição calculada: canal normalizado, campanha do primeiro contato, campanha do contato mais recente ou rótulos derivados por regras.

Essa separação impede que uma mudança nas regras de classificação reescreva a evidência histórica. É possível recalcular um rótulo para relatórios. Não é possível recuperar um gclid descartado nem uma URL de entrada sobrescrita.

Primeiro contato e contato mais recente respondem a perguntas diferentes

Não force um único campo de campanha a servir todos os relatórios. O primeiro contato descreve a aquisição. O último contato elegível descreve a campanha mais recente antes do lead. O Google Ads realiza a correspondência com seus próprios identificadores elegíveis e regras de atribuição.

Quando uma pessoa retorna ao site, acrescente a nova visita a uma jornada limitada ou preserve campos separados para primeiro e último contato. Não substitua silenciosamente o único registro armazenado. Se o armazenamento precisar ser mínimo, mantenha pelo menos:

• contexto da primeira página de entrada;
• contexto da campanha elegível mais recente;
• identificadores exatos ainda necessários para entrega;
• horários de criação e conversão do lead.

Por que combinar IDs de clique e dados próprios

O Google informa que anunciantes que combinaram dados próprios com GCLID tiveram aumento mediano de 10% nas conversões mensuradas, em comparação com importações off-line padrão. É uma mediana informada entre os anunciantes participantes, não uma previsão ou garantia para uma conta específica.

A conclusão de engenharia é mais restrita: preserve as duas classes de identificadores elegíveis quando o consentimento, a base legal e as políticas aplicáveis permitirem. Não descarte o ID do clique porque existe um e-mail, nem descarte dados próprios aprovados porque existe um ID do clique.

Três caminhos limpos de implementação

O WordPress não aparece como origem direta na lista atual de origens compatíveis da Central de Dados. Isso não exige um plugin personalizado grande. Escolha o caminho mais curto que a sua estrutura atual já aceita.

1. WordPress para CRM e, depois, Data Manager

Use esse caminho quando o CRM já controla o status do lead e os resultados comerciais.

O WordPress envia ao CRM o lead, o envelope de atribuição e a evidência de consentimento. O conector compatível do CRM ou uma pequena integração no backend envia os eventos de qualified_lead e converted_lead.

Esse costuma ser o caminho mais limpo porque o resultado da venda já está no CRM. O teste decisivo é verificar se o CRM preserva os identificadores originais, em vez de aceitar apenas o contato e nomes de campanha.

Se você usa um webhook genérico, defina um contrato estável em vez de encaminhar todos os campos do formulário. O guia da FunnelSheet sobre integração por webhook e CRM mostra o limite entre captura e entrega.

2. WordPress para uma origem compatível

Use esse caminho quando a equipe já opera dados em uma origem compatível, como BigQuery, Cloud Storage, Google Sheets, HTTPS, MySQL, PostgreSQL, Salesforce, Snowflake ou outro conector listado.

O WordPress grava ou exporta o registro permitido. O CRM ou job de dados acrescenta o resultado do ciclo de vida. A Central de Dados importa as linhas mapeadas em uma frequência definida.

Esse caminho reduz código de API, mas não elimina a modelagem dos dados. Confirme tipos das colunas, horários com fuso, consentimento, identificadores, frequência de atualização e comportamento de duplicatas antes de ativar uma ação de conversão principal.

3. WordPress para um worker da API Data Manager no servidor

Use esse caminho quando for necessário ter controle por evento, uploads quase em tempo real, novas tentativas explícitas ou um CRM personalizado.

O worker deve:

1. receber ou consultar um marco elegível do CRM;
2. associá-lo à chave original do lead no WordPress;
3. verificar consentimento, base legal aplicável e identificadores obrigatórios;
4. normalizar e aplicar hash aos dados exigidos;
5. criar um ID de transação estável;
6. chamar events:ingest com validateOnly: true durante os testes;
7. armazenar o ID da solicitação ou uma categoria compacta de erro;
8. repetir apenas os erros que aceitam nova tentativa com segurança.

Não chame a API Data Manager pelo JavaScript da página. O navegador não pode guardar credenciais OAuth com segurança, e bloqueadores, navegação ou falhas de rede podem interromper a solicitação.

Exemplos de código: da captura no WordPress à validação na API Data Manager

Os exemplos a seguir são intencionalmente pequenos. Eles demonstram o contrato, não um plugin universal. Adapte seletores do formulário, evento de consentimento, armazenamento e autenticação à sua estrutura.

1. Preencha campos ocultos com os identificadores da página atual

Este exemplo no navegador lê apenas a URL atual e é executado depois que a plataforma de consentimento emite um evento de permissão para marketing. Sozinho, ele não resolve persistência entre páginas nem visitas de retorno.

const attributionKeys = [
  'gclid', 'gbraid', 'wbraid',
  'utm_source', 'utm_medium', 'utm_campaign', 'utm_content', 'utm_term'
];

function fillAttributionFields(form) {
  const params = new URLSearchParams(window.location.search);

  for (const key of attributionKeys) {
    const input = form.elements.namedItem(key);
    const value = params.get(key);
    if (input && value) input.value = value;
  }
}

window.addEventListener('marketing-consent-granted', () => {
  document.querySelectorAll('form[data-attribution]').forEach(fillAttributionFields);
}, { once: true });

Crie campos ocultos correspondentes no formulário:

<form data-attribution method="post">
  <input type="hidden" name="gclid">
  <input type="hidden" name="gbraid">
  <input type="hidden" name="wbraid">
  <input type="hidden" name="utm_source">
  <input type="hidden" name="utm_medium">
  <input type="hidden" name="utm_campaign">
  <!-- Seus campos visíveis e o botão de envio -->
</form>

Sites em produção normalmente precisam de persistência entre páginas, regras de primeiro e último contato, integrações com formulários e tratamento seguro para cache. Reutilize uma camada de atribuição existente em vez de duplicar essa lógica em cada formulário. O ClickTrail preserva primeiro e último contato, IDs de clique do Google e contexto de formulários com consentimento; a FAQ documenta os limites dos dados. Ele não substitui o destino no servidor para a API Data Manager.

2. Sanitize os dados do formulário no WordPress antes de armazená-los

Valores enviados pelo navegador não são confiáveis. Sanitize no servidor, use uma lista de campos permitidos e limite o tamanho antes de gravar em metadados do post, pedido ou payload do CRM.

function fs_attribution_fields(array $input): array {
    $keys = [
        'gclid', 'gbraid', 'wbraid',
        'utm_source', 'utm_medium', 'utm_campaign', 'utm_content', 'utm_term',
    ];
    $result = [];

    foreach ($keys as $key) {
        if (!isset($input[$key]) || !is_string($input[$key])) {
            continue;
        }

        $value = sanitize_text_field(wp_unslash($input[$key]));
        if ($value !== '') {
            $result[$key] = mb_substr($value, 0, 512);
        }
    }

    return $result;
}

$attribution = fs_attribution_fields($_POST);

Essa função não decide consentimento, prazo de retenção nem quem pode ler os campos. Essas são decisões da aplicação e da política de privacidade. Quando o WooCommerce controla o registro da conversão, associe o envelope ao pedido uma única vez e reutilize-o nas etapas seguintes; consulte a integração de atribuição para WooCommerce.

3. Normalize e aplique hash aos identificadores próprios no servidor

O guia de formatação do Google exige SHA-256 para os dados aplicáveis. A normalização de e-mail e telefone acontece antes do hash. Endereços Gmail e Googlemail exigem tratamento adicional de pontos e do sufixo iniciado por sinal de mais. Telefones devem seguir o padrão E.164.

import { createHash } from 'node:crypto';

const sha256Hex = value =>
  createHash('sha256').update(value, 'utf8').digest('hex').toUpperCase();

function normalizeEmail(value) {
  const email = value.trim().toLowerCase();
  const at = email.lastIndexOf('@');
  if (at < 1) throw new Error('Invalid email address');

  let local = email.slice(0, at);
  const domain = email.slice(at + 1);
  if (domain === 'gmail.com' || domain === 'googlemail.com') {
    local = local.split('+', 1)[0].replaceAll('.', '');
  }

  return `${local}@${domain}`;
}

function normalizeE164(value) {
  const phone = value.replace(/[\s().-]/g, '');
  if (!/^\+[1-9]\d{7,14}$/.test(phone)) throw new Error('Phone must be E.164');
  return phone;
}

const emailHash = sha256Hex(normalizeEmail('[email protected]'));
const phoneHash = sha256Hex(normalizeE164('+55 11 91234-5678'));

Hash não é consentimento nem base legal. Ele reduz a exposição do identificador em trânsito, mas o valor continua sendo dado usado para publicidade e sujeito às suas finalidades, avisos, controles de acesso, retenção, à LGPD e às políticas aplicáveis do Google. A ANPD também esclarece que o consentimento é apenas uma das hipóteses legais previstas na LGPD; valide a hipótese adequada ao seu tratamento, em vez de marcar consentimento por padrão.

4. Valide uma solicitação da API Data Manager antes de aplicá-la

A API aceita POST https://datamanager.googleapis.com/v1/events:ingest. Para conversões off-line e conversões otimizadas para leads do Google Ads, productDestinationId deve apontar para uma ação de conversão do tipo UPLOAD_CLICKS. A conta operacional precisa ser proprietária dessa ação.

O payload abaixo é um modelo baseado no esquema documentado. Substitua cada valor em maiúsculas por um valor aprovado da sua conta. O e-mail já deve estar normalizado, com SHA-256 e codificado em HEX.

{
  "destinations": [
    {
      "operatingAccount": {
        "accountType": "GOOGLE_ADS",
        "accountId": "GOOGLE_ADS_CUSTOMER_ID"
      },
      "loginAccount": {
        "accountType": "GOOGLE_ADS",
        "accountId": "GOOGLE_ADS_LOGIN_CUSTOMER_ID"
      },
      "productDestinationId": "UPLOAD_CLICKS_CONVERSION_ACTION_ID"
    }
  ],
  "encoding": "HEX",
  "consent": {
    "adUserData": "CONSENT_GRANTED",
    "adPersonalization": "CONSENT_GRANTED"
  },
  "events": [
    {
      "adIdentifiers": {
        "gclid": "CAPTURED_GCLID"
      },
      "userData": {
        "userIdentifiers": [
          { "emailAddress": "SHA256_HEX_EMAIL" }
        ]
      },
      "eventTimestamp": "2026-08-27T14:30:00-03:00",
      "transactionId": "LEAD_4827_QUALIFICADO",
      "eventSource": "WEB",
      "conversionValue": 250.00,
      "currency": "BRL"
    }
  ],
  "validateOnly": true
}

Envie a solicitação por um processo protegido no servidor, com o escopo OAuth da API Data Manager:

curl --fail-with-body \
  -X POST 'https://datamanager.googleapis.com/v1/events:ingest' \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H 'Content-Type: application/json' \
  --data-binary @event.json

Comece com validateOnly: true. Segundo o Google, essa opção valida a solicitação sem aplicar as mudanças. Depois que a validação passar e ação de conversão, consentimento, horários e identificadores forem confirmados, altere para false no worker controlado. Uma solicitação aceita retorna um requestId; mantenha esse identificador junto ao lote, sem registrar dados pessoais brutos em logs gerais.

Use um ID de transação estável

Para a mesma ação de conversão do Google Ads, a API Data Manager usa transactionId para deduplicar eventos enviados por várias origens. Gere esse ID a partir de um evento comercial durável, não da tentativa de upload.

Bom:

lead_4827_qualificado
pedido_9931_pago
negocio_18_convertido

Arriscado:

2026-08-27T14:31:11-03:00
tentativa_3
uuid_aleatorio_criado_em_cada_tentativa

Se houver timeout depois que o Google aceitar a solicitação, mas antes de o worker receber a resposta, a nova tentativa deve reutilizar o mesmo ID de transação.

Como verificar o fluxo completo

O envio bem-sucedido do formulário não comprova uma conversão off-line bem-sucedida. Verifique a cadeia por camadas e pare na primeira transição quebrada.

Padrões comuns de falha

Proteja os logs durante o diagnóstico

Não registre corpos completos das solicitações, tokens de acesso, e-mails e telefones brutos nem URLs de entrada com dados pessoais. Logs úteis podem conter:

• ID interno do lote;
• ID da ação de conversão;
• quantidade de eventos;
• indicadores booleanos da presença de identificadores;
• intervalo dos horários dos eventos;
• IDs de transação, quando forem chaves internas não sensíveis;
• status HTTP e categoria compacta do erro;
• ID da solicitação na API Data Manager.

Guarde evidências detalhadas e restritas apenas onde o processo de incidentes permitir, com prazo curto de retenção.

Um plano de migração com menos risco

O guia de upgrade das conversões otimizadas recomenda acompanhar as ações atualizadas por um ou dois ciclos de conversão, ou até quatro semanas, antes de mudar as configurações de otimização. Use esse período para comparar entrega e qualidade dos dados, não para enviar um evento e declarar sucesso.

Fase 1: inventário

1. Liste cada formulário, checkout, lead telefônico e status do CRM que alimenta o Google Ads.
2. Identifique o uploader atual: arquivo manual, conector, código da API Google Ads, origem da Central de Dados ou job desconhecido.
3. Confirme ação de conversão, conta proprietária, tipo de origem, status principal ou secundário e regra de contagem.
4. Determine se algum token legado da API Google Ads está comprovadamente na lista de permissões. Registre evidência, não uma suposição.

Fase 2: torne a captura durável

1. Preserve gclid, gbraid, wbraid, identificadores próprios aprovados, contexto da entrada e evidência de consentimento ou outra hipótese aplicável.
2. Crie um ID estável do lead ou pedido no momento da criação.
3. Verifique se os dados sobrevivem ao mapeamento entre WordPress e CRM e às mudanças posteriores de status.
4. Mantenha a captura bruta separada dos rótulos calculados de canal.

Se você precisa definir a camada de captura, consulte nosso serviço de conversões off-line e atribuição de CRM. A implementação deve continuar portátil: o WordPress captura o envelope, enquanto o CRM ou worker escolhido controla a entrega.

Fase 3: valide a entrega

1. Crie o menor evento elegível.
2. Use uma ação de conversão secundária para teste quando for adequado.
3. Execute a validação na API Data Manager sem aplicar mudanças.
4. Aplique um teste controlado com dados de teste ou dados devidamente autorizados.
5. Registre o ID da solicitação e consulte o diagnóstico da Central de Dados.

Fase 4: compare antes de otimizar

Acompanhe por um ou dois ciclos de conversão, ou até quatro semanas, conforme o volume de leads. Compare:

• eventos enviados, aceitos e processados;
• taxa de identificadores ausentes;
• taxa de rejeição por duplicidade;
• tempo mediano entre o marco no CRM e o upload;
• cobertura de correspondência e diagnóstico;
• precisão do valor e da moeda da conversão.

Somente depois decida se a nova ação deve se tornar principal e se as estratégias de lances devem usá-la.

Erros que devem ser evitados

Tratar UTMs como estratégia completa de correspondência no Google Ads

UTMs são um contexto valioso para relatórios. Elas não substituem gclid, gbraid, wbraid, atributos da sessão ou dados próprios elegíveis em todos os casos da API Data Manager.

Fazer upload pelo navegador

Uploads no navegador expõem credenciais e falham de maneira imprevisível durante navegação, bloqueio ou conexão instável. Capture no navegador; autentique e entregue no servidor.

Aplicar hash antes da normalização

[email protected] e [email protected] geram hashes diferentes. Aplique primeiro a normalização específica do campo exigida pelo Google, depois SHA-256 e a codificação HEX ou Base64 declarada.

Chamar todo formulário enviado de lead qualificado

Um contato inicial e um lead qualificado são eventos comerciais diferentes. Deixe o WordPress criar o lead e o CRM emitir o marco quando a regra de qualificação for atendida.

Gerar IDs novos em cada tentativa

Uma nova tentativa representa o mesmo evento. Reutilize o ID de transação para que a deduplicação funcione.

Esperar a janela de upload fechar

Os 90 e 63 dias são limites máximos. Envie cedo o suficiente para investigar erros, corrigir mapeamentos e repetir o envio.

Perguntas frequentes

O WordPress se conecta diretamente à API Data Manager do Google Ads?

O WordPress não aparece como origem nativa na lista atual da Central de Dados. Encaminhe os registros por um CRM, banco de dados, origem HTTPS ou de arquivo compatível, ou por um worker no servidor que use a API Data Manager.

Preciso de GCLID e dados próprios com hash?

Nem todo evento exige os dois. A API Data Manager aceita identificadores de anúncio, atributos da sessão, dados do usuário ou outros identificadores elegíveis conforme o caso. Quando a hipótese legal, o consentimento e as políticas permitirem, preservar o ID do clique e dados próprios preparados corretamente oferece mais evidências úteis para a correspondência.

O GCLID deve sobrescrever as UTMs?

Não faça um apagar o outro. Preserve o ID exato do clique como identificador de correspondência e as UTMs como contexto da campanha. A classificação de atribuição pode escolher uma precedência depois, sem destruir os campos brutos.

O que acontece quando o consentimento é negado e concedido depois?

Sua plataforma de consentimento, hipótese legal aplicável e política determinam o que pode ser armazenado antes da permissão. Não registre um estado retroativo. Guarde o novo estado e horário e permita a coleta e entrega elegíveis a partir desse momento, conforme sua política. Se o contexto existia apenas na memória antes da permissão, persista-o depois somente quando esse comportamento for permitido e informado.

Qual horário deve ser usado na conversão?

Use o horário em que o lead foi qualificado, a venda foi concluída ou outro evento comercial ocorreu, incluindo o fuso. Não use o horário do upload como substituto.

Como evitar conversões duplicadas?

Use um transactionId estável para cada evento comercial dentro da ação de conversão e reutilize-o nas novas tentativas. Mantenha o mesmo mapeamento em todas as origens que podem enviar esse evento.

O ClickTrail envia diretamente para a API Data Manager?

O ClickTrail cuida da captura de aquisição consciente de consentimento e pode encaminhar atribuição para formulários, WooCommerce e webhooks. Ele não é apresentado como destino nativo da API Data Manager. Conecte sua saída a um CRM compatível ou ao uploader no servidor.

Lista final de verificação

• A URL final da landing page no WordPress mantém os identificadores esperados depois dos redirecionamentos.
• Estado, finalidade e horário do consentimento ou outra hipótese aplicável estão registrados.
• Formulário ou checkout armazena um ID estável do lead ou pedido.
• gclid, gbraid e wbraid são preservados exatamente quando estão presentes e seu uso é permitido.
• Dados próprios aprovados são normalizados antes do SHA-256.
• Marcos do ciclo de vida no CRM mantêm a chave original do registro no WordPress.
• Destino na API Data Manager aponta para a ação correta do tipo UPLOAD_CLICKS.
• Horário do evento representa o resultado comercial e contém o fuso.
• ID da transação permanece estável entre tentativas e origens.
• Solicitações de teste usam validateOnly: true antes de aplicar mudanças.
• IDs das solicitações e diagnóstico são acompanhados sem registrar dados pessoais brutos.
• Nova ação de conversão é comparada por um ou dois ciclos, ou até quatro semanas, antes de alterar a otimização.

Fontes e limites da evidência

Este guia foi verificado na documentação atual do Google sobre importações de conversões off-line, janelas de upload e duplicatas, ingestão de eventos na API Data Manager, formatação de dados do usuário, ingestão REST e origens compatíveis. O contexto brasileiro de proteção de dados foi conferido no texto compilado da LGPD e nas orientações da ANPD.

Verificamos o esquema documentado, as regras dos campos, o limite da captura no WordPress e a estrutura dos exemplos. Não enviamos dados de clientes nem executamos um upload em produção numa conta de anunciante para este artigo. Elegibilidade da conta, hipótese legal, consentimento, cobertura de correspondência e impacto nos lances precisam ser verificados no seu ambiente.

Versão em português brasileiro publicada em 27 de agosto de 2026. Localização revisada para terminologia oficial do Google, LGPD, BRL, telefone brasileiro e rotas PT-BR da FunnelSheet.