Depois de 15 de junho de 2026, a clínica ainda consegue enviar conversões offline pela API do Google Ads?

cmsapointoo·18 de agosto de 2026·6 min de leitura

Depois de 15 de junho de 2026, uma clínica não deve iniciar uma integração nova contando com o fluxo legado de UploadClickConversion. A documentação do Google diz que chamadas podem falhar quando o token de desenvolvedor nunca enviou solicitações de conversão offline ou de conversões melhoradas para leads. A rota recomendada para novas integrações é o Data Manager API.

O que mudou no fluxo de conversões offline?

O Google Ads API documenta que, a partir de 15 de junho de 2026, solicitações UploadClickConversion podem falhar quando o token de desenvolvedor não tinha histórico de uso para uploads offline ou conversões melhoradas para leads. Isso cria uma diferença importante entre uma integração antiga já reconhecida e uma integração nova criada após o marco.

Não trate a data como se todos os eventos antigos fossem apagados ou como se todos os tokens existentes fossem imediatamente desativados. A regra descrita é uma condição de aceitação para solicitações. A equipe precisa confirmar o estado real do token, o tipo de recurso usado e a mensagem retornada pelo endpoint.

O Google orienta a migração para o Data Manager API. Esse produto tem seus próprios recursos, campos, diagnósticos e fluxo de ingestão. Copiar a chamada antiga e apenas trocar o endereço não é uma migração testada.

Como uma clínica deve verificar seu token?

Comece com evidência técnica, não com uma suposição baseada na idade da conta. Registre o ID do cliente, o token de desenvolvedor, o recurso de conversão usado, a data do último upload, o método de autenticação e o resultado de uma solicitação de teste sem dados reais.

Identifique se a integração usa UploadClickConversion ou outro fluxo de conversão.
Consulte o histórico de solicitações e guarde códigos de erro e request IDs.
Verifique se o token já enviou offline conversions ou enhanced conversions for leads.
Teste o novo mapeamento no ambiente de desenvolvimento com identificadores sintéticos.
Defina uma janela de convivência em que o sistema registre falhas sem duplicar eventos.

O artigo sobre Data Manager API para formulários de clínicas mostra como separar captura, validação e ingestão. O relatório de outbox de conversões offline ajuda a registrar tentativas sem depender de um clique no painel.

Data Manager API substitui o cuidado com o payload?

Não. A migração muda o transporte e o contrato da API, mas não transforma dados de saúde em dados permitidos para publicidade. Antes de enviar, a agência precisa classificar o evento, a origem do dado, a finalidade, a base jurídica aplicável e a política do produto.

Para um evento elegível, mantenha o payload mínimo. Um identificador de clique ou outro identificador documentado, uma ação de conversão, um horário, um valor quando permitido, uma moeda e um transaction ID opaco podem ser suficientes. Não envie nome, telefone, e-mail, diagnóstico, procedimento clínico ou observações para resolver um problema de atribuição.

Hash não é uma autorização. O artigo sobre base legal e Customer Match explica por que uma transformação técnica não elimina a análise de saúde sensível. O mesmo limite vale para uma chamada feita pelo Data Manager API.

Como evitar perda ou duplicação durante a migração?

Use uma outbox local. Quando a clínica confirma um resultado, grave o evento interno com um ID estável, estado queued, contador de tentativas e uma cópia do mapeamento que será usado. Um trabalhador envia o evento e registra resposta, atraso e erro sem reabrir a consulta clínica.

Uma falha de API não deve marcar o tratamento como não convertido. Da mesma forma, uma resposta aceita não deve gerar uma segunda linha na próxima execução. Faça reconciliação por transaction ID, conversão e tenant. Reenvie apenas quando o diagnóstico indicar uma falha transitória ou quando a documentação permitir a repetição.

Estado local	Significado	Ação
queued	Evento validado internamente	Enviar pelo trabalhador autorizado
accepted	API aceitou a solicitação	Guardar resposta e não duplicar
retryable	Erro transitório ou limite	Repetir com backoff e limite
needs-review	Campo, consentimento ou política incerta	Bloquear envio e pedir decisão

A migração muda a política de consentimento?

Não. A migração é uma mudança de produto e de integração. A clínica continua responsável por decidir se pode medir, compartilhar ou modelar o evento no contexto da jurisdição e da política aplicável. Um endpoint novo não amplia a permissão do formulário nem substitui uma autorização.

Em uma clínica brasileira, documente a finalidade de atribuição e a separação entre dados usados internamente e dados enviados ao Google. Em uma operação internacional, registre também região, contrato, instruções do controlador e mecanismo de transferência. Se a decisão estiver pendente, mantenha googleOfflineSyncEnabled=false.

FAQ

Um token antigo garante que todas as chamadas continuarão funcionando?

Não. A documentação descreve uma condição de histórico para determinadas chamadas. Confirme o token, o endpoint e a resposta atual.

Posso migrar apenas trocando o endpoint?

Não é uma migração suficiente. Refaça o mapeamento, teste o diagnóstico, registre IDs e confirme o comportamento do novo recurso.

Posso enviar nome do paciente para aumentar a correspondência?

Não envie dados de saúde ou identificadores diretos sem uma análise específica de elegibilidade, finalidade e autorização. Prefira o payload mínimo documentado.

O que fazer quando a API rejeita um evento?

Classifique o erro, preserve o evento interno, não marque o resultado como perdido e encaminhe casos de política ou consentimento para revisão humana.

Referências

Nota: Este texto é informação técnica e editorial. Não constitui aconselhamento jurídico, fiscal ou garantia de elegibilidade para Google Ads.