API Data Manager do Google Ads para formulários de clínicas: uma arquitetura server-side

cmsapointoo on August 16, 2026

person holding black android smartphone

Um formulário de clínica não deve enviar conversões automaticamente ao Google Ads. Um desenho controlado começa pela medição interna: o navegador envia um evento em formato de formulário para o endpoint da clínica, e o servidor o mantém no ambiente aprovado até que uma análise separada autorize qualquer uso externo. Ligações telefônicas, mensagens, chamadas diretas a gtag ou fbq e criação de audiências ficam fora deste desenho.

A política de dados do cliente do Google informa que anunciantes não podem enviar informações de conversão relacionadas a categorias sensíveis e inclui informações médicas ou de saúde nessa lista. Um nome genérico não resolve se o evento subjacente está ligado à saúde. Este artigo descreve um padrão de controle recomendado para uma implantação futura de saúde, não controles já ativos em todas as contas do Apointoo. Mantenha o envio externo desativado até que a política vigente do Google e análises jurídica e de privacidade qualificadas permitam o evento e os campos exatos da clínica.

O que esta arquitetura server-side faz?

A arquitetura separa coleta, decisão, envio e relatório. O formulário se comunica com a aplicação aprovada pela clínica. A aplicação cria um evento interno limitado e decide se ele pode sair do ambiente próprio. Só um evento liberado por uma análise independente pode seguir para um destino de conversão no Google Ads. O navegador não se comunica diretamente com a plataforma publicitária.

formulário da clínica
  -> endpoint próprio
  -> validação da conta e do consentimento
  -> lista de campos permitidos
  -> registro durável do evento
  -> bloqueio padrão até a liberação do uso externo
  -> destino de conversão na Data Manager, se permitido
  -> reconciliação do envio

A documentação do Google informa que a Data Manager aceita eventos de conversão online e offline, organizados por destino e objeto de evento. Isso descreve o transporte. Não autoriza o envio de dados ligados à saúde. A política de dados do cliente cria uma restrição separada para informações de conversão relacionadas a categorias sensíveis. Antes de ativar qualquer rota, consulte os limites da taxonomia de resultados de agendamento e faça a revisão aplicável ao caso.

Passo 1: defina uma única conversão de formulário

Comece por uma definição interna que o gestor e a equipe técnica entendam da mesma forma. Um exemplo: “O evento medido é um pedido de consulta enviado com sucesso e confirmado pelo servidor.” A frase identifica a ação, a prova técnica e o sistema responsável. Ela não torna o evento apto para envio externo nem afirma que houve agendamento ou comparecimento.

Mantenha a definição estreita. O clique no botão de agendar não é um formulário concluído. Uma visita à página não é um lead. Uma ligação telefônica não faz parte deste produto. Se o resultado posterior do agendamento for relevante, guarde-o internamente e submeta-o a uma decisão separada antes de qualquer uso externo.

Se a rota externa for liberada por uma análise independente, o Google Ads distingue ações primárias e secundárias. Apenas uma fonte deve controlar a ação primária usada nos lances e no relatório principal. Não mantenha uma conversão direta no navegador e outra no servidor competindo pelo mesmo resultado.

Passo 2: colete apenas o necessário no endpoint próprio

O endpoint precisa validar o envio, aplicar a decisão de consentimento e criar uma referência do evento. Não precisa copiar o formulário completo para o fluxo publicitário. Perguntas clínicas, sintomas, tratamento procurado, notas da consulta e mensagens em texto livre ficam fora do evento enviado ao Google.

Separe o registro operacional do registro de conversão. O sistema operacional pode precisar de dados de contato para responder à pessoa. Já o registro de conversão deve conter uma referência opaca, o estado aprovado, o horário, os metadados mínimos da decisão e os campos publicitários autorizados. E-mail, telefone, número de prontuário ou ID de paciente nunca devem virar o ID do evento.

Rejeite campos desconhecidos. Se o formulário ganhar uma pergunta nova, um serializador permissivo pode copiá-la para o payload sem revisão. Uma lista explícita torna essa falha visível e impede que logs e filas de repetição virem cópias paralelas do atendimento.

Passo 3: teste a elegibilidade antes de montar um evento

A API Data Manager pode tecnicamente aceitar eventos para um destino configurado. Essa capacidade não decide a elegibilidade do uso. A política de dados do cliente do Google restringe informações de conversão relacionadas a categorias sensíveis. A política de publicidade personalizada restringe, de forma separada, audiências de saúde selecionadas pelo anunciante. Não use Customer Match, remarketing ou ativação de audiências como atalho.

Classe de campo Decisão padrão Motivo
Referência opaca do evento interno Manter internamente Apoia a deduplicação própria sem identificar paciente
Ação genérica Manter internamente até liberação O rótulo genérico não remove o contexto de saúde
Horário e valor numérico Manter internamente até liberação Ainda descrevem um evento de conversão
Referência de clique Manter internamente até liberação Exige finalidade válida e análise da política vigente
Nome, e-mail, telefone, tratamento, diagnóstico ou texto livre Bloqueados nesta rota Ficam fora do limite de conversão da clínica

Aplicar hash não muda o significado de um campo. Não transforme um identificador de paciente em hash para chamá-lo de anônimo. Se a rota depender de um campo proibido, mantenha o resultado em um relatório agregado interno.

Passo 4: aplique consentimento e política antes da fila

A chamada final à API acontece tarde demais para a primeira validação. Uma futura rota de saúde precisa de um bloqueio antes de colocar o evento na fila de saída. O servidor resolve a conta, confirma o destino, lê uma aprovação datada, valida os campos e verifica o estado de consentimento exigido. Informação ausente ou contraditória interrompe o envio. Não presuma que esse controle existe apenas porque as credenciais do Google foram configuradas.

  1. Resolver a conta autenticada e o formulário aprovado.
  2. Confirmar que o servidor recebeu um evento de formulário válido.
  3. Carregar o destino e a decisão vigente da clínica.
  4. Rejeitar campos proibidos ou inesperados.
  5. Confirmar que a rota é a única fonte primária.
  6. Criar o registro de saída só depois de todas as verificações.

O consentimento não substitui uma restrição da plataforma. Uma resposta de sucesso da API também não prova autorização jurídica. Registre a data e as fontes da decisão. Reavalie essa decisão quando a clínica alterar serviços, campos, texto de consentimento, titularidade da conta ou objetivos de conversão.

Passo 5: reconcilie a entrega

Mantenha um registro interno com os estados na fila, enviado, falhou e suprimido de forma intencional. Trate o sucesso do transporte apenas como evidência de que a requisição saiu do seu sistema, não como prova de autorização jurídica ou de registro nos relatórios posteriores. Uma nova tentativa mantém a mesma referência para não criar outra conversão primária.

Quando a entrega externa for permitida, a reconciliação responde se o evento liberado chegou uma vez ao destino correto. Ela não deve expor o formulário original. Guarde classes de erro e contagens, não conteúdo sensível rejeitado. Teste com envios sintéticos e confirme que o navegador não faz requisições diretas ao Google ou à Meta.

O relatório também deve separar o envio do formulário dos resultados posteriores. O artigo sobre taxa de comparecimento sem detalhes da consulta mostra como tratar uma fase posterior de forma agregada.

Erros comuns de arquitetura

  • Enviar o objeto completo do formulário porque ele já existe no servidor.
  • Manter uma tag antiga de conversão ao lado do evento server-side.
  • Classificar clique, ligação telefônica ou mensagem como envio de formulário.
  • Usar e-mail, telefone, agendamento ou tratamento como chave de deduplicação.
  • Ativar audiências porque a Data Manager também oferece essa função.
  • Tratar uma requisição aceita como prova de conformidade.

A arquitetura mínima tem um contrato de formulário, um ponto de decisão no servidor, um destino e um registro de reconciliação. Se o formulário recebe tráfego do Perfil da Empresa, documente também quem controla o link de agendamento no Google. Uma segunda rota só faz sentido quando existe uma necessidade documentada que a primeira não consegue atender.

Perguntas frequentes

Esta arquitetura instala uma tag Google no formulário?

Não. O navegador envia o evento para um endpoint próprio. A rota aprovada no servidor trata da entrega via Data Manager. Não existe chamada direta de conversão por gtag ou fbq.

A mesma rota pode criar audiências da clínica?

Não. O desenho limita-se a eventos de conversão aprovados. Ele não cria ou atualiza Customer Match, audiências do anunciante ou segmentos de remarketing.

A clínica pode enviar contato de paciente com hash?

Não neste limite. O hash não remove o contexto de saúde nem transforma o dado de contato em informação sem risco. Identificadores de pacientes ficam fora do payload.

O que acontece quando política ou consentimento não estão claros?

Não ative a saída. A clínica pode usar relatórios agregados no próprio ambiente enquanto o responsável, a revisão de privacidade e o aconselhamento qualificado avaliam a política vigente e o uso pretendido.

Referências