CRM próprio + CAPI: como blindar atribuição quando a BM cai

A BM caiu. Você abriu recurso, recebeu o e-mail genérico da Meta, e está esperando. O que a maioria dos gestores descobre nesse momento, da forma mais cara possível, é que o problema não é só campanhas pausadas — é que a atribuição parou junto. Sem pixel ativo, sem eventos chegando, o algoritmo esquece. Quando a estrutura volta (ou quando você sobe uma nova), o pixel novo começa do zero: sem histórico de purchase, sem audiência custom, sem lookalike calibrado. O re-aquecimento leva de 7 a 30 dias, e nesse período CPM sobe, ROAS afunda, e o orçamento que você teria rodando normal está sendo queimado em aprendizado.

Existe um jeito de não passar por isso. Operações que sobrevivem bem a quedas de BM têm uma coisa em comum: CRM próprio mandando eventos pra Conversions API com identificadores estáveis. Quando a BM cai, eles simplesmente trocam o pixel de destino no CAPI, revalidam o token, e em 24 horas o novo pixel já recebe todos os eventos que o CRM estava trackando. Sem perda de histórico de evento. Sem re-aquecimento do zero.

Esse post documenta a arquitetura, a lógica de event_id, as matching keys que fazem diferença, e como configurar isso na stack BR mais comum — Hotmart, RD Station, ActiveCampaign. Se você já opera com pixel só via browser, leia com atenção: essa é a mudança de infraestrutura que separa operação que para de operação que continua.

O que morre quando a BM cai (e o que não precisa morrer)

Quando uma BM é desativada, a Meta bloqueia acesso ao gerenciador, às contas de anúncio, e — o ponto que a maioria esquece — invalida os tokens de acesso associados a essa BM. Token de CAPI é vinculado a um pixel, que é vinculado a uma BM. BM desativada, token inválido. Os eventos que o seu servidor estava mandando passam a retornar erro 403 ou 190 (token expirado/inválido), e o fluxo para silenciosamente se você não tiver alertas configurados.

O pixel em si não desaparece da face da terra — ele fica preso dentro da BM bloqueada. Você não consegue transferi-lo pra outra BM facilmente (Meta não permite migração de pixel entre BMs de forma nativa). Então na prática, pixel = morreu junto com a BM.

O que não precisa morrer é a fonte de dados que alimentava esse pixel. Se os eventos de conversão estavam chegando só via pixel browser (fbq), aí sim você perdeu tudo: sem pixel ativo, sem coleta. Mas se os eventos estavam sendo disparados pelo seu CRM via CAPI server-side, a fonte de verdade está no seu servidor, não na BM. Você cria novo pixel em nova BM, gera novo token, aponta o CRM pra esse novo destino, e os eventos voltam a fluir.

Essa é a distinção crítica: pixel browser = dado que mora na Meta; CAPI via CRM = dado que mora em você.

Arquitetura que sobrevive a queda de estrutura

A arquitetura básica tem três camadas:

Camada 1 — Coleta no CRM Seu CRM (Hotmart, RD Station, ActiveCampaign, Shopify, sistema próprio) é o ponto central de registro de eventos. Cada lead captado, cada venda processada, cada evento de funil (lead, adicionou ao carrinho, iniciou checkout, purchase) é gravado no CRM com identificadores do contato: email com hash SHA-256, phone com hash SHA-256, e quando disponível, nome, cidade, CEP.

Camada 2 — Event gateway / middleware Um serviço intermediário (pode ser sua própria função Lambda/Cloud Function, pode ser n8n, Zapier, Make, ou SDK nativo do CRM) recebe o evento do CRM e formata o payload correto pra CAPI. Aqui fica a lógica de event_id, deduplicação, e routing: qual pixel recebe o evento.

Camada 3 — CAPI endpoint da Meta O endpoint graph.facebook.com/{version}/{pixel_id}/events recebe o payload formatado. O pixel_id e o access_token são configurações mutáveis — são as únicas duas coisas que mudam quando você troca de BM.

Com essa arquitetura, trocar de BM é alterar duas variáveis de ambiente. O resto continua igual.

Diagrama simplificado do fluxo

• Usuário converte (compra, lead, checkout) → evento registrado no CRM
• CRM dispara webhook pro seu middleware
• Middleware formata payload CAPI (event_name, event_time, event_id, user_data com hashes, custom_data)
• Middleware envia POST pra graph.facebook.com/{version}/{pixel_id}/events com access_token
• Meta recebe, processa, deduplica com evento browser se houver
• Se BM cai: troca pixel_id e access_token no middleware → fluxo continua

Event_id: a peça que a maioria ignora

O event_id é o campo mais subestimado da CAPI. A função dele é simples: deduplicação entre pixel browser e CAPI server-side. Se você dispara o mesmo evento pelos dois canais (o fbq no browser E o CRM no servidor), a Meta usa o event_id pra entender que é o mesmo evento e contar só uma vez.

Mas event_id tem uma segunda função menos documentada: ele serve como identificador estável de evento no seu sistema. Se você gera event_id com lógica determinística baseada nos dados da transação, você pode reenviar eventos de períodos passados sem criar duplicatas na Meta.

Isso tem implicação direta pra portabilidade de pixel: quando você aponta o CAPI pra novo pixel, pode reenviar os últimos 7 dias de eventos (a Meta aceita eventos com até 7 dias de atraso) e o novo pixel já começa com histórico recente.

Como gerar event_id estável

A estratégia mais comum é compor o event_id a partir de dados que identificam unicamente o evento:

event_id = SHA256(order_id + event_name + user_email)

Exemplo: se o pedido é PED-00192, o evento é Purchase, e o email é cliente@dominio.com, o event_id fica:

SHA256("PED-00192PurchaseXXXXX") = string hexadecimal única

Qualquer reenvio desse mesmo evento vai gerar o mesmo event_id, e a Meta vai reconhecer como duplicata e ignorar. Você pode reenviar sem medo.

Para eventos sem ID de transação (Lead, ViewContent, AddToCart), use o identificador de sessão ou o ID do contato no CRM:

event_id = SHA256(crm_contact_id + event_name + unix_timestamp_truncado_a_hora)

O timestamp truncado a hora evita que múltiplos eventos do mesmo tipo na mesma hora se cancelem — só dentro da mesma hora é considerado duplicata.

Matching keys: o que realmente aumenta taxa de match

A taxa de match do CAPI (quanto % dos eventos a Meta consegue atribuir a uma conta de usuário real) é o que determina a qualidade do dado que o pixel recebe. Pixel browser tem taxa de match natural de 60-80% (depende de cookies, navegador, iOS 14.5+). CAPI com matching keys bem configuradas pode chegar em 85-95%.

As matching keys prioritárias, em ordem de impacto:

1. Email hash (SHA-256 lowercase sem espaços) Maior impacto isolado. A Meta tem o email da maioria das contas. Se você manda email corretamente hashado, a taxa de match sobe imediatamente.

Atenção ao pre-processing: email deve ser lowercase e sem espaços antes do hash. Cliente@Email.Com vira cliente@email.com antes de hashear. Erro aqui é silencioso — o hash chega mas não faz match.

2. Phone hash (SHA-256 formato E.164) No Brasil, isso significa +55 + DDD + número. (11) 99999-9999 vira +5511999999999 antes de hashear. Meta cruza com o número de WhatsApp/Instagram da conta, então matching com phone BR tem taxa alta.

3. External_id Qualquer identificador único que você usa nos dois sistemas (pixel browser e CAPI). Pode ser o ID do contato no CRM, o ID do pedido, qualquer string. A Meta usa pra cruzar eventos browser e server-side do mesmo usuário. Se seu pixel browser já manda fbq('set', 'autoConfig', false) com external_id, e o CAPI manda o mesmo external_id, a deduplicação fica precisa.

4. FBC e FBP São os cookies _fbc e _fbp que o pixel browser seta no navegador do usuário. Se sua landing captura esses cookies e os passa pro CRM no momento do lead (via hidden field no formulário, ou via JavaScript no form submit), você pode incluir no payload CAPI. Isso melhora matching especialmente em Mobile.

5. IP e User Agent Coletados no momento da conversão e passados pro CAPI aumentam matching para usuários sem cookie. Importante em fluxos onde a conversão acontece em ambiente sem acesso a cookies (ex: pagamento via PIX assíncrono, confirmação de pedido por email).

Stack mínimo que funciona bem:

• email + phone + external_id

Stack que leva matching a 90%+:

• email + phone + external_id + fbc + fbp + ip + user_agent

Setup por plataforma BR

Hotmart

Hotmart tem integração nativa com Meta CAPI via painel (Configurações → Integrações → Meta Pixel). O problema da integração nativa é que ela envia eventos com matching keys limitadas — geralmente só email — e não te dá controle sobre o event_id.

Para o setup que sobrevive a queda de BM, o caminho correto é usar os webhooks do Hotmart (Configurações → Ferramentas → Webhooks) e processar os eventos no seu middleware:

• Evento PURCHASE_APPROVED → dispara evento Purchase no CAPI
• Evento PURCHASE_BILLET_PRINTED → dispara InitiateCheckout
• Evento PURCHASE_CANCELED → não dispara (ou dispara evento custom pra segmentação negativa)

O payload do webhook Hotmart já inclui email do comprador, produto, valor, ID da transação. Com isso você tem tudo pra formatar o payload CAPI correto com event_id determinístico baseado no ID da transação.

Ponto de atenção: Hotmart não entrega phone do comprador no webhook por padrão (privacidade). Se precisar, via API do Hotmart é possível buscar dados complementares do subscriber, mas adiciona latência. Para a maioria das operações, email + transaction_id é suficiente.

RD Station

RD Station Marketing tem dois pontos de integração úteis:

Automações (fluxos de automação) Você pode configurar uma automação que, quando contato entra em determinado estágio (ex: tag lead-qualificado, ou campo status = comprou), dispara um webhook pro seu middleware. O payload inclui email, telefone, e todos os campos custom que você configurou.

Isso é útil pra eventos de funil médio-alto: Lead qualificado, Oportunidade aberta, Venda fechada.

RD Station CRM (se usar junto com o Marketing) O CRM da RD tem webhook nativo por mudança de estágio de deal. Você pode apontar esse webhook pro middleware e disparar eventos CAPI baseados no pipeline de vendas:

• Deal movido pra Proposta enviada → evento Lead no CAPI
• Deal movido pra Fechado ganho → evento Purchase no CAPI

O event_id aqui usa o ID do deal (único no sistema) + event_name.

Ponto de atenção RD: telefone no RD fica em formato variado (usuários inserem como quiserem). Antes de hashear, normalize: tira caracteres especiais, adiciona +55 se DDD brasileiro, valida que tem 11 dígitos. Um script de normalização mal feito vai hashear telefone errado silenciosamente e perder matching.

ActiveCampaign

ActiveCampaign tem dois mecanismos: webhooks e automações com HTTP Request (plano Plus em diante).

Webhooks Configurado em Configurações → Desenvolvedor → Webhooks de contato. Você pode triggar em eventos como:

• contact_tag_added — quando tag específica é adicionada
• deal_stage_changed — quando deal muda de estágio
• form_submitted — quando formulário é submetido

Automação com HTTP Request (mais flexível) Cria automação que, quando contato entra numa lista/tag específica, executa uma ação de HTTP Request POST pro seu middleware. Você controla exatamente quais campos mandar (email, phone, custom fields, deal value).

ActiveCampaign tem um campo nativo %EMAIL% e %PHONE% que você usa no payload da automação. Se armazena lead_source via UTM em custom field, pode incluir no CAPI como custom_data para enriquecer o evento.

Ponto de atenção ActiveCampaign: o endpoint de HTTP Request nativo não suporta SHA-256 hashing inline. Ou você hasha no middleware ao receber, ou usa uma função Lambda/Cloud Function intermediária que recebe o dado em claro, hasha, e só então manda pra CAPI. Nunca mande dados em claro diretamente pro endpoint da Meta — isso viola LGPD e os termos da própria Meta.

Shopify (e-commerce)

Shopify tem integração CAPI nativa via canal Facebook & Instagram (Shopify App Store). A integração nativa já faz matching decente, mas tem o mesmo problema: pixel_id e token são configurados dentro da integração, e você não controla event_id.

Para operações que precisam de portabilidade de pixel, o setup recomendado é:

1. Manter a integração nativa desativada (ou ativa como backup)
2. Usar os webhooks do Shopify (Admin → Configurações → Notificações → Webhooks) pra eventos de order:
   • orders/paid → Purchase
   • checkouts/create → InitiateCheckout
   • orders/create → AddToCart (se checkout single-page)
3. Processar via middleware com event_id = SHA256(order_number + event_name)

O payload do webhook de order do Shopify inclui email, telefone (se preenchido no checkout), IP do cliente, e browser user agent — matching keys completas.

Deduplicação: evitando contar evento duas vezes

Se você roda pixel browser + CAPI simultaneamente (o setup ideal, porque redundância é bom), a Meta pode contar o mesmo evento duas vezes: uma pelo browser, outra pelo servidor. Isso distorce métricas e pode inflar conversões reportadas.

A deduplicação funciona assim:

• Pixel browser dispara fbq('track', 'Purchase', {value: 199, currency: 'BRL'}, {eventID: 'SEU_EVENT_ID'})
• CAPI manda o mesmo evento com o mesmo event_id no campo correspondente
• Meta vê dois eventos com mesmo event_id, origem diferente (browser vs server), e conta como um só

O requisito é que o event_id seja idêntico nos dois lados. Pra isso funcionar no browser, você precisa gerar o event_id no servidor (ou com lógica determinística que o browser consiga replicar) antes de renderizar a página de confirmação.

Fluxo no e-commerce:

1. Pedido é criado → servidor gera event_id determinístico baseado no order_id
2. Página de confirmação carrega com event_id no data-layer ou variável JavaScript
3. GTM puxa o event_id e dispara fbq com ele
4. Servidor (via webhook CRM/Shopify) manda CAPI com o mesmo event_id

Na prática com GTM: variável de Data Layer eventID é pushada via dataLayer.push({eventID: 'HASH_AQUI'}) antes do evento de conversão, e a tag de pixel no GTM usa essa variável no campo eventID.

O que você tem que checar quando a BM cai

Se a BM caiu agora e você quer saber se tem estrutura CAPI pra aproveitar:

1. Confirma se tem CAPI ativo Vá no Events Manager do pixel que estava na BM (se ainda tiver acesso readonly). Filtro por Source = Server. Se mostra eventos chegando, você tem CAPI configurado.

2. Identifica de onde o CAPI está vindo Pode ser: integração nativa da plataforma (Hotmart, Shopify, RD), código custom no servidor, middleware próprio. Olha configurações de integração das suas plataformas.

3. Verifica onde está o access_token O token está guardado em alguma variável de ambiente, config file, ou painel da integração. Você vai precisar trocar esse token pelo token do novo pixel.

4. Cria novo pixel em nova BM Se está usando uma BM cedida (estrutura operacional paralela) ou criou nova BM, cria novo pixel lá dentro. Events Manager → Conectar fontes de dados → Web → Conversions API → gera access_token.

5. Troca pixel_id e access_token Onde quer que esteja configurado (variável de ambiente, painel da integração, código), troca os dois valores. Faz um evento de teste manual pra confirmar que está chegando no novo pixel.

6. Reenvia últimos 7 dias (opcional mas recomendado) Se o seu middleware/CRM tem histórico de eventos, formata um batch dos últimos 7 dias com os event_ids originais e envia pro novo pixel. Ele vai começar com histórico de conversões recentes, encurtando o re-aquecimento de 30 dias pra 1-3 dias.

Quanto histórico o novo pixel precisa pra sair do aprendizado rápido

No contexto de Advantage+ (que em 2026 é o padrão pra quem escala), o algoritmo precisa de volume de eventos pra sair da fase de exploração e entrar em entrega eficiente. A Meta fala em 50 eventos de otimização por semana como mínimo pra campanhas de conversão, mas na prática:

• Abaixo de 50 purchases/semana no pixel: algoritmo em exploração constante, CPM alto
• 50-200 purchases/semana: aprendizado razoável, estabiliza em 7-10 dias
• Acima de 200 purchases/semana: pixel aquecido rapidamente, 3-5 dias

Com o reenvio de 7 dias de eventos históricos, se a operação tinha volume de 30-50 purchases/dia, o novo pixel começa com 200-350 eventos na janela de aprendizado e entra em ritmo normal em 2-3 dias em vez de 2-3 semanas.

Isso é o que torna o CAPI via CRM uma infra estratégica, não só técnica.

O que fazer se não tem CRM com CAPI hoje

Se você está lendo isso com a BM caída e não tem CAPI configurado via CRM, a situação de atribuição é mais difícil. Mas não é sem saída.

Dados que você provavelmente tem:

• Planilha ou banco de dados de vendas com email dos compradores
• Histórico de pedidos no Shopify, Hotmart, ou sistema próprio
• Leads exportados do formulário com email e telefone

O que você pode fazer com esses dados:

• Criar audiência custom via upload de customer list no novo pixel (CSV com email + telefone hasheados ou em texto que a Meta hasha na importação)
• Essa audiência não injeta eventos históricos, mas reconstitui base de exclusão (ex: excluir quem já comprou) e base pra lookalike
• Lookalike de customer list, mesmo sem histórico de eventos, já começa com sinal de qualidade se a lista for de compradores reais com bom matching

Essa abordagem recupera parte da eficiência, não toda. A diferença de CPM entre pixel aquecido por eventos CAPI vs lookalike de customer list sem histórico de evento é real — na prática, de 20-40% de CPM mais alto no segundo caso.

O caminho certo é configurar CAPI via CRM antes de precisar, não depois.

Monitoramento: como saber que o CAPI parou

O pior cenário não é CAPI que nunca existiu. É CAPI que existia e parou silenciosamente — token expirado, BM bloqueada, endpoint com erro — e você ficou dias sem saber.

Alertamento mínimo pra operação séria:

• Webhook de erro no middleware: se POST pra CAPI retornar código != 200, dispara alerta no Slack/Telegram com o erro
• Monitor de volume de eventos no Events Manager: Meta mostra gráfico de eventos recebidos. Se cair pra zero, é sinal imediato
• Token com expiração longa ou indefinida: ao criar token no Events Manager, use a opção de token sem expiração (System User token), não o token de usuário pessoal que expira em 60 dias
• Checagem semanal de Event Match Quality: Events Manager → Configurações → Event Match Quality. Score abaixo de 6 significa que matching keys estão mal formatadas. Investiga.

Resumo do setup mínimo viável

Pra quem quer implementar isso hoje, o caminho mais rápido:

• Escolhe uma ferramenta de middleware: n8n (self-hosted, gratuito) ou Make/Zapier (mais rápido de configurar, pago)
• Conecta a plataforma BR que você usa (Hotmart webhook, RD automação, ActiveCampaign HTTP Request)
• No middleware: normaliza email (lowercase, sem espaços) e phone (E.164), aplica SHA-256, monta payload CAPI com event_id determinístico
• Testa com Event Test Tool no Events Manager antes de ligar em produção
• Guarda pixel_id e token em variáveis de ambiente ou secrets manager — não em código hardcoded
• Documenta o processo de troca de pixel em 2 páginas: o que muda, onde muda, como validar que funcionou

Com esse setup, uma queda de BM passa de evento catastrófico pra procedimento operacional de 1-2 horas.

Quando a BM cai e você não tem backup de estrutura operacional

Mesmo com CAPI portável, se você não tem onde subir campanha nova enquanto o recurso da BM antiga rola, a atribuição funcionando não resolve o problema de faturamento parado.

O CAPI em novo pixel só funciona se você tem campanha nova rodando pra capturar conversão. Sem conta de anúncio ativa, o pixel recebe dados mas não alimenta nenhuma campanha.

Enquanto a BM original não volta, a operação precisa de contas de anúncio funcionais, preferencialmente já dentro de uma estrutura com histórico. Subir conta nova do zero, no perfil pessoal, na mesma estrutura que caiu — esse é o erro que duplica o downtime.

Enquanto a BM caída não volta e o recurso está em análise, dá pra retomar gasto com contas de anúncio compartilhadas entregues dentro da sua BM (existente ou nova) via ADS FLOW — você aponta o CAPI já configurado pro pixel novo, e as campanhas voltam sem esperar a estrutura original se recuperar. Conversa: t.me/oadsflow.