> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chargefy.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Conectar o pixel da Meta
> Conecte seu conjunto de dados da Meta, escolha o alcance e envie eventos do checkout pelo navegador e pelo servidor.
Conecte a Meta uma vez para enviar o funil que a Chargefy observa: abertura do
checkout, envio dos dados de pagamento, aprovação, recusa e expiração.
A configuração fica em **Integrações → Meta** no Dashboard.
## Antes de começar
Tenha em mãos:
* o **Pixel ID**, também apresentado pela Meta como ID do conjunto de dados;
* um **token de acesso da Conversions API**;
* os Payment Links que devem fazer parte do alcance, se a conexão não receber
todas as vendas.
O token é validado antes de a conexão ser salva. Depois disso, ele fica
criptografado e não é exibido novamente; o Dashboard mostra somente os quatro
últimos caracteres para conferência.
## Criar a conexão
No Dashboard, entre em **Integrações → Meta** e crie um destino.
Dê um nome interno à conexão, cole o Pixel ID e o token da Conversions API.
Defina se o destino recebe todas as vendas ou somente as sessões originadas
por Payment Links específicos.
O canal de servidor começa habilitado. O canal de navegador começa
desabilitado e pode ser ativado para formar a configuração redundante.
Informe um código de evento de teste, salve o destino e abra um checkout
criado depois dessa configuração.
## Combinar navegador e servidor
Os dois canais enviam o mesmo funil, mas cobrem situações diferentes. Mantenha
o servidor ativo e use também o navegador quando sua política de privacidade e
gestão de consentimento permitirem.
| Canal | O que cobre melhor | Limitação principal |
| ------------------------------ | ------------------------------------------------------- | ------------------------------------------------------ |
| **Navegador (Pixel)** | Interações enquanto o checkout está aberto | Pode ser bloqueado ou interrompido quando a aba fecha |
| **Servidor (Conversions API)** | Aprovações, recusas e expirações, inclusive assíncronas | Depende de uma credencial válida e da aceitação da API |
### Deduplicação
Quando os dois canais enviam o mesmo evento, eles compartilham um `event_id`
estável. A Meta usa esse identificador para tratar as duas entregas como uma
única conversão; ativar ambos não deve duplicar a venda.
### Eventos assíncronos e novas tentativas
Pix e boleto podem ser pagos depois que o comprador fecha a página. Nesses
casos, somente o servidor consegue enviar o resultado. Ele também cobre a
expiração da sessão e tenta novamente quando uma falha da API é temporária.
Se o token for revogado, expirar ou perder permissão, a conexão é marcada como
inválida e os envios param até a credencial ser substituída.
### Segurança e leitura dos resultados
A URL que o Pixel reporta à Meta é a página hospedada do checkout, endereçada
pelo id da sessão — nenhum segredo da sua conta ou da API passa por ali. Se o
navegador bloquear o Pixel, o canal de navegador não inicia, mas o servidor
continua funcionando.
No canal de servidor, “Recebido” significa que a API da Meta confirmou ao
menos um evento. No navegador, “Disparado” significa que a Chargefy observou o
comando do Pixel sair da página; a Meta não devolve um recibo individual desse
canal. Nenhum dos dois estados confirma atribuição à campanha.
## Definir o alcance
| Opção | O que entra |
| ----------------------------- | ------------------------------------------------------------------------ |
| **Todas as vendas** | Sessões de todos os Payment Links e sessões criadas diretamente pela API |
| **Payment Links específicos** | Somente sessões que nascerem dos links selecionados |
Uma sessão criada diretamente pela API não possui Payment Link de origem. Por
isso, ela entra no alcance amplo e fica fora de destinos restritos a links
específicos.
Você pode criar mais de um destino. Por exemplo, um conjunto de dados pode
receber todas as vendas enquanto outro recebe apenas uma oferta. A mesma sessão
pode alimentar mais de um destino quando estiver no alcance de ambos.
## Quando o alcance é congelado
O conjunto de destinos é resolvido **no momento em que a Checkout Session é
criada**. Depois disso, aquela sessão preserva o mesmo roteamento até concluir
ou expirar.
| Origem da sessão | Momento do snapshot |
| ---------------- | ---------------------------------------------------------------------------- |
| Payment Link | No clique, porque o clique cria a sessão |
| API | Na request do backend que cria a sessão, antes de o comprador abrir a página |
Isso mantém todos os eventos da mesma compra no mesmo conjunto de dados, mesmo
quando um boleto é pago dias depois.
Conectar ou mudar o alcance depois que uma Checkout Session foi criada não
inclui essa sessão retroativamente. Para sessões criadas pela API, o momento
relevante é o create do backend — não a primeira abertura no navegador.
## Separação entre teste e produção
Destinos pertencem ao ambiente em que foram criados. Uma conexão de teste
recebe apenas sessões com `livemode: false`; uma conexão de produção recebe
apenas sessões com `livemode: true`.
Isso permite validar eventos sem misturar compras simuladas aos relatórios de
produção.
## Testar a conexão
Use uma Checkout Session nova para validar o caminho real de uma compra:
Na área **Test Events** do Gerenciador de Eventos, gere o código e informe-o
no destino da Chargefy.
Abra um Payment Link incluído no destino ou crie uma Checkout Session nova
pela API. Sessões criadas antes da configuração não entram retroativamente.
A primeira abertura real produz `PageView` e `InitiateCheckout`. Não é
necessário concluir um pagamento para validar esses dois eventos.
Em **Integrações → Meta → Atividade**, procure `InitiateCheckout`. O servidor
deve aparecer como **Recebido** e o navegador como **Disparado** quando os
dois canais estiverem ativos. O evento do servidor também deve aparecer em
**Test Events** na Meta.
O código de teste acompanha os envios da Conversions API. Ele não transforma o
disparo do navegador em um recibo da Meta e não testa atribuição de campanha.
Remova o código de teste quando terminar. Ele serve para validação, não para a
operação diária da campanha.
## Se a qualidade não puder ser lida
Um token pode continuar autorizado a enviar eventos e, ao mesmo tempo, não
permitir que a Chargefy consulte as métricas de qualidade do conjunto de dados.
Nesse caso, o Dashboard mostra um aviso no destino.
O aviso não significa que o envio parou. Confira o recibo em **Atividade**. Se
também quiser acompanhar a qualidade pela Chargefy, gere outro token com
permissão de leitura dessas métricas e use **Substituir token**.
## Se o token deixar de funcionar
Quando a credencial é revogada, expira ou perde permissão, a conexão é marcada
como inválida e os novos envios são interrompidos. Gere outro token e use a ação
de substituição no destino.
## Próximos passos
Veja quando cada marco do checkout dispara.
Diferencie o recibo do servidor do disparo no navegador.