action_source: o parâmetro que a tela promete e o envio ignora
Ele diz ao Meta onde a conversão aconteceu, e influencia atribuição e otimização. Numa auditoria recente, 100% dos eventos de uma conta saíam como servidor — inclusive os que aconteceram no navegador da pessoa.
O action_source responde ao Meta uma pergunta simples: onde essa conversão aconteceu? Site, aplicativo, telefone, loja física, conversa. É um campo obrigatório na API de Conversões, e é dos poucos que mudam como o Meta trata o evento — não só se ele é aceito.
Também é um dos campos mais silenciosamente errados que existem, por um motivo que não tem nada a ver com o Meta.
O que ele muda de verdade
| Valor | Quando usar | O que muda |
|---|---|---|
| website | A pessoa estava no seu site quando aconteceu | Permite casar com o clique e usar fbc e fbp |
| app | Aconteceu dentro do aplicativo | Atribuição pelo identificador do app |
| chat | Fechou por WhatsApp, Messenger ou Instagram Direct | Conecta com campanhas de mensagem |
| phone_call | Fechou por telefone | Conversão offline, sem sinal de navegador |
| physical_store | Venda em loja | Entra na medição de tráfego de loja |
| system_generated | Gerado pelo seu sistema, sem ação direta da pessoa | Renovação de assinatura, por exemplo |
| other | Nenhum dos anteriores | O Meta aceita, mas perde contexto |
O caso mais consequente é website contra os demais. Quando o evento é declarado como de site, o Meta espera cookies de navegador e usa fbc e fbp para atribuir com precisão. Quando não é, esses campos perdem peso — e você mandou o dado à toa.
O defeito que a auditoria encontrou
Numa auditoria dos payloads realmente entregues por uma integração, o action_source vinha como servidor em 100% dos eventos. Inclusive nas visitas de página e nos cadastros — que aconteceram, por definição, no navegador da pessoa.
A causa não era descuido de quem configurou. A tela oferecia o seletor, gravava a escolha no destino, e o código que monta o envio lia o valor de outro lugar, onde ninguém escrevia. O seletor funcionava. Ele só não chegava a lugar nenhum.
É uma família inteira de defeito, e ela não aparece em teste: a interface promete um comportamento, o envio ignora, e o relatório do Meta continua verde porque o evento foi aceito.
Na mesma auditoria, o campo de recusa de uso de dados tinha o mesmo problema: oferecido na tela, zero ocorrências no código que envia. O padrão é sempre esse — a opção existe, o efeito não.
Como conferir o seu em dois minutos
Não confie na tela de configuração. Olhe o corpo que saiu. Toda ferramenta séria guarda os payloads entregues; se a sua não guarda, isso já é a resposta.
{
"event_name": "Lead",
"action_source": "website", // <- confira ESTE valor
"event_source_url": "https://...", // obrigatório quando é website
"user_data": { "em": ["..."], "fbc": "fb.1....", "fbp": "fb.1...." }
}Duas conferências rápidas resolvem quase tudo: se o valor é website, tem de existir event_source_url; e se o evento aconteceu no navegador, fbc e fbp deveriam estar presentes na maioria dos envios. Um evento declarado como de site, sem URL e sem cookie, é um evento que está mentindo sobre a própria origem.
O caso da renovação
Existe um uso do system_generated que quase ninguém aproveita: a renovação de assinatura. Ela não é uma ação da pessoa, não tem clique, não tem navegador, e mandá-la como website enfraquece a média da conta inteira.
Mandar renovação como venda nova é um erro maior ainda, mas esse merece texto próprio — ele infla o retorno da campanha com dinheiro que ela não trouxe.
No CrazyLeads, o action_source é resolvido a partir da origem real do evento, e o payload entregue fica guardado e visível na auditoria de entregas — que é onde você confere o que saiu, não o que foi configurado.