CAPI na Black Friday: checklist antes de escalar

Pontos-chave

Evento aceito, evento correspondido, venda atribuída e venda confirmada são quatro coisas diferentes; verifique cada uma em separado.
Só venda confirmada vira Purchase; mudança de etapa, link enviado ou "vou pagar" não são compra.
O event_id precisa ser o mesmo em todo reenvio do mesmo pedido e diferente para cada pedido novo; é assim que a Meta deduplica.
Valor e moeda viajam juntos e moedas diferentes nunca se somam no relatório.
Concilie diariamente: eventos enviados, aceitos, rejeitados e duplicados contra os pedidos do CRM, antes de aumentar a verba.

O que a API de Conversões faz em uma campanha de WhatsApp na Black Friday?

A API de Conversões (CAPI) envia eventos do servidor para a Meta, como Purchase, com deduplicação por event_id quando o mesmo evento também chega pelo pixel, segundo a documentação da Meta. Em vendas pelo WhatsApp não há pixel na conversa: a venda só existe para a Meta se o CRM enviar o evento.

Isso importa porque a campanha com objetivo de mensagens otimiza para conversa iniciada. Sem o Purchase de volta, a Meta nunca sabe quais conversas viraram venda, e o gestor decide verba pelo CPL. Com o Purchase, a Meta recebe um sinal de venda e mostra, dentro da janela de atribuição, vendas por campanha. O artigo antigo sobre API de Conversões para vendas no WhatsApp explica a base; aqui o foco é não escalar com um envio quebrado.

Quatro estados que não podem ser confundidos:

Estado	O que significa	Quem confirma	O que NÃO prova
Evento aceito	A Meta recebeu um payload válido	Gerenciador de eventos	Que a venda existiu
Evento correspondido	A Meta ligou o evento a um usuário	Gerenciador de eventos	Que o anúncio causou a venda
Venda atribuída	A Meta creditou a venda a um anúncio dentro da janela	Relatório da Meta	Que o valor está certo
Venda confirmada	Pagamento aprovado e registrado no CRM com valor e moeda	CRM / financeiro	Que a Meta recebeu o evento

Qual é o checklist de CAPI antes de escalar?

O checklist tem dez itens, e qualquer "não" segura a expansão de verba. Teste antes do evento com o mecanismo de teste da Meta, sem simular compras reais em produção.

Origem do evento definida: qual conjunto de dados recebe o evento e qual sistema envia. Duas ferramentas enviando: uma precisa parar.
Gatilho correto: Purchase sai só quando a venda é confirmada no CRM. Mudança de etapa no funil, envio de link de pagamento e "fechou no áudio" não disparam Purchase.
Valor e moeda: value numérico e currency em ISO (BRL). Sem moeda o valor é inútil; com moeda errada o ROAS vira ficção.
event_id estável: gerado a partir do identificador do pedido, igual em todo reenvio do mesmo pedido, diferente para pedido novo.
event_time do pagamento: hora da confirmação, não do envio em lote. Lote atrasado empurra a venda para fora da janela de atribuição.
Dados de correspondência: os campos de identificação que o canal fornece seguem o formato que a documentação da Meta exige; sem eles o evento chega e não liga a ninguém.
Deduplicação testada: envie o mesmo pedido duas vezes no ambiente de teste e confira que a Meta conta um.
Reenvio controlado: falha de rede gera nova tentativa com o mesmo event_id, com limite de tentativas e log.
Dono das rejeições: uma pessoa olha eventos rejeitados todo dia e sabe parar o envio se o payload estiver errado.
Conciliação: eventos aceitos por dia batem com pedidos confirmados no CRM por dia; diferença acima do tolerado (hipotético: 5%) bloqueia escala.

Regra de decisão: se os itens 2, 3, 4 ou 10 falharem, não escale. Os demais podem ser corrigidos com a verba de validação no ar.

Como funciona a deduplicação por event_id na prática?

A Meta recebe eventos com o mesmo event_name e o mesmo event_id dentro de um intervalo e conta apenas um. Isso protege contra reenvio após falha e contra o mesmo evento chegando por dois caminhos. Exemplo hipotético:

Pedido 7781 confirmado às 14h02, R$ 240,00 BRL. O CRM gera event_id "purchase-7781" e envia Purchase.
A rede falha e o CRM não recebe confirmação. Às 14h04, reenvia o mesmo payload com event_id "purchase-7781". A Meta conta um Purchase.
Pedido 7782 confirmado às 14h10, R$ 240,00 BRL, mesmo cliente comprando um segundo item. event_id "purchase-7782". A Meta conta o segundo Purchase.
Erro que destrói o relatório: o CRM gera o event_id a partir do telefone do cliente. Os pedidos 7781 e 7782 recebem o mesmo event_id, a Meta deduplica e o relatório mostra R$ 240 em vez de R$ 480.
Erro oposto: o CRM gera event_id com timestamp. O reenvio das 14h04 recebe id novo e a Meta conta dois Purchase de R$ 240 para um pedido: ROAS inflado.

Conciliação do dia: CRM com 2 pedidos (R$ 480); Meta com 2 eventos aceitos (R$ 480). Três eventos indicam id instável; um evento indica colisão de id. Um CRM com atribuição que envia Purchase com controle de duplicidade, como o RASTRO, cuida dessa parte; o gestor ainda confere a conciliação.

Que erros de CAPI mais aparecem na Black Friday?

Os erros mais frequentes são de gatilho, de identidade e de tempo:

Transformar etapa de funil em Purchase. O lead em "negociando" não comprou. Purchase ali ensina a Meta a buscar quem negocia, não quem paga, e infla o ROAS.
Copiar o payload de um e-commerce. Um site com pixel tem campos que a conversa não tem; o evento chega com dados vazios e a correspondência cai. Monte o payload a partir do que o canal fornece e declare o que não está disponível.
Enviar em lote de madrugada. O event_time em lote joga a venda para outro dia e, perto do fim da janela de atribuição, para fora dela. O relatório da Meta e o do CRM param de bater.
Somar moedas. Cliente que vende para o Brasil em BRL e para fora em USD precisa de dois relatórios de ROAS. Um Purchase em USD somado a outro em BRL gera um número sem significado.
Esquecer cancelamentos. O art. 49 do CDC dá 7 dias de arrependimento em compras fora do estabelecimento, incluindo WhatsApp. Venda cancelada é marcada no CRM e descontada do relatório; o Purchase já enviado fica como limitação declarada.

A fonte da verdade é o CRM com valor e moeda, não o gerenciador de eventos. Se o que você manda está errado, a otimização aprende errado no leilão mais disputado do ano; em novembro, compare o custo com o novembro anterior da própria conta.

O que medir diariamente na Black Week para manter a CAPI confiável?

Meça eventos enviados, aceitos, rejeitados, duplicados e conciliados, e cruze com a cobertura de atribuição do CRM. Fórmulas e faixas:

Taxa de aceitação = eventos aceitos ÷ eventos enviados. Bom: perto de 100%. Ruim: abaixo de 95% (hipotético); investigue o payload no mesmo dia.
Taxa de duplicados = eventos deduplicados ÷ eventos enviados. Bom: igual à taxa de reenvios por falha. Ruim: muito acima (id instável) ou zero com reenvios (id colidindo).
Conciliação = eventos aceitos ÷ pedidos confirmados no CRM. Bom: entre 0,95 e 1,05 (hipotético). Ruim: fora disso por dois dias.
Cobertura de atribuição = vendas com origem ÷ vendas totais no CRM. O Purchase sai para toda venda confirmada, com ou sem origem; a cobertura diz quanto a Meta conseguirá atribuir. Abaixo de 70% (hipotético), o relatório da Meta por campanha fica parcial e a escala por anúncio perde base.
Diferença de valor = receita dos eventos aceitos − receita confirmada no CRM, por moeda. Bom: zero. Ruim: qualquer diferença recorrente.

Compare por cohort (vendas dos leads que entraram no dia), não por caixa; a janela de atribuição segue o clique, não o pagamento. O rastreamento que alimenta essas vendas está em rastreamento do anúncio ao WhatsApp, e a decisão de verba a partir delas em orçamento de Meta Ads na Black Friday.

Como apresentar os números da CAPI ao cliente sem prometer o que não existe?

Apresente os quatro estados em separado, com a cobertura ao lado, e deixe escrito o que o canal não fornece. O ROAS da Meta e o do CRM são leituras diferentes, não erro de alguém. Estrutura sugerida:

Vendas confirmadas no CRM, por moeda, com total e sem atribuição em linha própria.
Eventos Purchase enviados, aceitos e deduplicados no período.
Vendas atribuídas pela Meta dentro da janela, por campanha.
Diferença entre 1 e 3 explicada por janela, cobertura e correspondência.
Limitações declaradas: cancelamentos após o envio e caminhos de entrada sem origem.

O número que não pode ser explicado linha a linha não deve estar no relatório. O formato completo está em relatório que ajuda o cliente a decidir.

Plano de ação: o que fazer nesta semana

Use este cronograma para validar a CAPI antes de escalar.

Quando	Ação	Responsável	Pronto quando
Hoje	Confirmar qual sistema envia Purchase e para qual conjunto de dados	Gestor de tráfego	Uma única ferramenta enviando
Até sexta	Disparar Purchase só com venda confirmada, com value, currency e event_id do número do pedido	Quem cuida do CRM	Payload de teste com valor, moeda ISO e event_id do pedido
D-14	Enviar o mesmo pedido duas vezes e um segundo pedido do mesmo cliente no ambiente de teste	Quem cuida do CRM	Deduplicação conta 1 evento para 2 envios do mesmo pedido e 2 eventos para 2 pedidos
D-7	Nomear quem olha os eventos rejeitados todo dia e pode parar o envio	Gestor de tráfego e cliente	Nome do responsável escrito no briefing
D-7 a D-1	Conciliar eventos aceitos com pedidos confirmados no CRM, por dia	Gestor de tráfego	Conciliação entre 0,95 e 1,05 (hipotético) antes de escalar
Dia do evento	Conferir taxa de aceitação e diferença de valor por moeda	Gestor de tráfego	Aceitação perto de 100% e diferença de valor zero
D+7	Marcar no CRM as vendas canceladas no prazo de arrependimento	Atendimento	Cancelamentos descontados do relatório

Perguntas frequentes

Fontes

Evento aceito pela Meta garante que a venda foi atribuída ao anúncio?

Não. Aceitação significa que o payload era válido. Atribuição exige que a Meta encontre o usuário (correspondência) e que a venda caia na janela de atribuição do clique. Venda confirmada é outra coisa ainda: só o CRM e o financeiro confirmam. Verifique os quatro estados em separado.

Devo enviar Purchase quando o lead diz que vai pagar?

Não. Purchase só para pagamento confirmado, com valor e moeda. Enviar antes ensina a Meta a buscar quem promete, não quem paga, e infla o ROAS. Se quiser um sinal intermediário, use um evento próprio para lead qualificado, separado de Purchase.

O que acontece se eu reenviar o mesmo pedido duas vezes?

Se o event_id for o mesmo, a Meta deduplica e conta um Purchase. Se o event_id mudar a cada envio (por exemplo, com timestamp), a Meta conta dois e o ROAS fica inflado. Teste o reenvio no ambiente de teste antes da Black Friday e confira a contagem.

Como testar a CAPI sem gerar compras falsas?

Use o mecanismo de eventos de teste do gerenciador de eventos da Meta, com um pedido marcado como teste no CRM. Confira valor, moeda, event_id, event_time e a deduplicação. Depois marque ou exclua o pedido de teste para ele não entrar no relatório.