> ## 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.
# Ver aquisição e diagnosticar eventos da Meta
> Acompanhe aquisição e receita e diferencie o recibo do servidor do disparo do Pixel no navegador.
Use duas visões diferentes:
* **Dashboard → Aquisição** para saber qual campanha trouxe sessões, pagamentos
e receita;
* **Integrações → Meta → Atividade** para inspecionar separadamente a evidência
do servidor e a do navegador.
Uma mede resultado de negócio. A outra diagnostica transporte técnico.
## Relatório de aquisição
O relatório agrupa o primeiro contexto da Checkout Session por:
* origem (`source`);
* mídia (`medium`);
* campanha (`campaign`).
Para cada grupo, você acompanha:
| Métrica | O que significa |
| --------- | --------------------------------------------- |
| Sessões | Checkout Sessions capturadas no período |
| Enviados | Sessões em que o comprador enviou o pagamento |
| Aprovados | Sessões que terminaram com pagamento aprovado |
| Recusados | Tentativas recusadas associadas ao grupo |
| Receita | Valor dos pagamentos aprovados |
| Conversão | Relação entre sessões e aprovações |
Filtros de origem, mídia e campanha ajudam a isolar uma ação específica sem
misturar taxonomias diferentes.
## Como Pix e boleto entram no período
O período pertence à **captura da aquisição**, não ao dia em que o pagamento
compensou.
Exemplo:
1. a pessoa abre o checkout na segunda-feira;
2. gera um boleto;
3. paga na quinta-feira;
4. a receita atualiza retroativamente a campanha capturada na segunda-feira.
Isso responde à pergunta de marketing correta: qual campanha iniciou a compra.
O relatório financeiro pode continuar usando a data real da aprovação para
conciliação.
## Origem `direct`
Uma sessão aparece como `direct` quando não possui `utm_source` nem um
identificador conhecido que permita classificar a plataforma.
Antes de concluir que a venda foi realmente direta, confira:
* se a URL publicada continha UTMs;
* se a landing page carregou Chargefy.js;
* se o botão final apontava para uma URL reconhecida;
* se a sessão criada pela API recebeu `marketing_attribution`;
* se um first-touch direto antigo estava salvo no navegador de teste.
## Atividade da Meta
Cada linha representa uma ocorrência do funil, com a data e a hora exatas em
que ela aconteceu, e mostra duas colunas de evidência: **API do servidor** e
**Pixel do navegador**. Elas não usam a mesma régua, porque somente a API do
servidor devolve um recibo individual. Os filtros acima da tabela cortam por
destino, evento (um ou vários), status do servidor e período.
O detalhe da ocorrência reúne:
* evento, destino, valor e identificador compartilhado para deduplicação;
* tentativas, código HTTP, quantidade recebida e rastreio devolvido pela Meta no
canal de servidor;
* horário em que o comando do Pixel foi observado no navegador;
* último erro, mensagens da Meta e dados enviados.
### Estados da API do servidor
O canal de servidor envia o evento pela Conversions API e guarda o recibo que a
Meta devolve. É o único canal com confirmação individual por evento.
| Estado | O que significa | O que fazer |
| ------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| **Aguardando** | O evento está na fila e ainda será enviado | Nada — o envio sai em instantes |
| **Recebido** | A Meta confirmou pelo menos um evento recebido | Nada — a entrega técnica está comprovada |
| **Resposta 2xx** | Registro histórico: a API respondeu com sucesso, mas o recibo não foi salvo | Nada — eventos novos já guardam o recibo completo |
| **Sem confirmação** | A resposta não confirmou nenhum evento recebido | Abra o detalhe e leia as mensagens devolvidas pela Meta |
| **Falhou** | Houve erro e ainda pode existir nova tentativa | Veja o código de erro no detalhe; credencial recusada pede a substituição do token |
| **Descartado** | A janela de tentativas terminou sem recebimento confirmado | Corrija a causa mostrada no detalhe; este evento não será reenviado |
| **Ignorado** | O evento não foi tentado | Confira o motivo no detalhe: evento fora da janela que a Meta aceita ou destino/canal desativado |
| **Sem registro** | Não existe envio de servidor para esta ocorrência | Esperado em destino somente navegador; ative o canal de servidor para ter recibo da Meta |
### Estados do Pixel no navegador
O canal de navegador executa o comando do Pixel na página do checkout. A Meta
não devolve recibo por evento nesse canal, então o status registra o que a
Chargefy conseguiu observar na página.
| Estado | O que significa | O que fazer |
| ----------------- | --------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| **Planejado** | O evento ficou pronto para sair, mas ainda não há observação do Pixel | Aguarde — a página reporta o disparo logo depois de renderizar |
| **Disparado** | A Chargefy observou o comando do Pixel ser executado na página | Nada — é o estado final deste canal |
| **Bloqueado** | O Pixel não ficou disponível para executar o comando | Teste sem bloqueador de anúncios e revise o consentimento exigido na página |
| **Não observado** | A página não devolveu uma observação do disparo dentro da janela | Esperado quando a confirmação acontece com a página fechada, como um Pix pago depois |
| **Sem registro** | Não existe tentativa do Pixel para esta ocorrência | Confira se o canal de navegador está ativo no destino; sem página aberta, só o servidor envia |
**Recebido** confirma ingestão técnica pela API da Meta. **Disparado**
confirma apenas o comando no navegador. Nenhum dos dois estados prova
atribuição a uma campanha, uso na otimização ou contabilização final pela
Meta.
## Diagnóstico por sintoma
### A campanha não aparece no relatório
1. abra a Checkout Session e confira `marketing_attribution`;
2. veja `capture_point` e `source`;
3. confirme se a UTM estava na primeira entrada, não em um reload posterior;
4. verifique se a data filtrada inclui `captured_at`.
### A compra aparece como direta
Confirme se `utm_source` ou um click ID conhecido chegou ao primeiro ponto de
captura. Em landing pages, limpe o `localStorage` ou use janela anônima para não
reaproveitar um contexto direto de teste.
### O servidor não aparece como recebido
1. confirme se o destino já existia quando a sessão foi criada;
2. confira ambiente, alcance e se o canal de servidor está ativo;
3. abra o detalhe e veja quantidade recebida, código HTTP, rastreio e mensagens;
4. substitua o token se a conexão estiver inválida;
5. para uma prova controlada, informe um código de **Test Events** e abra uma
Checkout Session nova.
### O navegador não aparece como disparado
1. confirme se o canal de navegador está ativo no destino;
2. abra a página hospedada da Checkout Session, não apenas a URL de retorno;
3. confira se a sessão está dentro do alcance resolvido quando ela foi criada;
4. teste sem bloqueador de anúncios e com o consentimento necessário;
5. lembre que pagamentos confirmados depois que a página fechou podem ter apenas
o envio do servidor.
### A Meta não mostra o evento no painel
Se o servidor está como **Recebido**, a Meta confirmou a ingestão. O painel da
Meta ainda pode levar outro tempo ou aplicar correspondência, deduplicação,
consentimento e regras de atribuição antes de exibir ou usar o evento.
Se o destino avisa que não consegue ler qualidade, isso não significa falha no
envio. O token pode enviar eventos sem permitir a consulta dessas métricas. Use
o recibo da atividade como evidência técnica ou substitua o token para liberar
também a leitura de qualidade.
### A venda parece duplicada
Compare o `event_id` das entregas. Pixel e servidor devem compartilhar o mesmo
identificador. Se outro sistema também envia o evento, ele precisa usar a mesma
estratégia de deduplicação para o mesmo acontecimento.
## Limites atuais
* o destino de conversão automatizado disponível é a Meta;
* identificadores de Google, TikTok e Microsoft são capturados para atribuição,
mas não são enviados automaticamente a esses destinos;
* o Dashboard copia a URL-base e o QR code-base do Payment Link; monte uma URL
com UTMs antes de gerar um QR code rastreado;
* não existe um construtor de UTMs no Dashboard;
* o canal do servidor termina em “Recebido” e o do navegador em “Disparado”; a
atribuição final só pode ser avaliada na plataforma de mídia.
## Relacionado
Descubra por que uma origem venceu outra.
Confira nomes, limites e regras de validação.