← blog/capi-trackingEN
    // blog/capi-tracking.md

    CAPI — Tracking Server-Side

    Por que a maioria das agências está perdendo 30–40% dos dados de conversão — e como corrigir isso.

    2026-05-02·6 min de leitura·tráfego pago·POSTEP Digital

    Pixel = dispara no browser (bloqueável) · CAPI = dispara no servidor (não bloqueável) · event_id = deduplica os dois

    // 01

    O problema

    A maioria das agências está otimizando campanhas com metade dos dados.

    Quando você instala só o Pixel do Meta no site, os eventos chegam pelo browser do usuário. Mas o browser tem bloqueadores de anúncio, restrições de cookie, iOS 14, Safari ITP. Dependendo do público, 30 a 40% dos eventos somem antes de chegar no Meta.

    O algoritmo de campanha aprende com o que recebe. Menos dados significa pior otimização e CPL mais alto — mesmo sem mudar copy, criativos ou orçamento.

    // 02

    O que é a Conversions API

    A Conversions API (CAPI) é uma integração server-side lançada pelo Meta em 2021. Em vez de depender do browser para enviar eventos, você envia diretamente do servidor para o Meta via chamada HTTP. Nenhum bloqueador de anúncio intercepta isso.

    // pixel vs capi
    só Pixel (browser)
    ✗bloqueado por ad blockers
    ✗iOS 14 limita tracking
    ✗Safari ITP apaga cookies
    ✗perda de 30–40% dos eventos
    ✗algoritmo com sinal fraco
    Pixel + CAPI
    ✓server-side, não bloqueável
    ✓independente do browser
    ✓event_id deduplica os dois
    ✓cobertura próxima de 100%
    ✓algoritmo com sinal completo
    // 03

    Como funciona na prática

    O ponto crítico é a deduplicação. Como o Pixel e a CAPI disparam para o mesmo evento, o Meta precisa saber que são o mesmo — senão conta duas vezes e distorce os dados. A solução é um event_id único gerado no frontend e enviado para os dois canais.

    // fluxo completo
    →usuário acessa a página
    →frontend gera event_id único
    →Pixel dispara com esse event_id (browser)
    →webhook N8N recebe o mesmo event_id
    →N8N chama a Graph API com o evento
    →Meta recebe os dois, deduplica pelo event_id

    → Se o Pixel for bloqueado, só a CAPI conta. Se os dois chegarem, o Meta usa o event_id para não duplicar.

    // a deduplicação pelo event_id
    gera
    event_id único
    no frontend, quando a página carrega
    os 2 canais levam o mesmo event_id
    Pixel
    no browser
    bloqueável
    CAPI
    no servidor
    sempre chega
    recebe os 2
    Meta
    deduplica pelo event_id — não conta duas vezes
    se o Pixel cair, a CAPI garante o evento — cobertura perto de 100%
    // 04

    O que precisa ser enviado

    A CAPI exige alguns campos obrigatórios e aceita dados opcionais que aumentam a qualidade do matching — quanto mais dados de usuário você enviar, melhor o Meta consegue atribuir o evento a uma pessoa real.

    ✓
    event_name— PageView, Lead, Purchase, ViewContent…
    ✓
    event_time— Unix timestamp do momento do evento
    ✓
    event_id— ID único para deduplicação com o Pixel
    ✓
    action_source— sempre 'website' para eventos de site
    ·
    client_user_agent— user agent do browser do usuário
    opcional
    ·
    client_ip_address— IP extraído do header x-forwarded-for
    opcional
    ·
    fbp / fbc— cookies _fbp e _fbc do Meta Pixel
    opcional

    → Os campos opcionais aumentam o Event Match Quality Score — métrica que o Meta usa para medir a qualidade do sinal recebido.

    // 05

    Nossa implementação

    No próprio site da POSTEP usamos N8N como relay entre o frontend e a Graph API. O frontend envia um POST para um webhook N8N, que monta o payload correto e chama a API do Meta server-side.

    // arquitetura
    frontend (React)
    fetch(CAPI_WEBHOOK, { event_name, event_id, fbp, fbc, ip })
    ↓ POST
    N8N webhook
    extrai IP do x-forwarded-for
    valida event_name contra lista permitida
    monta payload e chama Graph API v25
    ↓ HTTP POST
    Meta Conversions API
    events_received: 1

    Nenhuma dependência de SDK externo. O N8N já está na infra — o relay não adiciona custo, só conecta o que já existe.

    // a arquitetura do relay
    dispara
    Frontend
    fetch → webhook com event_id, fbp, fbc
    monta o payload
    N8N · relay
    extrai o IP · valida o evento · chama a Graph API
    recebe
    Meta · Conversions API
    events_received: 1
    sem SDK externo — o N8N já está na infra, o relay não adiciona custo
    // 06

    Vale implementar?

    Depende do público. Se a maioria do seu tráfego é mobile iOS ou usa bloqueadores, a diferença é imediata. Se é tráfego Android sem bloqueadores, o ganho é menor — mas o sinal ainda melhora.

    público mobile iOS

    alto — 30–40% de eventos recuperados

    usuários com ad blockers

    alto — 100% dos eventos bloqueados recuperados

    tráfego Android / desktop sem bloqueador

    médio — melhora Event Match Quality

    qualquer conta com objetivo de conversão

    alto — algoritmo recebe sinal mais completo

    // conclusão

    Se você roda campanhas de conversão no Meta e não tem CAPI configurado, está otimizando com dados incompletos. A implementação leva menos de um dia. O impacto é imediato.

    escrito por
    POSTEP Digital
    ← ver todos os posts