RD Station + Meta Ads: integração de ponta a ponta

Integrar RD Station ao Meta Ads de ponta a ponta significa não só capturar leads, mas enviar de volta ao Meta o evento de oportunidade ganha via Conversions API — para o algoritmo otimizar por venda real. A integração nativa do RD cobre a captura; para o retorno da venda, usa-se uma automação com webhook, geralmente via Make como camada de tratamento. É o que transforma o RD Station de um repositório de leads num sensor de receita que alimenta a mídia.

Se você ainda otimiza campanhas de Meta por preenchimento de formulário, comece por entender por que o CPL engana no B2B. Aqui, o foco é a mecânica específica do RD Station — que tem particularidades que o HubSpot não tem.

O que a integração nativa faz e não faz

O RD Station tem uma integração oficial com o Meta que cobre bem duas coisas: receber leads de Lead Ads (formulários dentro do Facebook/Instagram) direto na base, e sincronizar listas de público para segmentação. Isso é útil e vale ativar.

O que ela não faz de forma robusta é o inverso: enviar eventos de fundo de funil — oportunidade qualificada, oportunidade ganha — de volta ao Meta via Conversions API. E é justamente esse fluxo de retorno que muda a qualidade da otimização, porque é ele que ensina o algoritmo a diferença entre um lead qualquer e um comprador.

A arquitetura que funciona

O fluxo completo tem quatro pontos:

1. Captura do fbc no formulário. Todo formulário do site salva o fbclid da URL num campo personalizado do lead no RD. Sem isso, o match com o clique original despenca depois de alguns dias.
2. Automação no RD Station. Uma automação dispara quando a oportunidade muda para "ganha" (ou "qualificada", conforme o volume). A ação é "Enviar webhook".
3. Make como tradutor. O webhook chega ao Make, que normaliza os dados, aplica o hash SHA256 no email e no telefone, monta o payload no formato da CAPI e o envia.
4. Conversions API do Meta. O evento chega ao Gerenciador de Eventos como "Purchase" (ou evento customizado) com fonte "Servidor", amarrado ao clique via fbc.

Para a parte técnica do payload — endpoint, campos obrigatórios, hash, event_id — o detalhamento está em Meta CAPI: guia de configuração passo a passo. Aqui vale focar no que é específico do RD.

Por que o Make entra no meio

O webhook do RD Station envia um JSON com os dados da oportunidade, mas você tem pouco controle sobre o formato — e a CAPI é exigente. O email precisa ir em SHA256 lowercase; o telefone em SHA256 no formato E.164 sem símbolos; o fbc em texto puro; o valor no lugar certo do custom_data. O RD sozinho não faz esse tratamento.

O Make recebe o webhook cru do RD e faz o trabalho de tradução: pega o email, normaliza, aplica o hash; pega o telefone, limpa, formata, aplica o hash; monta o objeto user_data; adiciona o valor da oportunidade em custom_data; e faz o POST para o endpoint da CAPI. É uma cenário de 4 ou 5 módulos, roda em segundos, e custa pouco no plano gratuito ou básico do Make.

"Dá para fazer sem o Make, escrevendo uma função serverless. Mas para a maioria das operações, o Make resolve em uma tarde o que uma integração customizada levaria uma semana — e qualquer pessoa do time consegue dar manutenção depois."

O problema do volume no B2B

O maior limitador não é técnico, é estatístico. O Meta precisa de cerca de 50 eventos de conversão por semana para estabilizar a otimização. Uma operação B2B que fecha 15 negócios por mês nunca chega lá enviando só "oportunidade ganha".

A saída é enviar um evento intermediário de maior frequência como sinal principal — normalmente a passagem de MQL para SQL, ou "oportunidade criada". Você atribui a esse evento um valor proporcional: se a taxa histórica de fechamento de uma oportunidade qualificada é 20% e o ticket médio é R$ 50 mil, o valor do evento é R$ 10 mil. Assim o algoritmo tem volume para aprender e ainda pondera por valor esperado.

Ordem de implementação

Não tente ligar tudo de uma vez. A sequência que reduz erro:

1. Ativar a captura do fbc nos formulários e confirmar que chega no RD.
2. Montar o cenário no Make e testar com um disparo manual, checando o EMQ no Gerenciador de Eventos.
3. Ligar a automação do RD apontando para o evento intermediário (mais volume, valida o fluxo rápido).
4. Depois de estável, adicionar o evento de oportunidade ganha com o valor real.
5. Migrar a estratégia de lance do Meta para otimizar pelo evento de venda.

LGPD: o ponto que não pode passar

Enviar dados de contato de leads para o Meta — mesmo em hash — é compartilhamento com terceiro para fins de publicidade. Isso precisa estar coberto na sua base legal e na política de privacidade, e o consentimento do titular precisa estar registrado. O RD Station tem campos de consentimento; garanta que o fluxo só envia dados de leads que consentiram. É requisito, não detalhe.

Perguntas frequentes sobre RD Station + Meta Ads

A integração nativa serve para otimizar por venda?

Não completamente. A nativa cobre captura de Lead Ads e sincronização de públicos, não o envio de venda fechada via CAPI. Para otimizar por oportunidade ganha, você precisa de uma automação com webhook, geralmente via Make.

Por que usar o Make no meio?

O RD dispara webhooks, mas tem controle limitado sobre o payload e não faz o hash SHA256 exigido pela CAPI. O Make recebe o webhook, normaliza, aplica o hash, monta o payload correto e envia ao Meta — funciona como camada de tradução.

Qual evento do RD enviar?

Idealmente "oportunidade ganha". Mas com poucos fechamentos/mês, envie também um evento intermediário de maior frequência (oportunidade qualificada) com valor proporcional à probabilidade de fechamento, para dar volume ao algoritmo.

Preciso guardar o fbc no RD?

Sim — é o que mais aumenta o match rate. Capture o fbclid da URL num campo personalizado do lead. Como a venda fecha meses depois, o cookie do navegador já expirou; ter o fbc salvo permite enviá-lo com o evento de venda e amarrar ao clique original.