Depois de 15 de junho de 2026, a clínica ainda consegue enviar conversões offline pela API do Google Ads?
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
- Google Ads API: upload de conversões por clique
- Google Ads Help: importação de conversões offline
- Google Data Manager API
Nota: Este texto é informação técnica e editorial. Não constitui aconselhamento jurídico, fiscal ou garantia de elegibilidade para Google Ads.









