Preciso do pixel da Meta e da Conversions API em simultâneo?

A Meta recomenda usar ambos. O pixel acrescenta dados do navegador, como o cookie fbp, e a Conversions API entrega os eventos que o navegador perde. Dê às duas cópias o mesmo nome e o mesmo ID de evento para que a Meta conte cada evento uma só vez.

Quanto tempo espera a Meta para eliminar os duplicados entre um evento do navegador e um evento do servidor?

A Meta elimina os duplicados entre um evento do navegador e um evento do servidor com o mesmo nome e o mesmo ID de evento quando chegam com menos de 48 horas de diferença. Uma cópia que chegue mais tarde é contada de novo.

A Conversions API exige que os dados do cliente tenham hash?

Sim, no caso dos dados de contacto. Os campos de email, telefone, nome e morada têm de ser normalizados e passar por hash SHA-256. O endereço IP, o user agent, o fbp e o fbc são enviados sem hash.

Que campos são obrigatórios num evento de website?

Todos os eventos precisam de event_name, event_time, action_source e de pelo menos um parâmetro de dados do cliente. Nos eventos de website, a Meta exige também event_source_url e client_user_agent.

Posso enviar encomendas antigas pela Conversions API?

Só as recentes. O event_time pode ter no máximo 7 dias no passado, e se um evento de um pedido for mais antigo, a Meta rejeita o pedido inteiro.

Meta Conversions API (CAPI): um guia prático

Pontos-chave

A Conversions API da Meta envia eventos como o Purchase a partir do seu servidor, por isso chegam à Meta mesmo quando o pixel do navegador está bloqueado.
Use-a a par do pixel e dê às duas cópias o mesmo nome de evento e o mesmo event_id; a Meta conta então o evento uma só vez se ambas chegarem no prazo de 48 horas.
Os eventos de website precisam de action_source, de event_source_url e do user agent do comprador; o email e o telefone com hash, o endereço IP, o fbp e o fbc determinam o quão bem a Meta os consegue associar.
Teste com o separador Test events no Events Manager e depois remova o código de teste, porque os eventos de teste não são descartados.
A maioria dos problemas vem de IDs de evento que não coincidem, do endereço IP do próprio servidor, de um fbclid perdido ou de dados de contacto que receberam hash sem serem normalizados.

A Conversions API (CAPI) da Meta permite que o seu servidor envie eventos como o Purchase diretamente para a Meta. O pixel da Meta envia os mesmos eventos a partir do navegador do comprador. A CAPI envia-os a partir do seu servidor, por isso continuam a chegar quando um bloqueador de anúncios trava o pixel, um cookie desaparece ou a página de agradecimento nunca carrega.

Este guia explica o que contém um evento da Conversions API, como a usar a par do pixel com um só event_id, que parâmetros a Meta exige e recomenda, como testar com o Test events e os erros que surgem com mais frequência.

O que é a Conversions API da Meta?

A Conversions API faz parte da Graph API da Meta. O seu servidor envia um pedido HTTPS POST para graph.facebook.com/VERSION/PIXEL_ID/events com um token de acesso e uma lista data com até 1,000 eventos. Cada evento descreve uma ação, como uma compra, em três partes: o que aconteceu, quem a fez e os detalhes.

Campo	O que contém
`event_name`	A ação, por exemplo `Purchase`, `AddToCart` ou `InitiateCheckout`
`event_time`	Quando aconteceu, como timestamp Unix em segundos
`event_id`	Um ID único deste evento, usado para eliminar os duplicados em relação ao pixel
`action_source`	Onde aconteceu: `website` para compras na loja
`event_source_url`	O URL da página onde o evento aconteceu
`user_data`	Dados do cliente para correspondência: email e telefone com hash, endereço IP, user agent, fbp e fbc
`custom_data`	Detalhes como `value`, `currency` e `content_ids`

Todos os eventos da Conversions API têm a mesma forma: a ação, os dados do cliente e os detalhes.

Um evento Purchase reduzido tem este aspeto:

Conversions API: um evento Purchase (reduzido)

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1792929600,
    "event_id": "order-1042",
    "action_source": "website",
    "event_source_url": "https://yourstore.com/checkouts/thank-you",
    "user_data": {
      "em": ["<SHA-256 of the normalized email>"],
      "ph": ["<SHA-256 of the normalized phone>"],
      "client_ip_address": "203.0.113.24",
      "client_user_agent": "Mozilla/5.0 (iPhone; ...)",
      "fbp": "fb.1.1792928400000.1234567890",
      "fbc": "fb.1.1792928400000.AbCdEf123"
    },
    "custom_data": { "value": 74.00, "currency": "USD" }
  }]
}

Os campos de contacto, como o email e o telefone, são normalizados e recebem hash SHA-256 antes de saírem do seu servidor. O endereço IP, o user agent, o fbp e o fbc são enviados tal como estão.

Porquê usar a Conversions API a par do pixel?

A Meta recomenda usar a Conversions API a par do pixel e enviar os mesmos eventos pelos dois. Cada lado vê algo que o outro não vê, e em conjunto dão à Meta dados mais completos.

Pixel da Meta (navegador)

Define o cookie _fbp e guarda o fbclid de um clique num anúncio no cookie _fbc
Vê a página e o navegador enquanto a visita decorre
Perde-se quando o navegador o bloqueia ou a página não carrega

Conversions API (servidor)

Envia a encomenda paga a partir dos dados da sua loja
Pode acrescentar email, telefone e morada com hash a partir da encomenda
Não depende do navegador, por isso os bloqueadores de anúncios não o travam

O pixel traz os identificadores do navegador e o servidor traz a encomenda. Cada um sozinho deixa escapar parte do quadro.

O custo de usar os dois é que a Meta passa a receber duas cópias de cada evento. A secção seguinte mostra como a Meta fica só com uma.

Como funciona a eliminação de duplicados com um só event_id?

A Meta trata um evento do navegador e um evento do servidor como o mesmo evento quando duas coisas coincidem: o nome do evento e o ID do evento. No pixel, o ID vai na opção eventID. Na Conversions API, o mesmo valor vai em event_id.

Pixel da Meta: o mesmo Purchase com eventID

fbq('track', 'Purchase', { value: 74.00, currency: 'USD' }, { eventID: 'order-1042' });

O comprador pagaEncomenda 1042, $74.00

O pixel envia o PurchaseeventID order-1042, a partir do navegador

O servidor envia o Purchaseevent_id order-1042, a partir da encomenda

A Meta conta umMesmo nome e ID em 48 horas

As duas cópias trazem o mesmo nome de evento e o mesmo ID, por isso a Meta fica com uma compra em vez de duas.

A Meta só elimina os duplicados de um par coincidente quando as duas cópias chegam com menos de 48 horas de diferença. Algumas regras fazem isto funcionar na prática:

Crie o ID uma só vez. Construa-o a partir de algo que os dois lados conhecem, como o número da encomenda, e passe-o ao navegador e ao servidor. Dois sistemas que criem cada um o seu próprio ID não vão coincidir.
Use um só formato. order-1042 e 1042 são IDs diferentes.
Use exatamente o mesmo nome de evento. Purchase e purchase são eventos diferentes.
Envie o evento do servidor sem demora. Um evento do servidor que chega mais de 48 horas depois do evento do navegador é contado uma segunda vez.

A Meta descreve também um segundo método que associa os eventos pelo fbp ou pelo external_id. A Meta indica que, em regra, só funciona quando o evento do navegador chega antes do evento do servidor, por isso um event_id partilhado é a escolha mais fiável. Se a Meta continuar a reportar mais compras do que a sua loja teve, o nosso guia sobre eventos de compra duplicados lista as causas habituais.

Que parâmetros são obrigatórios e quais são recomendados?

Os campos obrigatórios tornam um evento válido. Os campos recomendados determinam quantos dos seus eventos a Meta consegue associar a uma pessoa, e só os eventos associados podem ser usados para atribuição e para a entrega dos anúncios.

Parâmetro	Eventos de website	O que enviar
`event_name`	Obrigatório	Um evento padrão como Purchase, ou um nome de evento personalizado
`event_time`	Obrigatório	Hora Unix em segundos, no máximo 7 dias no passado
`action_source`	Obrigatório	`website` para eventos na sua loja
`event_source_url`	Obrigatório	O URL da página onde o evento aconteceu
`client_user_agent`	Obrigatório	A cadeia do navegador do comprador, não a do seu servidor
`user_data`	Obrigatório	Pelo menos um parâmetro de dados do cliente
`event_id`	Recomendado	O mesmo ID que o pixel usa, para a eliminação de duplicados
`em`, `ph`	Recomendado	Email e telefone, normalizados e com hash SHA-256
`client_ip_address`	Recomendado	O endereço IP do comprador, sem hash
`fbp`, `fbc`	Recomendado	Os cookies de ID do navegador e de ID de clique, sem hash
`external_id`	Recomendado	O seu próprio ID de cliente, igual nos eventos do navegador e do servidor
`value`, `currency`	Enviar com o Purchase	O valor da encomenda e um código de moeda de três letras

A Meta indica action_source, event_source_url e client_user_agent como obrigatórios para os eventos de website enviados através da Conversions API.

Três detalhes causam a maioria dos problemas:

Normalize antes de aplicar o hash. A Meta espera o email sem espaços nas pontas e em minúsculas, e os números de telefone em dígitos com o indicativo do país. Anna@Example.com e anna@example.com dão hashes diferentes, e só o segundo pode corresponder.
Não aplique hash aos identificadores do navegador. O fbp, o fbc, o endereço IP e o user agent entram como valores simples.
Mantenha o ID de clique exatamente como está. O valor do fbc é fb.1., a hora de criação em milissegundos, um ponto e o fbclid do URL da página de entrada. O fbclid distingue maiúsculas de minúsculas. Guarde-o quando o visitante chega, porque já não está no URL no checkout.

A qualidade desta correspondência é o que a pontuação Event Match Quality da Meta mede. O nosso guia sobre a Event Match Quality explica cada parâmetro, as regras de hash e a pontuação a atingir.

Como se testam eventos com o Test events?

O Events Manager tem um separador Test events que mostra os eventos à medida que chegam. Use-o antes de confiar numa configuração nova.

Abra o Test events
No Events Manager, selecione o seu dataset (pixel) e abra o separador Test events. Copie o código de teste que aparece.
Adicione o código aos seus eventos do servidor
Envie-o como test_event_code no pedido. Na ROASaurus, cole-o no campo Test event code do pixel da Meta.
Faça uma encomenda de teste
Visite a loja, adicione um produto e pague, para que tanto o pixel como o servidor enviem um Purchase.
Compare as duas cópias
As duas cópias devem mostrar o mesmo nome de evento, ID de evento, valor e moeda.
Verifique os dados do cliente
O evento do servidor deve trazer email e telefone com hash, o endereço IP, o user agent e o fbp, e também o fbc se a visita começou com um clique num anúncio.
Remova o código de teste
A Meta indica que o campo serve apenas para testes, por isso remova-o antes de passar a confiar nos eventos.

Purchase browser order-1042 74.00 USDDo pixel

Purchase server order-1042 74.00 USDDa Conversions API

event_name + event_id matchContado como uma só compra

em ph fbp fbc client_ip_address client_user_agentDados do cliente no evento do servidor

O que mostra uma boa encomenda de teste (valores de exemplo): duas cópias, um só ID e dados do cliente completos.

Erros comuns da Conversions API e como os corrigir

O que vê	Causa provável	Solução
O pedido inteiro falha e nenhum evento é processado	Um evento do lote tem um event_time com mais de 7 dias	Envie os eventos quando acontecem. Corrija ou descarte os eventos antigos antes de tentar de novo.
A Meta reporta mais compras do que a sua loja teve	IDs de evento diferentes, um evento do pixel sem eventID ou uma segunda app que envia o mesmo pixel	Use um só ID para as duas cópias e um só emissor do servidor por pixel.
Qualidade de correspondência baixa nos eventos do servidor	O seu servidor envia o seu próprio endereço IP e user agent	Passe o endereço IP e o user agent registados a partir do navegador ou da encomenda do comprador.
Poucos eventos com fbc	O fbclid não foi guardado na página de entrada, ou foi alterado	Guarde o fbclid exatamente como chega e crie o fbc a partir dele.
O email e o telefone não correspondem	Valores com hash sem normalização, ou enviados sem hash	Retire os espaços das pontas e ponha o email em minúsculas, mantenha os dígitos e o indicativo do país do telefone e aplique depois o hash SHA-256.
Os pedidos falham com um erro de token expirado	O token de acesso veio de um início de sessão no Facebook, e os tokens de início de sessão expiram	Volte a ligar, ou use um token de System User do Business Manager, que pode criar sem data de expiração.

A maioria dos problemas da Conversions API aparece como pedidos rejeitados, contagens em duplicado ou qualidade de correspondência baixa.

Depois de alguns dias de tráfego real, abra o separador Diagnostics no Events Manager. A Meta lista aí os problemas com recomendações sobre como os corrigir. Depois compare a contagem diária de Purchase no Events Manager com as encomendas pagas na sua loja nos mesmos dias. Se a Meta estiver claramente mais alta, a nossa página de ajuda sobre como evitar a contagem em duplicado lista as definições a verificar.

Como configurar a Conversions API com a ROASaurus

A ROASaurus envia eventos da Conversions API a partir dos dados de encomenda da sua loja, por isso não tem de construir o lado do servidor por si. Em Tracking & platforms, clique em Connect with Facebook e escolha a sua conta de anúncios e o seu pixel, ou cole o ID do pixel (dataset) e um token da Conversions API. O guia de configuração da Meta explica as duas opções, e a página da integração com a Meta lista todos os campos que são enviados.

Um só ID nos dois lados. Os eventos do navegador e do servidor partilham um só ID de evento. Numa compra, é order- seguido do ID da encomenda.
Uma curta espera antes da compra. O Purchase do servidor espera um instante depois de a encomenda chegar, para que o evento de compra do navegador possa ser associado primeiro. O endereço IP, o user agent e o URL da página desse evento seguem então com o evento do servidor, juntamente com o fbp e o fbc guardados para o visitante.
Dados do cliente a partir da encomenda. O email, o telefone, o nome e a morada são normalizados e recebem hash SHA-256. O ID de cliente da loja e o ID de visitante da ROASaurus seguem com hash como external_id.
Os eventos que a Meta não consegue associar são ignorados. Um evento sem fbc, fbp, email, telefone nem endereço IP não é enviado.

O Event log mostra cada entrega do servidor com o pedido e a resposta da Meta. Se as suas margens diferirem muito entre produtos, pode também enviar um valor de lucro junto a cada compra: o nosso guia sobre otimização de valor da Meta para o lucro explica como. Para o percurso completo dos dados, do clique à encomenda, veja tracking server-side.

Fontes

Na ROASaurus

Continue a ler

Plataformas de anúncios e lojas onlineTracking de conversões em pagamento contra reembolso e checkouts externosTracking de conversões em pagamento contra reembolso: porque é que os pixels falham as encomendas COD e de checkout externo, quando enviar a compra e como tratar as encomendas recusadas.Plataformas de anúncios e lojas onlineTracking de conversões no CCV Shop: um guia de configuraçãoTracking de conversões no CCV Shop: envie as encomendas pagas para a Meta e o TikTok com um webhook assinado, associe-as aos cliques em anúncios, configure, teste e trate os pagamentos tardios.Plataformas de anúncios e lojas onlineConversões avançadas do Google Ads no ShopifyAs conversões avançadas acrescentam dados de clientes com hash às compras do Google Ads no Shopify. Veja como funcionam, em que diferem das importações offline e como configurar.