Encaminhar conversões para a Meta CAPI através de short links Elido

A própria orientação da Meta, publicada na página de introdução à Conversions API (consultada em 2026-05-12), enquadra o pixel do browser como um complemento à CAPI, e não o contrário. Essa mudança aconteceu por volta do iOS 14.5: o App Tracking Transparency reduziu a qualidade do sinal da Meta, o ITP cortou outra fatia e as instalações de bloqueadores de anúncios continuaram a crescer. Em 2026, as equipas a correr anúncios Meta em audiências com grande presença de iOS estão regularmente a ver 30-40% dos eventos de conversão desaparecerem antes de chegarem aos relatórios.

A CAPI é o canal do lado do servidor que contorna tudo isso. O seu servidor fala diretamente com a graph API da Meta. O ITP não se aplica. Os bloqueadores de anúncios não o intersetam. A taxa de correspondência aumenta porque pode enviar email e telefone com hash ao lado do identificador de clique; como tanto os eventos do browser como do servidor partilham uma chave de deduplicação, a Meta conta a conversão uma vez mesmo quando ambos os caminhos disparam.

Este é o guia passo a passo para ligar a CAPI através dos short links do Elido. A visão geral de rastreio de conversão do lado do servidor cobre a arquitetura mais ampla (GA4, TikTok, Mixpanel, semântica de reenvio). O tutorial UTM end-to-end vale a pena ler primeiro se a sua marcação de campanhas ainda for informal.

Resumo#

• O Meta Pixel perde 30-40% dos eventos de conversão em tráfego com grande presença de iOS para o ITP e bloqueadores de anúncios; a CAPI envia esses eventos diretamente do seu servidor, recuperando a maior parte da diferença.
• A chave de deduplicação - event_id - deve ser idêntica entre o pixel do lado do browser e o evento CAPI. Falhar nisto causa dupla contagem, o que quebra a alocação do orçamento de otimização da Meta.
• Uma maior densidade de match keys (email com hash, telefone, fbc click ID, cookie fbp) melhora diretamente a taxa de correspondência de atribuição; o Elido captura o fbclid no momento do clique e associa-o a cada conversão posterior.
• A validação demora cerca de 10 minutos: o Events Manager da Meta tem um painel Test Events que mostra os eventos CAPI a chegar em 30 segundos, muito antes de o dashboard de taxa de correspondência de 24 horas se preencher.

O que precisa antes de começar#

Três coisas, todas do Meta Business Manager.

Pixel ID. Cada conta de anúncios Meta tem pelo menos um pixel. Encontre-o no Events Manager em Data Sources. A string numérica - algo como 1234567890 - é o que vai colar nas definições de integração do Elido.

Token de acesso de System User. Esta é a credencial que autoriza o Elido a escrever eventos no seu pixel. Navegue para Business Settings, depois Users, depois System Users. Crie um system user com acesso Standard, atribua-o ao pixel (permissões Manage) e gere um token com os âmbitos ads_management e business_management. O token é de longa duração; rode-o quando rodar outras credenciais de serviço, não por agendamento. Armazene-o como um segredo de workspace - não no código fonte, não numa folha de cálculo.

Padrão de URL de fonte de evento. Cada evento CAPI carrega um event_source_url que diz à Meta em que página ocorreu a conversão. Para eventos de compra, este é tipicamente o URL de confirmação do checkout. Para eventos de lead, é a página de submissão do formulário. Não os codifica diretamente; vêm do webhook do seu pedido ou do contexto do pedido do seu backend no momento da conversão.

As match keys: porque a densidade importa#

A Meta deduplica e faz corresponder eventos do servidor a sessões do browser usando um conjunto de parâmetros de informação do cliente. Quanto mais enviar, maior a taxa de correspondência. Uma taxa de correspondência mais alta significa mais conversões atribuídas às suas campanhas, o que significa que o algoritmo de otimização tem melhor sinal, o que significa melhor ROAS. A relação é direta.

As quatro chaves que mais importam:

em (email com hash SHA-256). O sinal de maior valor único. Se tem o email do cliente no momento da conversão (quase sempre tem em e-commerce), envie-o. A referência de parâmetros de informação do cliente da Meta (consultada em 2026-05-12) especifica as regras de normalização: minúsculas, sem espaços no início/fim, sem modificações ao domínio. Faça hash da string normalizada. Enviar [email protected] diretamente com hash produz o valor errado; [email protected] é o que deve ser hasheado.

ph (telefone com hash SHA-256). Mesma disciplina de normalização. Formato E.164: código de país, sem espaços, sem hífenes, sem parênteses. +4915123456789 faz hash para algo que a Meta consegue corresponder; 015123456789 não.

fbc (Facebook click ID). Quando um utilizador clica num anúncio Meta, o URL de destino recebe um parâmetro de consulta fbclid. A sua landing page ou o handler de redirecionamento do Elido lê-o e armazena-o. O campo fbc é construído a partir disto: fb.{version}.{creationTime}.{fbclid}, onde a versão é 1 e o tempo de criação é o timestamp Unix em milissegundos. O Elido captura o fbclid do URL de redirecionamento no momento do clique e armazena-o contra o registo do clique. Quando faz POST de uma conversão com um click_id, o valor fbc já está anexado e é encaminhado automaticamente.

fbp (cookie de pixel de browser do Facebook). Este é o cookie _fbp que o JS do Meta Pixel define no seu domínio. É um cookie first-party da perspetiva do seu domínio. O seu servidor lê-o a partir dos cabeçalhos do pedido no momento do checkout e inclui-o no payload de conversão. Sem ele, a taxa de correspondência da Meta para o caminho de fallback do lado do browser degrada-se.

A ordem de prioridade prática: em primeiro (quase sempre disponível), fbc segundo (o Elido fornece-o para conversões originadas em cliques), fbp terceiro (lido a partir do cookie na página de confirmação), ph por último (muitas vezes não capturado). Um payload com em + fbc vai corresponder significativamente melhor do que um sem nada.

Ligar no Elido#

A integração está em Workspace Settings, em /integrations, depois Meta CAPI.

Cole o seu Pixel ID e o token de acesso do System User. O Elido valida o token contra a graph API da Meta imediatamente - um 400 aqui significa que o token está malformado ou carece dos âmbitos necessários; verifique as permissões do system user antes de prosseguir. Uma vez validado, a integração está ativa para o workspace. Todos os links rastreados no workspace participam; não há interruptor por link.

Quando um link rastreado é clicado, o handler edge do Elido lê o fbclid da query string (se presente) e escreve-o no registo do clique. Isto acontece na camada de redirecionamento, antes de o utilizador chegar ao seu site, pelo que a captura é fiável independentemente de o JavaScript do site de destino correr.

Quando um evento de conversão dispara, faça POST para /v1/conversions:

curl -X POST \
  https://api.elido.app/v1/conversions \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -d '{
    "click_id":   "clk_01HYZ7T8WV6KQX3M",
    "event_name": "Purchase",
    "event_id":   "ord_98231",
    "value":      89.50,
    "currency":   "EUR",
    "user": {
      "email":  "[email protected]",
      "phone":  "+4915123456789"
    }
  }'

Na receção, o Elido procura o registo do clique, lê o fbclid armazenado para construir o fbc, normaliza e faz hash do email e phone, monta o payload CAPI completo e faz POST para https://graph.facebook.com/v21.0/{pixel_id}/events. A chamada à API devolve imediatamente um ID de conversão; o fan-out para a Meta é em segundo plano e observável via GET /v1/conversions/{id}.

O payload CAPI em bruto que o Elido constrói parece assim:

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1747047600,
      "event_id": "ord_98231",
      "action_source": "website",
      "event_source_url": "https://shop.example.com/checkout/thanks?order=98231",
      "user_data": {
        "em": ["a3b6e2f4...sha256 of [email protected]"],
        "ph": ["c7d9f1a3...sha256 of +4915123456789"],
        "fbc": "fb.1.1747040000.AbCdEfGhIj",
        "fbp": "fb.1.1747040000.987654321",
        "client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 17_4 ...)",
        "client_ip_address": "203.0.113.42"
      },
      "custom_data": {
        "currency": "EUR",
        "value": 89.5,
        "content_ids": ["sku-spring-jeans-32-blue"],
        "content_type": "product",
        "num_items": 1
      }
    }
  ],
  "access_token": "EAAxxxxxxx"
}

Os campos event_source_url e action_source são derivados do URL de destino do registo do clique e do parâmetro source do pedido de conversão (tem como predefinição website). Se estiver a encaminhar conversões do lado da app, passe "source": "app" no body do POST.

Disciplina de deduplicação#

Leia a documentação de deduplicação de eventos da Meta (consultada em 2026-05-12) antes de tocar em tráfego de produção. A versão curta é esta: a Meta faz corresponder eventos do pixel do browser e eventos CAPI usando event_id + event_name dentro de uma janela de 48 horas. Se ambos os eventos carregam o mesmo par, o segundo é silenciosamente descartado.

O requisito operacional que se segue: o evento Purchase do pixel do lado do browser e o evento CAPI do lado do servidor devem partilhar o mesmo event_id. A escolha mais fiável é o seu ID de pedido: ambos os lados o veem, é estável, não é regenerado em reenvio.

Onde isto falha na prática: o servidor gera um UUID no momento do encaminhamento em vez de usar o ID do pedido. Ou o pixel do browser usa um esquema de ID (ord_98231) e o backend usa outro (order-98231). Ambos os eventos são ingeridos. Nenhum é deduplicado. As suas conversões relatadas duplicam. O algoritmo da Meta sobre-aloca orçamento para a campanha com base em números inflados. A revisão do orçamento três semanas depois revela "o nosso ROAS é de alguma forma 2,5× a nossa receita real" e a análise forense é desagradável.

O diagrama de sequência abaixo mostra como o event_id percorre o sistema:

A chamada do pixel do lado do browser acontece do lado do cliente quando a página de confirmação carrega. O encaminhamento CAPI do lado do servidor acontece quando o webhook do seu pedido dispara. Ambos devem emitir event_id: ord_98231 (ou qualquer que seja o seu identificador de pedido). A diferença de tempo entre os dois é irrelevante desde que ambos cheguem dentro de 48 horas.

Se não está a correr um pixel do lado do browser (removido por razões de consentimento RGPD, ou porque a sua audiência é totalmente dominada por utilizadores de bloqueadores de anúncios), a deduplicação não é relevante. Envie apenas CAPI. Mas a maioria das equipas corre ambos; o pixel do browser fornece sinal de fallback para utilizadores onde os eventos CAPI não conseguem carregar match keys (sem email capturado, sem fbclid).

Validação#

O ciclo de validação é curto e deve acontecer antes de qualquer tráfego de produção fluir.

Passo um: definir um código de evento de teste. Nas definições de integração Meta CAPI do Elido, há um campo de código de evento de teste. Obtenha um código do Meta Events Manager em Test Events. Cole-o. Enquanto este código estiver definido, cada evento CAPI que o Elido envia é encaminhado para o painel de teste - nunca entra nos relatórios de produção.

Passo dois: disparar uma conversão de teste. Clique num dos seus links rastreados a partir de um browser (isto captura o fbclid se o URL do link veio de um anúncio Meta, ou de um link com fbclid manualmente anexado para teste). Faça POST de uma conversão contra esse click_id com um ID de pedido, valor e endereço de email realistas.

Passo três: verificar Test Events. No Meta Events Manager, o evento de teste deve aparecer em 30 segundos. Verifique que o event_name corresponde ao que o seu pixel do browser está a enviar. Verifique que o event_id é o ID do pedido, não um UUID. Verifique que em, fbc ou fbp aparecem na secção user_data - pelo menos uma match key deve estar presente.

Passo quatro: remover o código de evento de teste. Uma vez validado, limpe o campo do código de evento de teste e guarde. Os eventos de produção começam a fluir. O dashboard de taxa de correspondência no Events Manager demora 24 horas a preencher-se com dados significativos.

O que procurar às 24 horas: uma taxa de correspondência acima de 60% é aceitável; acima de 75% é boa; acima de 85% significa que a densidade das suas match keys é elevada e a atribuição será fiável. Se estiver abaixo de 60%, a causa mais provável é a falta de fbc (o fbclid não estava no URL de destino) ou um erro de normalização de hashing.

Modos de falha comuns#

event_source_url em falta. Os eventos CAPI sem este campo são aceites mas penalizados na lógica de correspondência da Meta. O campo deve ser o URL da página onde ocorreu a conversão - o seu URL de confirmação de checkout, a sua página de destino do formulário de lead, o equivalente da sua app. O Elido deriva-o do URL de destino do registo do clique quando não é substituído; passe-o explicitamente no POST de conversão se o seu URL de confirmação diferir do destino de redirecionamento.

Chave com hash não normalizada em minúsculas. [email protected] e [email protected] produzem valores SHA-256 diferentes. Os servidores da Meta fazem hash da forma canónica armazenada no seu gráfico de utilizadores. Se o seu hash não corresponder, o evento chega como não correspondido. O requisito de normalização aplica-se também aos números de telefone: elimine variações de formatação do código de país, force E.164. Encaminhar através do endpoint /v1/conversions do Elido significa que a normalização é tratada em seu nome; passa o email e telefone em bruto, o Elido faz hash conforme a especificação.

Desfasamento de action_source. As conversões originadas na web usam "action_source": "website". As conversões de apps móveis usam "app". Se estiver a encaminhar uma compra que aconteceu na sua app iOS mas enviar action_source: "website", o modelo de atribuição da Meta pode degradar o sinal. Passe "source": "app" no POST de conversão do Elido para eventos do lado da app.

fbc ausente porque fbclid não estava no URL. Isto acontece quando o URL de destino do anúncio não inclui fbclid - seja porque a campanha não tem "Auto-advanced matching" ativado, ou porque o URL foi construído manualmente sem ele, ou porque o utilizador chegou através de um caminho de retargeting que não carregava o parâmetro. Quando fbc está ausente, a conversão ainda é encaminhada, mas a taxa de correspondência cai para apenas email/telefone. Verifique as definições da campanha no Meta Ads Manager; fbclid deve aparecer nos URLs de destino para campanhas de tráfego padrão.

Esquemas duplos de event_id. O pixel do browser e o evento CAPI usam formatos diferentes para o mesmo ID de pedido. Isto acontece quase sempre quando equipas diferentes gerem a configuração do tag manager no frontend e a integração do webhook de pedidos no backend. Acordem num formato canónico antes do lançamento. O ID do pedido como string (ord_98231) funciona. Numérico-apenas também funciona. O pixel a emitir "ord_98231" e o servidor a emitir "98231" são tratados como eventos diferentes: nenhum é deduplicado.

Um resultado real#

Uma marca de e-commerce europeia a correr anúncios Meta para a Alemanha e Áustria reportou uma taxa de correspondência de 38% com rastreio apenas de pixel. O Safari no iOS representava cerca de 45% do tráfego do site; as taxas de opt-out do ATT no grupo demográfico dos 25-44 anos rondavam os 72%.

Após ligar a CAPI através do Elido com em + fbc como as match keys primárias, a taxa de correspondência subiu para 76% na primeira semana. O fbc estava agora presente em cada conversão originada de um clique de anúncio Meta (o Elido captura o fbclid na camada de redirecionamento, não ao nível do browser), e o encaminhamento de email com hash forneceu um segundo caminho de correspondência para conversões onde o cookie _fbp tinha expirado.

O CPA caiu 18% nas quatro semanas seguintes. O ROAS reportado passou de 2,1 para 2,6. A redução de 18% no CPA reflete uma melhor atribuição, não melhor desempenho da campanha: as campanhas sempre tiveram um desempenho de ROAS de 2,6; o pixel sozinho estava a sub-reportar.

Onde isto se situa no pipeline de atribuição#

A CAPI é um canal num setup mais amplo de encaminhamento do lado do servidor. A visão geral de rastreio de conversão do lado do servidor cobre o GA4 Measurement Protocol e a TikTok Events API com a mesma profundidade que esta publicação aplica à Meta. Atribuição sem cookies explicada vale a pena ler se quiser perceber o porquê subjacente - ITP, proteção de rastreio de links e as mudanças de modelo de atribuição que se seguiram.

Para a superfície do produto: funcionalidades de rastreio de conversão documenta a API completa, incluindo eventos de reembolso, modos de atribuição multi-toque e a semântica de reenvio/backoff. Soluções para marketers mostra como as peças se encaixam num fluxo de trabalho de campanha.

A configuração descrita acima é alcançável numa manhã. O principal investimento é tempo na validação - 30 minutos no Meta Test Events antes de mudar o tráfego de produção. Esses 30 minutos valem a pena; a alternativa é descobrir uma configuração incorreta três dias depois, quando o algoritmo já atuou com base nos números errados.

Fontes

• Meta Conversions API: Getting Started. developers.facebook.com/docs/marketing-api/conversions-api/get-started/ (consultado em 2026-05-12)
• Meta Conversions API: Deduplicate Pixel and Server Events. developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events/ (consultado em 2026-05-12)
• Meta Conversions API: Customer Information Parameters. developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters/ (consultado em 2026-05-12)