Data Manager API do Google: O Que Muda Para Quem Sobe Conversões Offline

O Google introduziu a Data Manager API como o caminho unificado recomendado para enviar dados first-party — conversões offline, enhanced conversions para leads, customer match — para as contas de anúncios do Google. O caminho antigo, via Google Ads API (UploadClickConversions e endpoints equivalentes), foi marcado como legado: novas integrações são direcionadas para a Data Manager API, e integrações existentes são esperadas migrar.

Isso não é uma mudança cosmética de nome de endpoint. Muda a superfície de autenticação, os requisitos de normalização e o processo de aprovação que qualquer time ou ferramenta precisa passar para continuar subindo conversões.

O Que Isso Não É

Não há data confirmada de desligamento do caminho antigo. Se você encontrar conteúdo afirmando que a Google Ads API para upload de conversões “vai parar de funcionar em [data específica]”, trate com ceticismo — essa informação não está publicamente confirmada até julho de 2026.

O que está confirmado é mais sutil e, para efeitos de planejamento, mais importante: o caminho recomendado já mudou. APIs descontinuadas eventualmente param de funcionar — às vezes com aviso de meses, às vezes com uma janela mais curta — mas o padrão histórico do Google com deprecações é dar uma janela de migração e depois cortar. Migração feita sob pressão de prazo é sempre mais cara e mais arriscada do que migração planejada: bugs de normalização passam despercebidos, testes ficam incompletos, e a integração antiga é desligada antes da nova estar validada em produção.

A pergunta certa não é “quando isso vai quebrar”, é “quanto vai custar migrar isso quando eu precisar, e por que não fazer agora, com tempo”.

Quem é Afetado, Concretamente

Agências e times com scripts próprios. Se alguém escreveu um script — Python, Node, Apps Script — que chama a Google Ads API diretamente para subir conversões de CRM, essa integração está no caminho que o Google está descontinuando. A migração é responsabilidade de quem mantém o script.

Fluxos de Zapier ou Make usando ações de Google Ads. Esses fluxos dependem inteiramente do vendor (Zapier, Make) migrar a integração deles para a Data Manager API. Se o vendor não migrar, ou migrar com atraso, o fluxo do cliente fica preso ao caminho legado sem que o usuário final tenha visibilidade disso. Vale perguntar diretamente ao suporte do vendor qual é o plano de migração — não assumir que “vai continuar funcionando” é uma resposta suficiente. O comportamento de falha silenciosa desse tipo de fluxo já é um problema mesmo sem a migração — veja Zapier Para Conversões Offline: Quando Funciona e Quando Vira Imposto para o detalhamento de onde esses fluxos quebram hoje.

Quem faz importação manual via CSV não é afetado por esta mudança específica — o upload manual pela interface do Google Ads não passa pela Google Ads API da mesma forma. Mas vale o contexto: CSV manual já é o setup mais fraco disponível, com atraso de dias entre o fechamento do negócio e o upload, e sem suporte a enhanced conversions para leads. Não ser afetado pela migração da Data Manager API não significa que o setup atual seja bom — só significa que esse não é o problema mais urgente para quem está nesse caso.

O Que Muda Na Prática

A Data Manager API consolida em um único endpoint o que antes eram fluxos separados: conversões offline, enhanced conversions e audiências (customer match). Para quem já tem hashing e normalização corretos, a lógica central do payload não muda de forma radical — e-mail e telefone continuam sendo enviados com hash SHA-256, normalizados antes do hash. Os requisitos de normalização (minúsculas, remoção de espaços, formato E.164 para telefone) permanecem os mesmos princípios que já valiam para Enhanced Conversions — veja LGPD e Hashing de Conversões Offline para o detalhamento de como isso deve ser feito de forma correta e compatível com a LGPD.

O ponto de fricção real está em outro lugar: escopos de OAuth e processo de aprovação. A Data Manager API exige um novo escopo de autenticação, e o Google exige um processo de aprovação — semelhante ao que já existe para outras APIs sensíveis do Google — antes de liberar acesso de produção para uma ferramenta terceira. Isso significa que, se sua integração depende de uma ferramenta (Zapier, Make, ou qualquer middleware), o cronograma de migração não depende só do esforço técnico — depende do vendor conseguir aprovação do Google para o novo escopo, o que está fora do controle do usuário final.

Caminho antigo	Data Manager API
Endpoints separados por tipo de dado (conversões, audiências)	Endpoint unificado
Escopo de OAuth já estabelecido para Google Ads API	Novo escopo, sujeito a aprovação do Google
Normalização e hashing por conta do integrador	Mesmos requisitos de normalização, formato de payload distinto
Caminho legado, sem data de desligamento confirmada	Caminho recomendado para novas integrações

O Que Fazer Agora

Um checklist prático, na ordem em que faz sentido resolver:

1. Faça o inventário de como suas conversões offline chegam ao Google hoje. Script próprio? Zapier/Make? CSV manual? Um middleware dedicado? Sem esse inventário, não dá para saber quem precisa migrar e quem não precisa. Se a resposta for “não temos nada rodando ainda”, o caminho de partida é configurar enhanced conversions sem desenvolvedor — já direto no caminho novo.
2. Se depende de uma ferramenta terceira, pergunte ao vendor qual é o plano de migração para a Data Manager API — e se eles já têm o escopo aprovado pelo Google ou ainda estão no processo. Uma resposta vaga é um sinal de risco.
3. Se depende de script próprio, trate a migração como item de backlog com prioridade — não como urgência, mas também não como algo a ser ignorado indefinidamente. Orçar o tempo de desenvolvimento agora, com uma janela de meses pela frente, custa menos do que migrar sob pressão depois que o caminho antigo parar de aceitar chamadas.
4. Se está construindo uma integração nova do zero, não construa sobre o caminho legado. Qualquer integração nova hoje deve mirar a Data Manager API diretamente — construir em cima de uma API que o próprio fornecedor já sinalizou como descontinuada é dívida técnica assumida no dia um.

O Papel de um Middleware Nessa Transição

Para quem já usa um middleware dedicado em vez de scripts próprios ou automações genéricas, essa migração é responsabilidade do fornecedor da ferramenta, não do usuário final — o mesmo raciocínio que já vale para hashing, retry e deduplicação, como descrito em Zapier vs. Middleware. O trade-off é o inverso do script próprio: você depende do fornecedor priorizar a migração, mas não precisa alocar tempo de desenvolvimento interno para isso.

Próximo Passo

O True Conversions acompanha as mudanças de infraestrutura do Google Ads como parte da manutenção da plataforma, para que agências e times de marketing não precisem monitorar deprecação de API por conta própria. Configure em conversions.nexopath.com. Teste grátis, sem cartão.