Conversions API para clínicas: como enviar pagamentos reais ao Meta e ao Google Ads

Resumo

a Conversions API (CAPI) da Meta e a importação de conversões offline do Google Ads permitem que o CRM da clínica avise às plataformas de anúncio o que aconteceu depois do clique: quem agendou, quem compareceu, quem aceitou o orçamento e quem pagou, com o valor real. Com esses sinais, o algoritmo deixa de otimizar para quem apenas preenche formulários e passa a buscar pessoas com perfil de quem se torna paciente. Para a clínica, isso significa menos leads que não fecham. Para a agência, significa poder provar o retorno com faturamento, e não com volume de leads.

Por que o pixel sozinho não basta em uma clínica

O pixel da Meta e a tag do Google medem o que acontece no navegador: visita à página, clique no botão de WhatsApp, envio de formulário. Para um e-commerce, isso cobre boa parte da jornada, porque a compra acontece no próprio site. Em uma clínica, a jornada é diferente. O paciente vê o anúncio, preenche o formulário ou chama no WhatsApp, conversa com a secretária, agenda, vai (ou não vai) à consulta, recebe um orçamento e paga presencialmente. Quase tudo o que importa acontece fora do navegador.

Há ainda limitações técnicas que afetam até o que o pixel consegue ver: bloqueadores de anúncio, restrições de rastreamento em navegadores e sistemas operacionais e perda de cookies. Por isso, as plataformas recomendam complementar o pixel com o envio de eventos direto do servidor, o que a Meta chama de Conversions API.

O efeito prático de depender só do pixel é conhecido de quem gerencia contas de clínicas. A plataforma otimiza para o evento que consegue medir, geralmente o lead. E o lead mais fácil de gerar nem sempre é o que paga. A campanha parece ótima no gerenciador, com custo por lead baixo, e péssima no caixa da clínica.

O que é a Conversions API e o que são as conversões offline

A Conversions API da Meta é uma forma de o servidor da empresa enviar eventos diretamente à Meta, sem passar pelo navegador do usuário. No caso de uma clínica, quem envia é o CRM. Cada vez que algo relevante acontece (lead capturado, consulta agendada, pagamento registrado), o sistema monta um evento com os dados necessários e o transmite.

O equivalente no Google Ads é a importação de conversões offline, que permite subir conversões ocorridas fora do site e associá-las ao clique original, normalmente por meio do identificador de clique do Google (o gclid). Você encontra a explicação oficial na página de ajuda sobre importação de conversões offline.

Nos dois casos, a lógica é a mesma: o CRM conhece o desfecho comercial, a plataforma conhece o clique, e o evento une as duas informações.

Os eventos que importam na jornada de uma clínica

Nem todo evento precisa ser enviado. O que importa é mapear os momentos da jornada que representam progresso real e associá-los aos eventos que as plataformas entendem.

No Google Ads, cria-se uma ação de conversão para cada etapa que se queira otimizar, como lead, agendamento, visita e venda.

O ponto central é o evento de pagamento com valor em reais. É ele que permite otimizar campanhas por retorno sobre o investimento (ROAS) e não apenas por quantidade de conversões. Se a clínica só puder implementar um evento além do lead, que seja esse.

Um cuidado de método: quanto mais adiante na jornada o evento estiver, menos volume ele terá. Uma clínica pequena pode não gerar conversões de pagamento suficientes para a plataforma aprender rapidamente. Nesse caso, uma estratégia comum é otimizar a campanha para um evento intermediário, como o agendamento, e usar o pagamento para análise e para alimentar audiências de público semelhante, aumentando a exigência conforme o volume cresce.

Como um evento é construído: os dados que a plataforma precisa

Um evento de conversão precisa dizer à plataforma o que aconteceu, quando aconteceu, com quem e, se possível, de qual clique veio. Na prática, ele carrega quatro grupos de informação.

O que e quando. O nome do evento, a data e a hora exatas em que ocorreu e, para eventos com valor, o valor e a moeda (no caso, BRL).

A origem do evento. A Meta pede que se informe de onde vem o evento, por meio do campo de fonte da ação. Para eventos gerados por um sistema interno, como o registro de pagamento no caixa, usa-se o valor que indica evento gerado pelo sistema. Se preferir, também é possível classificar como loja física, quando o evento representa atendimento presencial. O importante é ser consistente e verdadeiro na classificação.

Quem é a pessoa. Aqui entram os identificadores que permitem à plataforma reconhecer o usuário: e-mail, telefone, nome e sobrenome, além dos identificadores de clique, como o fbclid da Meta e o gclid do Google, quando existirem. Quanto mais identificadores válidos, maior a chance de a plataforma associar o evento a um usuário real. Na Meta, isso se reflete na chamada qualidade de correspondência do evento.

Como evitar duplicidade. Se a clínica usa pixel e Conversions API ao mesmo tempo, o mesmo evento pode chegar duas vezes. Para a plataforma reconhecer que se trata da mesma ocorrência, os dois envios devem carregar o mesmo identificador de evento. É um detalhe simples de implementar e que evita relatórios inflados.

A lista completa e atualizada de parâmetros está na documentação de parâmetros da Conversions API, que vale consultar antes de implementar, porque os requisitos evoluem.

Hash e normalização: como os dados pessoais são protegidos

Nenhum dado de contato viaja em texto aberto. Antes do envio, cada identificador passa por dois passos: normalização e hash.

A normalização padroniza o formato. O e-mail é convertido para minúsculas e sem espaços. O nome é convertido para minúsculas. O telefone é reduzido a dígitos, incluindo o código do país (no Brasil, 55) e o DDD.

O hash aplica a função criptográfica SHA-256, que transforma o dado em uma sequência que não pode ser revertida de forma direta. A plataforma faz o mesmo cálculo com os dados que ela já possui e compara os resultados. Se coincidirem, reconhece o usuário. Se não, descarta.

Um detalhe que costuma causar erro: a normalização deve seguir exatamente o que cada plataforma especifica, porque um hash calculado sobre um dado formatado de forma diferente nunca vai coincidir. No caso do telefone, por exemplo, a Meta espera apenas dígitos com o código do país, sem sinais como o "+". Se o CRM converte o número para o formato internacional com o sinal de mais antes de aplicar o hash, vale conferir com a documentação e testar, porque isso pode reduzir silenciosamente a taxa de correspondência.

O que nunca deve ser enviado: saúde e publicidade

Esta é a seção mais importante para quem trabalha com marketing médico, e a que mais separa uma operação segura de uma arriscada.

Dados clínicos não trafegam. Diagnósticos, CID, prontuários, prescrições, fotos, laudos e evolução clínica ficam dentro do sistema da clínica. Para as plataformas, seguem apenas eventos comerciais (agendou, compareceu, pagou) e identificadores cadastrais com hash. Além de ser a postura correta do ponto de vista ético, é o que protege a clínica diante da Lei Geral de Proteção de Dados e das normas de sigilo profissional.

Nomes de eventos e de audiências também contam. As plataformas têm políticas que restringem o uso de informações de saúde em publicidade e em eventos enviados por empresas. Mesmo sem enviar um diagnóstico explícito, um evento personalizado com nome que revele uma condição de saúde (por exemplo, o nome de uma doença ou de um tratamento sensível) pode violar as regras e levar à limitação da conta ou do recurso. A recomendação prática é usar nomes genéricos e comerciais para os eventos, como Lead, Schedule e Purchase, e evitar campos de descrição do produto ou do serviço com nomes de procedimentos ou condições.

Consulte as políticas vigentes. As regras da Meta e do Google para saúde e para públicos personalizados mudam com frequência, e o que é permitido para um procedimento estético pode não ser para uma especialidade que trata condições sensíveis. Antes de ativar a integração, leia as políticas atuais de cada plataforma e valide o desenho com o jurídico da clínica. Lembre também que a publicidade médica tem regras próprias, como as da Resolução CFM nº 2.336/2023.

Este artigo é informativo e não substitui orientação jurídica.

Passo a passo: como implementar a integração

O caminho abaixo vale para uma clínica que já tem um CRM capaz de registrar origem, agendamentos e pagamentos.

Passo 1: registre a origem de cada lead

Toda a atribuição depende de saber de onde o paciente veio. No momento da captura, o CRM deve guardar a fonte (anúncio da Meta, anúncio do Google, WhatsApp, indicação, presencial), os parâmetros de campanha (UTMs) e os identificadores de clique, como fbclid e gclid. Sem isso, o evento de pagamento não consegue ser ligado ao anúncio que gerou o paciente.

Esse registro não precisa acontecer só por formulário. Quando o paciente clica em um anúncio no Instagram, no Facebook ou no Google e chega ao site ou ao Portal de Agendamento Online da clínica, o sistema pode capturar os parâmetros da campanha (utm_source, utm_campaign, fbclid e gclid) e associá-los ao contato. Assim, mesmo quem tenta agendar pelo site e desiste continua com a origem registrada, e pode receber remarketing depois.

Passo 2: capture o lead em tempo real

Formulários de anúncio da Meta e do Google podem enviar o lead para o CRM por webhook. Isso reduz o tempo de resposta e já grava os identificadores de origem. Como o webhook recebe dados de fora, ele precisa validar a autenticidade da requisição, seja por assinatura, seja por token, para evitar cadastros forjados.

Passo 3: configure as credenciais por clínica

Cada clínica tem sua própria conta de anúncios, seu pixel e suas credenciais. O CRM deve armazenar esses dados de forma segura, separados por clínica, com tokens criptografados. Em sistemas com várias clínicas na mesma base, o isolamento entre elas é requisito básico, e não um extra.

Passo 4: dispare os eventos a partir das ações reais

O evento deve nascer do fato, e não de um botão manual. Quando o pagamento é registrado no caixa, o sistema cria o evento de compra com o valor real. Quando a consulta é marcada na agenda, cria o evento de agendamento. Quando o paciente faz check-in, cria o evento de comparecimento. Cada evento entra em uma fila, com data, valor, identificadores e status.

Passo 5: use fila com retentativas

Chamadas a APIs externas falham por motivos banais: instabilidade, limite de requisições, token expirado. Um sistema robusto não descarta o evento quando isso acontece. Ele o mantém em uma fila com número de tentativas, intervalo entre elas e registro do erro, e só o marca como falho depois de esgotar as tentativas. Também é importante enviar os eventos o quanto antes, porque as plataformas aceitam eventos apenas dentro de uma janela de tempo limitada após a ocorrência (na Meta, em geral de até sete dias para a maioria dos casos, mas confirme na documentação vigente).

Passo 6: teste antes de ligar em produção

Tanto a Meta quanto o Google oferecem ferramentas de teste. Na Meta, é possível enviar eventos com um código de teste e vê-los no gerenciador de eventos em tempo real, sem que eles entrem nas campanhas. Aproveite essa etapa para checar se os identificadores estão chegando, se a qualidade de correspondência está aceitável e se não há eventos duplicados.

Passo 7: monitore continuamente

Uma integração que funcionou no primeiro dia pode parar de funcionar quando um token expira ou uma regra muda. Mantenha um registro de todos os eventos enviados, com status, resposta da API e mensagens de erro, e acompanhe a taxa de sucesso. Um painel de telemetria permite identificar rapidamente quando algo saiu do ar.

Alternativa manual: exportar a lista em CSV

Nem toda clínica ou agência está pronta para ligar a integração por API no primeiro dia. Uma alternativa é exportar as listas de pacientes em CSV, já com e-mail e telefone em formato protegido (hash SHA-256) no padrão aceito pela Meta e pelo Google, e subi-las manualmente como públicos personalizados. A exportação perde a automação (a lista só é atualizada quando alguém a exporta de novo) e não envia eventos de conversão, mas serve para testar o conceito e para clínicas com volume menor.

Como saber se está funcionando

Alguns sinais indicam que a retroalimentação está saudável. Os eventos aparecem no gerenciador de eventos da Meta com boa qualidade de correspondência. A quantidade de compras registradas na plataforma é coerente, ainda que não idêntica, com a quantidade de pagamentos no CRM. Não há duplicidade evidente. E, com o tempo, os custos por resultado nas campanhas otimizadas para eventos mais avançados passam a refletir a realidade do caixa.

Não espere que os números batam exatamente. As plataformas atribuem conversões com base em suas próprias janelas e regras, e nem todo paciente é encontrado por correspondência. O objetivo é que a direção e a ordem de grandeza façam sentido, e que o CRM continue sendo a fonte da verdade para faturamento.

O que muda para a agência e para a clínica

Para o gestor de tráfego, a mudança mais importante é poder otimizar campanhas por um resultado que se aproxima do negócio. A conversa com o cliente passa de "geramos leads" para "esta campanha gerou tanto de faturamento, com tal taxa de comparecimento". Nesse cenário, um perfil de acesso restrito ao módulo de marketing é essencial: o gestor vê o funil comercial e as métricas de campanha, sem acesso a fichas de pacientes ou prontuários.

Para a clínica, o benefício é deixar de pagar por leads que nunca viram consulta e passar a enxergar a origem do faturamento. A partir da integração, abre-se também o módulo de Segmentações & Públicos de Anúncios, com públicos de remarketing, de semelhança, de reativação e de exclusão construídos com dados reais, tema do artigo sobre remarketing para clínicas médicas. A Doctte reúne esse ciclo no mesmo sistema de gestão, e você encontra os demais recursos na página de benefícios.

Erros comuns na integração

O primeiro é normalizar os dados de forma diferente da exigida, o que derruba a correspondência sem gerar erro visível. O segundo é enviar apenas o e-mail, deixando de fora telefone e identificadores de clique, quando o lead veio pelo WhatsApp e o e-mail nem existe. O terceiro é registrar o evento de pagamento sem valor, o que anula a otimização por ROAS. O quarto é duplicar eventos por usar pixel e API sem identificador de evento em comum. O quinto é enviar dados sensíveis por descuido, como nomes de procedimentos ou condições em campos livres. E o sexto é não monitorar, descobrindo semanas depois que os envios estavam falhando.

Perguntas frequentes

O que é a Conversions API da Meta? É uma forma de o servidor de uma empresa enviar eventos de conversão diretamente à Meta, sem depender do navegador do usuário. Em uma clínica, o CRM envia eventos como agendamento e pagamento.

Preciso da Conversions API se já uso o pixel? O pixel continua útil, mas mede apenas o que acontece no navegador. Como a maior parte da jornada de uma clínica ocorre fora do site, a API complementa a medição com eventos reais do CRM.

Como o Google Ads recebe conversões que aconteceram na clínica? Por meio da importação de conversões offline, que associa a venda ao clique original usando o identificador de clique (gclid), guardado pelo CRM no momento da captura do lead.

Os dados dos pacientes ficam expostos ao enviar eventos? Não em texto aberto. E-mail, telefone e nome passam por normalização e hash SHA-256 antes do envio. Dados clínicos, como diagnóstico, CID e prontuário, nunca devem ser enviados.

Qual é o evento mais importante para uma clínica? O evento de pagamento com valor real, porque informa às plataformas quanto cada campanha gerou de receita e permite otimizar por retorno sobre o investimento.

Por que os números da Meta e do CRM não batem exatamente? Porque as plataformas usam janelas e regras próprias de atribuição e nem todo paciente é encontrado pela correspondência dos identificadores. O CRM permanece como fonte de verdade do faturamento.

Clínicas pequenas conseguem usar a otimização por pagamento? Dependem de volume. Com poucas conversões, costuma ser melhor otimizar para um evento intermediário, como o agendamento, e usar os pagamentos para análise e para audiências.

Que cuidados devo ter com as políticas de saúde das plataformas? Use nomes genéricos para eventos, evite descrever procedimentos ou condições nos parâmetros, leia as políticas vigentes da Meta e do Google e valide o desenho com o jurídico.

Quanto tempo depois do pagamento o evento deve ser enviado? O quanto antes. As plataformas aceitam eventos dentro de uma janela limitada, então uma fila com retentativas e monitoramento evita perdas.