Meta CAPI server-side

O plugin dispara eventos pra Meta Conversion API (CAPI) direto do servidor — sem depender do Pixel JS no navegador. Isso garante atribuição mesmo quando o visitante tem bloqueador de ads, iOS 14.5+ ou cookies de terceiros bloqueados.

Desde a v2.10.0, toda conversão carrega um event_id determinístico compartilhado entre CAPI, Pixel do navegador (opcional) e CRM — a mesma conversão nunca é contada duas vezes.

Por que server-side

Cenário	Pixel client-side	Meta CAPI server-side
Visitante com adblock	❌ Não dispara	✅ Dispara
iOS 14.5+ (ATT)	⚠ Limitado	✅ Normal
Cookies 3rd-party bloqueados	❌ Falha	✅ Funciona
Browser sem JS	❌ Falha	✅ Funciona
Reliability de match	~70%	90%+

O CAPI não substitui o Pixel — eles trabalham juntos com deduplicação (mesmo event_id em ambos). Você tem 3 caminhos possíveis:

Só CAPI (default) — plugin dispara o CAPI, sem Pixel no navegador. Simples, funciona com adblock.
CAPI + Pixel do navegador do próprio plugin — plugin dispara os dois com o mesmo event_id. Ideal se seu site ainda não tem Pixel via GTM.
Envio por servidor + Pixel próprio (via GTM ou outro) — o plugin manda pelo servidor e publica window.smart2_event_id mais um push smart2_conversion no dataLayer, para o seu GTM usar o mesmo identificador.

O que é disparado

Evento	Quando
`Lead` (nome padrão, configurável)	Toda submissão de formulário capturada pelo plugin
`Contact`	Clique em qualquer link de WhatsApp (`wa.me`, `api.whatsapp.com`)

Configurar

Pré-requisitos:

Pixel ID — número longo do seu Pixel no Meta Events Manager
Token de conversão — gerado no Gerenciador de Eventos da Meta, no seu Pixel, em Configurações → API de Conversões

A tela está dividida em duas partes

Desde a versão 2.9, a Meta não fica mais sob um título só. São duas seções, e elas fazem coisas diferentes:

Seção	O que é
Meta — Pixel do navegador	O pixel que dispara no navegador do visitante. Sempre parte do site
Meta — Envio por servidor (CAPI)	O envio que sai de servidor. Pode sair daqui ou do CRM

A separação existe porque antes tudo ficava sob “Meta CAPI” e parecia que sem CAPI não havia pixel.

Quem envia por servidor: o site ou o CRM

É a pergunta que a segunda seção responde, e ela responde na hora, na própria tela:

Token de conversão vazio → quem envia é o CRM
Token de conversão preenchido → quem envia é o site

Os dois caminhos funcionam. O do CRM costuma ser mais simples, porque a credencial já está lá e não precisa ser copiada para dentro do WordPress.

Quando é o site que envia, o envio pra Meta não depende do CRM: se o CRM estiver fora do ar, a Meta recebe do mesmo jeito e o lead fica na fila até o CRM voltar. Envio à Meta que falhar por rede ou erro do servidor também entra na fila. O lead parcial (pré-coleta) nunca vai pra Meta — só a conversão de verdade.

Configurar, quando o site é quem envia

Configurações → app.smart CRM → seção Meta — Pixel do navegador: preencha o Pixel ID.
Na seção Meta — Envio por servidor (CAPI):
- Marque Enviar pelo site
- Cole o Token de conversão, gerado no Gerenciador de Eventos da Meta em Configurações → API de Conversões
- Código de teste só enquanto você estiver testando. Em produção, vazio
Salve.

O token fica criptografado no banco, como os demais.

O nome do evento não é mais um campo só

Antes havia um “nome do evento” global, padrão Lead. Desde a 2.10 o nome é por evento, na seção Eventos que este site envia: cada tipo de conversão do site — cada formulário, o clique em WhatsApp, o abandono — pode ir para a Meta com um nome diferente.

O nome escolhido vale para os dois caminhos, o do navegador e o do servidor, e viaja junto mesmo quando quem envia é o CRM. Veja configuração.

Pixel do navegador (opcional)

Toggle default OFF. Quando ligada:

Plugin injeta um snippet leve no <head> do site que dispara fbq('track', '<nome_do_evento>', {...}, { eventID: '<event_id>' }) no navegador quando o formulário é enviado.
O event_id é o mesmo que o CAPI usa — Meta reconhece e conta uma única conversão.
Útil quando o site não tem Pixel próprio (via GTM, tema ou outro plugin).

Não ligue se o site já tem Pixel via GTM disparando Lead — nesse caso o mesmo evento seria disparado duas vezes no navegador (o do GTM + o do plugin) e contaria dobrado. Deixe OFF e integre o GTM ao smart2_event_id (veja abaixo).

Deduplicação — como funciona

A partir da v2.10.0, o plugin gera um event_id determinístico por conversão (SHA-256 de dados estáveis do evento). Esse ID é:

Enviado ao CAPI no campo event_id do payload
Enviado ao CRM para carimbar a conversão registrada
Publicado no navegador em window.smart2_event_id
Empurrado no dataLayer como o evento smart2_conversion (com o event_id dentro)
Enviado ao fbq() do próprio plugin (se o Pixel do navegador estiver ligado) via { eventID }

Resultado: Pixel + CAPI + CRM veem o mesmo event_id → Meta deduplica corretamente e o CRM não conta a mesma conversão duas vezes.

Integrando com GTM ou Pixel próprio

Se você já tem um Pixel próprio (via GTM, tema, outro plugin), mantenha o Pixel do navegador do plugin desligado e configure o seu Pixel a usar o event_id publicado pelo plugin:

No GTM:

Crie um Trigger do tipo Custom Event com nome smart2_conversion.
Crie uma Variable do tipo Data Layer Variable com nome event_id (Data Layer Variable Name: event_id).
Na sua Tag do Meta Pixel (evento Lead), no Event ID aponte para {{event_id}} (a variable criada).
Publique.

Agora o GTM dispara fbq com o mesmo event_id que o CAPI do plugin — Meta deduplica.

Direto no JavaScript:

<script>
  window.addEventListener('smart2:conversion', function(e) {
    if (typeof fbq === 'function') {
      fbq('track', 'Lead', {}, { eventID: e.detail.event_id });
    }
  });
</script>

Ou lendo direto de window.smart2_event_id no momento apropriado.

Que dados são enviados

Payload CAPI (exemplo `Lead`)

{
  "data": [{
    "event_name": "Lead",
    "event_time": 1719876543,
    "event_id": "a8c7f9e1d4b6...",
    "event_source_url": "https://seusite.com.br/contato",
    "action_source": "website",
    "user_data": {
      "em": ["<sha256(email)>"],
      "ph": ["<sha256(telefone só dígitos)>"],
      "external_id": ["<sha256(contact_id do CRM)>"],
      "client_ip_address": "189.123.45.67",
      "client_user_agent": "Mozilla/5.0 ...",
      "fbc": "fb.1.1719876543.IwAR1abc...",
      "fbp": "fb.1.1719876543.987654321"
    },
    "custom_data": {
      "currency": "BRL",
      "value": 0
    }
  }]
}

Para evento `Contact` (clique WhatsApp)

Mesma estrutura, com event_name: "Contact" e event_source_url apontando pra página onde o clique aconteceu.

Detalhes importantes

Hash dos dados pessoais

Email (em): convertido pra minúsculo + trim + SHA-256
Telefone (ph): só dígitos (sem +, sem espaço, sem hífen) + SHA-256
external_id: ID do contato no CRM, hasheado SHA-256 — permite ao Meta ligar essa conversão à mesma pessoa em outros eventos (do próprio CRM ou de outras integrações), melhorando o Event Match Quality (EMQ)
Outros campos como nome (fn, ln), data nascimento (db), gênero (ge) — não são enviados atualmente.

`fbc` e `fbp`

fbp: lido direto do cookie _fbp que o Pixel JS já grava no navegador
fbc: prioridade em cascata:
1. Cookie _fbc do próprio Pixel (se existir)
2. fbc reconstruído com o timestamp real do clique (persistido pelo tracker do plugin no first-touch)
3. Se nada acima existir mas houver fbclid na URL, constrói fb.1.{timestamp_atual}.{fbclid} — último recurso

O timestamp real do clique (não o do submit) é o que a Meta espera para atribuição correta.

IP e User Agent reais

IP do visitante: lido de X-Forwarded-For (primeiro IP válido) ou REMOTE_ADDR. Aceita IPv4 e IPv6. Enviado como client_ip_address.
User Agent do visitante: lido de HTTP_USER_AGENT. Enviado como client_user_agent.

Esses valores são encaminhados também ao CRM — importante quando o CRM também dispara o CAPI (ou outras integrações), para que os eventos usem os dados reais do visitante e não os do servidor.

Modo de teste

Pra validar antes de subir em produção:

Em Events Manager → seu Pixel → Test events.
Copie o Test Event Code (formato TEST12345).
Cole no campo Test event code das settings do plugin.
Faça uma submissão de form de teste no seu site.
No Events Manager → Test events, o evento aparece em segundos com Source: Server.
Se o Pixel do navegador estiver ligado, aparece também o evento Browser com o mesmo event_id — e o Meta os marca como deduplicados.

Quando estiver tudo OK, apague o test event code e salve. Eventos voltam ao modo de produção normal.

Verificar entrega

No Events Manager

Vá em Events Manager → seu Pixel → Test events (com test code ativo) ou Overview.
Faça uma submissão real.
Em 5-30 segundos, o evento deve aparecer com:
- Source: Server (e Browser se Pixel do navegador ligado)
- Match Quality (EMQ): idealmente “Great” (≥7) ou “Good” (5-6)
- Deduplication: Deduplicated (se ambos Source apareceram)

Score de match quality

Score	Significado	Como melhorar
Great (≥7)	Match forte com dados ricos	Manter como está
Good (5-6)	Match parcial	Garantir que `_fbp`/`_fbc` cookies existem (Pixel JS instalado no site)
Below Average	Match difícil	Verificar se email/phone estão sendo capturados do form + se o `external_id` do CRM está sendo devolvido no relay

O external_id (contact_id do CRM) empurrou o EMQ de muitos clientes de “Good” pra “Great” — sem ele, o Meta só tem email/phone hasheados. Com ele, tem também um identificador estável cross-plataforma.

No log do plugin

Toda chamada Meta CAPI é registrada em wp-content/uploads/smart2-logs/smart2-debug-*.log:

[2026-07-13 14:30:00] [INFO] Meta CAPI event sent {"event":"Lead","event_id":"a8c7f9e1...","status":200}
[2026-07-13 14:30:05] [ERROR] Meta CAPI HTTP error {"http_code":400,"body":"{...}"}

Erros mais comuns:

Erro Meta	Causa	Solução
`(#100) Invalid parameter`	`event_time` muito antigo (>7 dias) ou inválido	Não deve acontecer com o plugin (usa `time()`)
`Access token invalid`	Token CAPI errado ou revogado	Gerar novo no Events Manager
`Pixel ID does not match`	Pixel ID errado	Conferir em Events Manager
`User data is required`	Form sem email/telefone	Garantir mapping correto no app.smart

Próximos passos

Google Analytics 4 — outro destino server-side
UTMs e atribuição — onde fbc/fbp são capturados e o timestamp real do clique é persistido
Troubleshooting — ler logs