Atribuição view-through: por que Meta e seus dados não batem

Uma venda que analisamos recentemente parecia, à primeira vista, bug de tracking.

O nosso tracker tinha a visita inteira registrada. A pessoa entrou pelo link da bio do Instagram da marca, caiu na página de vendas, foi pro checkout e pagou. Uma sessão, uma origem clara.

O Gerenciador de Anúncios da Meta creditou a mesma compra a um anúncio estático. Pelo que o site conseguia ver, esse anúncio não tinha mandado ninguém: nenhuma sessão com clique dele, nenhuma UTM dele, nada na página de vendas.

Aí quem comprou trouxe uma terceira versão: depois, contou que finalizou a compra no computador.

• O nosso tracker: a venda veio da bio do Instagram.
• A Meta: a venda é de um anúncio estático.
• Quem comprou: a venda aconteceu no computador.

O reflexo é decidir quem está mentindo, e agir nesse reflexo custa dinheiro. É assim que anúncio que funcionava acaba pausado, e que anúncio que só estava perto da venda continua recebendo verba. Ninguém nessa história está mentindo. Cada fonte responde a uma pergunta diferente, com um pedaço diferente da jornada, e quando você enxerga qual pedaço está com cada uma, as três respostas se encaixam.

Este artigo desmonta essa venda: o que a atribuição da Meta conta em 2026, como um anúncio ganha crédito sem gerar visita, por que isso não depende de fbclid, onde entra o segundo aparelho, e o que um tracker no seu próprio domínio deve (e não deve) tentar fazer a respeito.

Três perguntas que parecem uma só

Quase toda a confusão vem de tratar três perguntas diferentes como se fossem uma.

De onde veio a sessão que converteu? É isso que um tracker first-party (um tracker que roda no seu próprio domínio) consegue observar: o referrer, as UTMs, os IDs de clique, a página de entrada. Se a visita que terminou em compra entrou pela bio do Instagram, registrar "bio do Instagram" como origem está certo. Não quer dizer que a bio foi o primeiro contato da pessoa com a marca. Quer dizer que foi ali que essa sessão começou.

Essa pessoa interagiu com algum anúncio nosso dentro da janela de atribuição? Essa é a pergunta da Meta, e é outra pergunta. Um anúncio pode receber crédito por uma conversão sem ter gerado a sessão em que a conversão aconteceu. A Meta não precisa que o anúncio tenha trazido a visita. Precisa de uma interação elegível entre aquela pessoa e aquele anúncio, dentro da janela que o conjunto usa.

A venda teria acontecido sem o anúncio? Isso é causalidade, ou incrementalidade, e nenhuma das duas primeiras responde. Se um anúncio foi exibido pra alguém que comprou oito horas depois, isso pode bastar pra uma atribuição view-through. Não prova que a venda dependeu do anúncio. A própria Meta faz essa separação: no mesmo anúncio de março de 2026 em que mudou a atribuição, ela diz que experimentos de incrementalidade, como o Conversion Lift dela, são o melhor jeito de responder essa pergunta.

Então, quando Meta, GA4 e o seu tracker mostram origens diferentes pra mesma compra, isso não é prova de erro. Na maioria das vezes é prova de que você está lendo três respostas pra três perguntas.

O que a atribuição da Meta conta em 2026

Pensa numa campanha otimizada pra compras no seu site. Em 2026, a configuração de atribuição dela, no modelo de atribuição padrão da Meta, costuma combinar três janelas:

• Clique de 7 dias (click-through): a pessoa clicou num link do anúncio e converteu em até sete dias.
• Engajamento de 1 dia (engage-through): a pessoa clicou no anúncio em qualquer lugar que não fosse um link (curtida, comentário, compartilhamento, salvamento) ou assistiu pelo menos cinco segundos de vídeo, e converteu em até um dia.
• Visualização de 1 dia (view-through): o anúncio foi exibido pra pessoa, sem nenhuma interação, e ela converteu em até um dia.

A janela do meio é nova. Até março de 2026, a atribuição por clique contava qualquer clique no anúncio, então quem curtiu na segunda e comprou na sexta podia aparecer como conversão por clique. Em março de 2026, a Meta mudou a definição pra conversões em sites e em lojas físicas: atribuição por clique passou a significar clique em link, e todo outro clique foi pro que antes se chamava atribuição de visualização com engajamento, agora atribuição por engajamento (engage-through), com janela própria de um dia. As visualizações de vídeo ficam nesse mesmo balde, e a Meta baixou o mínimo de uma visualização com engajamento de 10 pra 5 segundos. A mudança foi liberada aos poucos, então algumas contas ainda podem mostrar os nomes antigos.

Duas consequências importam pra todo o resto:

1. Conversão creditada a um anúncio que não gerou sessão não é automaticamente view-through. Pode ser um clique em link de dias antes, um engajamento ou uma visualização.
2. Essas janelas não mexem só no relatório. Segundo a própria Meta, a atribuição padrão otimiza a entrega pras janelas de tempo e os comportamentos selecionados, então elas também decidem quem vê o anúncio.

Como um anúncio ganha crédito por uma venda que ele não trouxe

Duas linhas do tempo deixam isso concreto.

Um clique do começo da semana.

Segunda → clica no anúncio, dá uma olhada, sai
Quinta  → digita o endereço e volta
Quinta  → Purchase

A sessão de quinta é direta. A Meta credita o anúncio como conversão por clique, porque houve um clique elegível em link três dias antes da compra. Os dois estão certos sobre o que descrevem.

Um bom tracker first-party faz algo parecido dentro de um mesmo navegador. No Supreme, por exemplo, uma visita que volta direto em até sete dias herda a origem da última visita que tinha uma, então a compra de quinta cai na campanha de segunda. O limite está nas palavras "um mesmo navegador". Guarda isso pra seção sobre aparelhos.

Uma impressão algumas horas antes.

14:00 → o anúncio aparece no feed
17:00 → a pessoa procura a marca e abre o perfil
17:05 → toca no link da bio
17:15 → Purchase

O seu tracker vê bio do Instagram → Purchase. A Meta tem um fato a mais, que o seu site nunca recebeu: o anúncio A foi exibido pra essa pessoa às 14:00. Se a Meta conseguir ligar a compra a essa pessoa, o anúncio A pode levar o crédito como conversão view-through.

O anúncio gerar uma sessão simplesmente não é requisito. É essa a parte que quebra a intuição de quem se acostumou a ler atribuição como "quem trouxe a visita".

Por que view-through não precisa de fbclid, e o que o fbc é de verdade

A objeção de sempre a essa altura: o anúncio nunca gerou fbclid, então como a Meta ligou ele à venda?

Não precisou. A impressão acontece inteira dentro da infraestrutura da Meta, onde a plataforma já registra algo como o anúncio Y foi exibido pra pessoa X no horário Z. Nada precisa chegar ao seu site pra esse registro existir. Atribuição view-through não depende de fbclid nem de fbc associado à impressão, porque impressão não gera nenhum dos dois.

O fbc é um identificador de clique. Ele nasce quando alguém clica num link dentro de um app da Meta e a URL chega ao seu site com ?fbclid=…. O site guarda isso no cookie _fbc, e o seu servidor pode enviar depois, junto com o evento, pela API de Conversões. O valor segue um formato documentado, fb.1.<momento de criação>.<fbclid>. A documentação da Meta explica como montar esse valor a partir do fbclid quando não há cookie, e a Meta publica uma biblioteca pequena, o CAPI parameter builder, que monta ele pra você.

Dois detalhes pesam mais do que parecem.

fbclid não significa tráfego pago. A documentação da Meta só descreve o parâmetro em clique de anúncio, mas não é só ali que ele aparece. Desde o fim de 2018, tem gente relatando fbclid em link compartilhado organicamente no Facebook, e glossários técnicos listam o parâmetro em tráfego orgânico vindo de Instagram, Messenger e Threads. Trate esses casos como observados, não como documentados. De qualquer forma, um fbclid, ou um fbc, diz que o visitante clicou num link dentro de um app da Meta. Não prova que ele clicou num anúncio. Pra saber se a visita foi paga, você precisa de parâmetros que você controla: UTM em todo anúncio. O gerador de UTM mostra em que canal cada link vai cair antes de você publicar.

O número do meio é a hora do clique. A documentação da Meta define esse número como o momento em que o cookie _fbc foi gravado ou, se você não guarda o cookie, o momento em que você viu o fbclid pela primeira vez. Um servidor que só remonta o fbc quando a compra chega, digamos pelo webhook do checkout dois dias depois do clique, está dizendo pra Meta que o clique aconteceu na hora da venda. Seja lá o que a Meta faça com esse horário, ela está trabalhando com um fato errado. É um erro fácil de cometer: o nosso próprio Node cometia em compras registradas pelo servidor até a versão 3.7.1, em setembro de 2026. Desde então, ele só monta um fbc a partir do fbclid em eventos registrados no navegador, durante a visita, e nos outros casos envia o fbc que de fato observou.

O segundo aparelho

O comentário de quem comprou, de que a compra foi feita no computador, é onde a maioria das explicações first-party para de funcionar e a da Meta segue em frente.

A política de privacidade da Meta diz que ela coleta e recebe informações de e sobre os diferentes aparelhos que você usa, e que combinar essas informações entre os seus aparelhos é parte de como ela ajuda as empresas a medir o desempenho dos anúncios. O exemplo da própria política é uma jornada do celular pro notebook: um anúncio exibido no celular e, depois, o clique e a compra feitos no notebook. Um tracker restrito ao seu domínio não tem nada parecido. Pro seu site, o navegador do celular e o do computador são dois visitantes diferentes, a não ser que alguma coisa ligue os dois, como um login.

CELULAR      pessoa X → recebe uma impressão do anúncio A
                ...depois...
COMPUTADOR   pessoa X → seu site → Purchase

O seu site pode nunca ter um único identificador provando que esses dois navegadores são da mesma pessoa. A Meta pode ter vários. O que vai junto com a compra pela API de Conversões é o que dá à Meta a chance de tentar:

• e-mail e telefone, normalizados e com hash;
• external_id, um ID estável que você atribui ao visitante;
• endereço IP e user agent, em texto puro, como a Meta pede;
• fbc e fbp, os identificadores de clique e de navegador.

A própria orientação da Meta sobre qualidade da correspondência de eventos coloca e-mail e ID de clique entre os identificadores de prioridade alta, e o ID do navegador, o external_id e o telefone como prioridade média.

Nenhum deles é uma impressão. São sinais que a Meta usa pra reconhecer quem fez a compra. Sabendo quem, ela consegue consultar o que foi exibido pra essa pessoa e o que ela clicou, em qualquer aparelho em que use os apps dela.

Reconstruindo a venda, com cuidado

Aqui vai uma reconstrução plausível do caso do começo. Plausível é a palavra-chave: de fora da Meta, ninguém consegue ver qual sinal decidiu esse casamento específico.

1. No celular, o anúncio estático A é exibido pra pessoa.
2. Depois, abre o perfil da marca no Instagram.
3. No computador, clica no link da bio. Um fbclid pode vir junto com o clique e virar fbc.
4. No seu site: bio, página de vendas, checkout, compra.
5. O seu servidor envia a compra pela API de Conversões, com os dados de cliente que tem.
6. A Meta liga a compra à pessoa X.
7. A Meta acha uma impressão elegível do anúncio A dentro da janela.
8. O anúncio A leva o crédito.

Se a impressão aconteceu até um dia antes da compra, isso é exatamente o que a visualização de 1 dia descreve.

O que é documentado: o fbc pode ser montado a partir do fbclid; a API de Conversões aceita ele junto com e-mail, telefone, IP, user agent, fbp e external_id; a Meta diz que combina informações entre aparelhos; e a Meta mantém o próprio registro de que anúncio mostrou pra quem.

O que ninguém de fora da Meta pode afirmar: que o fbc da bio foi o identificador que ligou o computador ao celular, ou que ele foi decisivo em alguma coisa. A versão honesta é que o fbc pode ter contribuído pro casamento, junto com os outros identificadores que a API de Conversões levou e com o que a Meta já sabia sobre aquela pessoa.

Tem mais uma armadilha nessa história. O clique na bio pode muito bem ter gerado um fbclid, mas não foi um clique no anúncio estático. Desde março de 2026, click-through em conversão no site exige clique em link do próprio anúncio. Então a mesma compra pode carregar um clique orgânico na bio, que explica a sessão, e um crédito view-through pro anúncio, que explica o número do anúncio. Dois fatos diferentes sobre uma venda só.

Evento recebido não é evento atribuído

Um tracker server-side tem dois trabalhos aqui: capturar o evento direito e entregar o evento direito. A atribuição acontece depois, do lado da Meta, e é outro problema.

Uma compra que a Meta recebeu não é automaticamente uma compra que a Meta atribuiu. Os eventos enviados pela API de Conversões são processados como os do Pixel, mas a Meta ainda precisa ligar cada um a uma pessoa e, depois, achar uma interação elegível dessa pessoa com algum anúncio dentro das janelas configuradas. A própria documentação da Meta sobre qualidade da correspondência diz isso com todas as letras: evento correspondido é o que ajuda a atribuir conversões aos seus anúncios. Algumas compras passam pelas duas etapas. Outras não.

É por isso que melhorar os identificadores que você envia pode subir as compras no Gerenciador sem subir as suas vendas em uma unidade sequer.

Pensa em 100 vendas reais. Antes, a Meta liga e atribui 55. Depois que você arruma os dados que o servidor envia, ela atribui 70. Vendas: continuam 100. O que cresceu foi a capacidade da Meta de casar. Isso tem valor: conversão que a Meta não consegue ligar a ninguém ensina muito pouco pra entrega dela, então casar melhor dá mais material pra ela aprender. Mas o primeiro efeito é no relatório, não na conta bancária. Quando alguém te disser que a ferramenta "aumentou as conversões em 30%", pergunta de qual número está falando: do Gerenciador ou do painel da Hotmart.

A mesma lógica explica por que as plataformas não dividem as suas vendas entre si. A Meta credita pelas janelas da Meta, o Google pelas do Google. A mesma compra pode ser reivindicada pelas duas, legitimamente, cada uma pelas próprias regras. Some o que cada plataforma reporta e você chega fácil num total maior que as vendas reais. E a mesma venda aparece diferente dependendo de onde você olha:

Quantas vendas você fez sai da sua loja ou do seu checkout. A atribuição diz quem está reivindicando crédito por elas.

Como investigar uma venda dessas no Gerenciador de Anúncios

Quando um resultado aparece num anúncio que parece não ter trazido ninguém, não chuta. Abre a comparação de configurações de atribuição (Compare attribution settings, no Gerenciador em inglês), ou quebra os resultados por configuração de atribuição, e vê em que janela a compra caiu. Os nomes mudam de uma tela pra outra (a própria Meta chama o balde do meio de "engajamento" num lugar e de "engage-through" em outro), mas os baldes são estes:

Depois coloca isso do lado do que o seu tracker registrou pra mesma compra: a origem da sessão, se ela trazia fbclid, e as visitas anteriores de quem comprou. Juntando os dois, você chega numa resposta bem mais confiável sobre qual mecanismo gerou o crédito.

Remarketing é onde o view-through merece mais desconfiança

View-through pede atenção especial em remarketing. Quem já conhece a marca, está na sua lista, recebeu seu e-mail ou sua mensagem no WhatsApp, ou já ia comprar de qualquer jeito, é exatamente a pessoa com mais chance de receber uma impressão de anúncio e comprar algumas horas depois por outro canal.

A Meta pode creditar essa venda à impressão mesmo que o anúncio não tenha mudado nada. Isso não é trapaça da Meta: o modelo está fazendo o que diz que faz. E é por isso que atribuição e incrementalidade precisam ser lidas separadas, principalmente em público quente.

Pra quem vende por lançamento, esse é o cenário normal, não a exceção. Com o carrinho aberto, a lista recebe e-mail, o grupo de WhatsApp recebe mensagem, o remarketing roda pra todo mundo que passou pela página, e muita gente que compra recebeu impressão de algum anúncio naquele mesmo dia. O Gerenciador vai creditar muitas dessas vendas aos anúncios. Algumas foram mesmo decididas por eles. Outras aconteceriam de qualquer jeito. Se a pergunta é "esse remarketing se paga?", a ferramenta é um teste de incrementalidade com grupo de controle, como o Conversion Lift da própria Meta, não a coluna de atribuição.

O que o seu tracker deve fazer, e o que ele não deve fingir

Um tracker first-party nunca vai reproduzir a atribuição da Meta, e nem deve tentar. Ele não tem as impressões, o histórico de interações dentro do Instagram e do Facebook, a identidade logada nem o grafo entre aparelhos. Ferramenta que promete bater com o Gerenciador está copiando o número da Meta ou inventando um.

O que ele pode fazer é manter os dois lados honestos:

• Capturar a venda e ligar ela à sessão de onde veio, inclusive a compra que a Hotmart, a Kiwify ou a Yampi confirmam fora do navegador, sempre que der pra reconhecer quem comprou.
• Guardar os identificadores de clique com a hora certa. Guardar o fbclid e o fbc observados no clique e mandar os reais junto com a compra, em vez de fabricar um fbc novo quando a venda chega.
• Mandar os dados de cliente do jeito que a Meta pede. E-mail e telefone normalizados e com hash, IP e user agent em texto puro, um external_id estável. Hash no IP não protege ninguém; só deixa o campo inútil pro casamento.
• Conferir se a Meta de fato ingeriu o evento. HTTP 200 não é prova. A resposta da Meta diz quantos eventos ela recebeu, e 200 com zero recebidos é falha e tem que aparecer como falha.
• Colocar as duas leituras na mesma tela, com nome. As conversões da Meta do lado da receita que os seus próprios registros ligam a cada anúncio, sabendo que elas medem coisas diferentes.

Foi assim que a gente construiu o Supreme. O Node roda no seu servidor, no seu domínio, e guarda a sessão, os identificadores de clique e a compra no seu próprio banco. Ele envia a compra pra Meta pela API de Conversões, registra a entrega como falha quando a Meta responde OK mas não ingere nada, e guarda o código de rastreio e os avisos da própria Meta pra quando você precisar. No Console, Insights → Meta Ads mostra os números da própria Meta do lado da receita que o seu Node mediu, por anúncio, a partir do momento em que os seus anúncios levam o ID no utm_content. As duas leituras ficam lado a lado em vez de competir, e agora você sabe por que elas não vão bater.

O que dá pra provar, e o que não dá

O seu tracker sabe o que aconteceu na sua propriedade. A Meta sabe o que aconteceu dentro dos apps dela, e quem a pessoa provavelmente é. Quem comprou sabe o resto. A API de Conversões é a ponte que deixa a Meta atribuir uma jornada que o seu site nunca conseguiria reconstruir sozinho, e o objetivo razoável é que cada lado esteja certo sobre a própria metade.

Quer ver as duas leituras na mesma tela? Instale seu primeiro Node, grátis e sem cartão de crédito, e depois conecte sua conta de anúncios da Meta.

Fontes

• Simplificando a mensuração de anúncios para um mundo social-first — Meta, 3 de março de 2026
• Configurações de atribuição: clique, engajamento e visualização — Central de Ajuda para Empresas da Meta
• Qualidade da correspondência de eventos — Central de Ajuda para Empresas da Meta
• Política de Privacidade: informações de e entre os aparelhos que você usa — Meta
• API de Conversões — Meta for Developers
• Os parâmetros fbp e fbc — Meta for Developers
• Parâmetros de informações do cliente — Meta for Developers
• CAPI parameter builder — Meta, no GitHub
• Meta Business SDK para Ruby — UserData server-side
• How Meta Ads Attribution Works in 2026 — Jon Loomer
• Click-Through Attribution Now Requires a Link Click — Jon Loomer
• Meta Ads Attribution Reporting: What Your Results Really Mean — Jon Loomer
• fbclid num link compartilhado organicamente, outubro de 2018 — discussão no Hacker News
• What Is fbclid? — AffBuddy (fonte secundária sobre fbclid em tráfego orgânico)