Conversões modeladas: o que o relatório do Meta não diz que é estimativa

O relatório não deixa lacunas

Um relatório de publicidade tem uma propriedade que raramente é discutida: ele é sempre preenchido. Quando uma informação não está disponível, o sistema não desenha um espaço vazio na coluna; ele produz uma estimativa do que provavelmente teria acontecido e escreve essa estimativa ao lado do que foi efetivamente observado. As duas coisas passam a ocupar a mesma célula, com a mesma formatação, sem asterisco e sem rótulo.

Publicamos pesquisa editorial: não é consultoria e não garante resultado comercial. Nada do que se descreve aqui afirma que existe um erro específico na sua conta, nem que existe um percentual fixo de distorção: os limiares citados aparecem como intervalos, são configurações de mercado sujeitas a mudança e devem ser conferidos no painel do período. Nos trechos em que tocamos em consentimento e em bases legais de tratamento de dados, registramos também que isto não é aconselhamento jurídico.

O tema deste texto é a composição do número que você lê. Não é um guia de configuração e não é uma acusação: é uma descrição de como a camada de medição se comporta quando o sinal falta.

Perda de sinal: de onde vem o buraco

A medição por plataforma depende de um encadeamento simples: um evento acontece no seu site ou no seu aplicativo, um identificador atribui esse evento a uma pessoa, e essa pessoa é reconhecida como a mesma que viu ou clicou em um anúncio. Cada elo desse encadeamento pode se romper.

Ele se rompe quando o sistema operacional pergunta ao usuário se ele aceita ser rastreado e o usuário responde que não. Rompe-se quando o navegador bloqueia cookies de terceiros por padrão. Rompe-se quando o usuário limpa dados, troca de dispositivo, navega em aba privada ou simplesmente fecha a página antes de o script terminar de carregar. Rompe-se, cada vez mais, quando a empresa instala uma barra de consentimento que recusa tags antes de haver escolha do visitante.

O resultado é que uma fração das conversões que realmente aconteceram não chega ao relatório como observação. É a perda de sinal, e ela não é um defeito pontual: é o estado normal da medição em clientes e navegadores contemporâneos. A consequência não é um número menor, como se poderia esperar. A consequência é um número estimado.

Conversões modeladas: o mecanismo

Conversões modeladas são conversões inferidas, não registradas. O procedimento é, em linhas gerais, o seguinte: o sistema observa um conjunto de usuários cujo comportamento é totalmente visível, aprende o padrão estatístico que relaciona características contextuais a resultados, e aplica esse padrão ao subconjunto de usuários cujo resultado ficou invisível. A conclusão não é que a conversão aconteceu; é que, dado o que se sabe sobre pessoas comparáveis em circunstâncias comparáveis, era provável que acontecesse.

Há uma distinção importante entre esse procedimento e uma invenção. Modelagem estatística é uma técnica legítima e amplamente usada, inclusive fora de publicidade, para lidar com dados faltantes. O problema não é a técnica; é a apresentação. Um relatório que soma observações e inferências na mesma coluna, sem distinguir uma da outra, transforma uma estimativa em um fato aparente.

O que torna o caso peculiar é a posição de quem faz a estimativa. A plataforma que decide quanto estimar é a mesma plataforma que recebe o pagamento pelos resultados reportados. Não se trata de imputar má intenção a ninguém: trata-se de reconhecer que a arquitetura da medição contém um conflito de interesses estrutural, do tipo que em outras indústrias seria resolvido com auditoria externa e que aqui é resolvido, quando muito, com a disciplina do próprio anunciante.

Como descobrir se você está afetado

O teste é simples de descrever e trabalhoso de executar. Tome a receita registrada no seu próprio sistema, seja ele um gestor de relacionamento, um processador de pagamento ou a base de pedidos, e compare com a receita atribuída pela plataforma na mesma janela de tempo e sob as mesmas regras de atribuição.

O que se procura não é igualdade. Alguma diferença sempre existe, por motivos legítimos de janela, fuso, moeda, cancelamento e devolução. O que se procura é sistematicidade. Se o número da plataforma é maior do que o seu em todos os meses, se a distância cresce quando o volume cresce, se a diferença não oscila em torno de zero mas se acumula em uma direção, então existe inflação de estimativa, e o tamanho dessa diferença é a fração do seu esforço de otimização que está sendo dirigida por números inferidos.

O inverso também merece atenção. Plataforma reportando menos do que o sistema interno costuma indicar problema de instrumentação, evento ausente ou janela mal configurada, e é um defeito diferente, com remédio diferente. O que não se deve fazer é escolher a fonte que fica melhor e passar a citá-la. Isso é seleção de resultado, não diagnóstico.

Reconciliação semanal e um índice próprio

Comparação feita uma vez não serve para nada, porque o que importa é a tendência, não o valor. O procedimento que defendemos é uma rotina fixa: mesmo dia da semana, mesma janela, mesmas regras, mesma pessoa montando o quadro, com o resultado anotado em um histórico que não é editado retroativamente.

A forma mais útil de registrar isso é um índice de inflação de conversões modeladas, calculado pela sua própria operação: razão entre o que a plataforma atribui e o que o seu sistema confirma, na mesma janela. Um índice estável em torno de um valor conhecido é perfeitamente administrável, porque passa a ser uma constante do seu planejamento. Um índice que muda de patamar sem explicação é um alerta de que algo se alterou na configuração, no consentimento ou no próprio modelo, e merece investigação antes da próxima decisão de orçamento.

A reconciliação semanal é o que transforma esse índice em instrumento. Ela cria memória institucional sobre o comportamento da medição, e memória é a única coisa que permite distinguir variação normal de mudança estrutural. Sem ela, cada relatório é lido como se fosse o primeiro.

Medição agregada de eventos e a fila de prioridades

Com a restrição de rastreamento em navegadores, a plataforma passou a operar com um número limitado de eventos por domínio. A medição agregada de eventos, frequentemente abreviada como AEM, exige que o anunciante defina quais eventos são prioritários e em que ordem. O limite costumeiramente citado para essa priorização de até oito eventos por domínio verificado, e deve ser tratado como configuração de mercado que muda com o tempo: confirme no painel do período.

A consequência prática é uma decisão de escassez. Se a sua lista de eventos foi montada por inércia, com eventos de baixo valor ocupando posições altas, o evento que sustenta a otimização pode ficar de fora do conjunto ativo em cenários restritos. Isso não aparece como erro: aparece como uma campanha que otimiza para um evento secundário e entrega resultados que parecem razoáveis dentro da lógica errada.

O critério de ordenação deve ser o valor econômico do evento, não a facilidade de instrumentação. Compra concluída e lead qualificado ficam no topo; visualização de página, rolagem e clique em botão secundário ficam abaixo. Evento de vaidade em posição alta é um custo de oportunidade disfarçado de relatório completo.

Domínio verificado não é opcional

A configuração de eventos agregados pressupõe que o domínio pertença a quem está configurando, e essa relação se estabelece pela verificação de domínio. Sem ela, a priorização fica sujeita a definições automáticas e a alterações feitas por terceiros que também apontam eventos para o mesmo domínio.

Domínio verificado é, portanto, pré-condição, não etapa opcional de capricho. É também um controle de governança: define quem pode configurar a medição daquele ativo e reduz a superfície de configurações feitas por pessoas que já não trabalham na empresa. Verificar é um procedimento curto; deixar de verificar é aceitar que a sua fila de prioridades seja definida por padrão.

Pixel e API de Conversões: onde nasce a dupla contagem

A instrumentação contemporânea costuma ter dois caminhos. O Pixel, executado no navegador, observa o evento no lado do cliente. A API de Conversões, executada no servidor, envia o mesmo evento a partir da sua infraestrutura. A combinação de Pixel + API de Conversões existe para reduzir a perda de sinal: o que o navegador deixa de reportar pode ser reportado pelo servidor.

O defeito mais comum dessa arquitetura não é técnico; é conceitual. Quando os dois caminhos enviam o mesmo evento, o sistema precisa saber que se trata de um único acontecimento. Se essa informação não estiver presente, o resultado é dupla contagem: uma conversão real registrada como duas.

A cadeia de consequências é o que torna o problema grave. Conversões em dobro elevam o retorno aparente. Retorno aparente mais alto autoriza lance mais agressivo. Lance mais agressivo eleva o custo de mil impressões. E, porque numerador e denominador foram inflados pelo mesmo fator, o retorno continua parecendo saudável na coluna de cima. Nenhum alarme dispara, porque o indicador que deveria acusar o problema foi contaminado por ele. A operação fica mais cara e mais otimista ao mesmo tempo.

ID de evento compartilhado e deduplicação

O mecanismo que evita a dupla contagem é a deduplicação, e ela depende de um detalhe: o mesmo evento enviado pelos dois caminhos precisa carregar o mesmo ID de evento compartilhado. É esse identificador que diz ao sistema que a mensagem do navegador e a mensagem do servidor descrevem um só fato.

Quando o identificador é gerado de forma independente em cada caminho, a correspondência não ocorre. Quando ele é gerado uma única vez e reaproveitado nos dois envios, funciona. A regra é simples de enunciar e surpreendentemente frequente de violar, porque em muitas implementações o evento de servidor é montado a partir de um espelho do banco de dados em que o identificador original não foi preservado.

Vale distinguir isso de um problema parecido e diferente: parâmetros de identificação de usuário inconsistentes entre cliente e servidor. Aí o efeito não é duplicação, e sim atribuição falha, com evento recebido e não associado a pessoa alguma. Os dois defeitos coexistem em muitas contas e se mascaram mutuamente: um infla, o outro subtrai, e o resultado líquido parece plausível.

Já tratamos do envio por API de Conversões e da qualidade dos parâmetros de correspondência em texto anterior desta série. Não vamos reescrever aqui a arquitetura do pipeline; basta a conexão: pipeline mal construído produz relatório mal composto, e relatório mal composto produz decisão mal fundamentada.

Event Match Quality

A plataforma atribui uma nota à qualidade dos parâmetros enviados com cada evento, o Event Match Quality. A nota expressa quanto dos dados recebidos serve para identificar a pessoa com segurança. Parâmetros de identificação presentes, normalizados e enviados nos dois caminhos elevam a nota; ausência, formato inconsistente e envio apenas parcial a derrubam.

A leitura correta dessa métrica é de qualidade, não de volume. Enviar mais campos errados não melhora nada; enviar poucos campos corretos melhora bastante. E a nota não é um objetivo em si: ela é um indicador de que a correspondência está acontecendo nas condições em que deveria acontecer.

O ponto de conexão com o tema deste texto é direto. Quanto menor a qualidade da correspondência, maior a fração de eventos que não pode ser atribuída com segurança e maior o espaço deixado para preenchimento por estimativa. Melhorar parâmetros é, portanto, uma forma de reduzir a dependência de modelagem, e não apenas um exercício de conformidade técnica.

Janela de atribuição: o número depende da régua

A pergunta sobre quantos dias após o clique uma conversão ainda conta para o anúncio não tem resposta natural; tem resposta convencional. A configuração frequentemente oferecida como padrão é clique de 7 dias combinado com visualização de 1 dia. Outra configuração comum é clique de 1 dia. As duas descrevem realidades diferentes e geram números diferentes para exatamente o mesmo gasto e exatamente o mesmo resultado.

Relatos de mercado situam a distância entre configurações amplas e restritas na casa de dezenas de pontos percentuais, com variação grande conforme ciclo de compra e ticket. Trate isso como intervalo e confirme no seu próprio histórico. O que se pode afirmar sem depender de intervalo é a direção: ampliar a janela aumenta o número atribuído, porque mais resultados caem dentro dela.

A implicação para gestão é anterior à discussão de performance. Antes de dizer que uma campanha melhorou ou piorou, é preciso registrar qual janela estava ativa em cada período, porque comparar meses com janelas diferentes é comparar réguas diferentes. A janela de atribuição deve estar documentada, fixada e citada em todo relatório interno. Só depois se discute desempenho.

Visualização sem clique e o que ela compra

A visualização sem clique é a atribuição de uma conversão a um anúncio que foi visto e não clicado. Ela existe porque impacto publicitário frequentemente não se manifesta como clique imediato, e porque medir apenas o clique subestima o efeito de formatos de pouco clique.

O problema é que ela é também o componente mais vulnerável a inflação. Um modelo pode atribuir a uma impressão uma conversão que teria acontecido de qualquer maneira, e não há como o anunciante distinguir esse caso de um impacto real olhando apenas o relatório agregado. Por isso a recomendação analítica é separar sempre as duas coisas: observar o resultado com e sem visualização sem clique, e tratar a diferença como uma estimativa de segunda ordem, não como resultado consolidado.

Essa separação também resolve parte da conversa sobre discrepância. Boa parte das divergências entre sistemas vem exatamente de um deles considerar impressão e o outro não.

Discrepância estrutural entre plataforma, GA4 e CRM

Três sistemas registrando o mesmo período raramente concordam, e a tentação é procurar o sistema errado. Na maior parte dos casos, nenhum está errado: eles estão medindo coisas diferentes com regras diferentes.

A plataforma de anúncios atribui segundo suas próprias janelas, inclui impressão e conta a partir do momento do clique. Uma ferramenta de analítica como o GA4 costuma operar com modelo próprio de último clique não direto, janelas distintas e recorte de sessão. O gestor de relacionamento registra a oportunidade na data em que ela entra no funil comercial, não na data do anúncio que a originou.

Some-se a isso fusos diferentes, moedas diferentes e tratamentos diferentes de cancelamento, e o resultado é uma discrepância estrutural. Não é defeito a ser corrigido; é consequência de definições distintas. Tentar fazer os três números baterem é um projeto que consome semanas e devolve pouco.

O que funciona é hierarquia. Define-se uma fonte de verdade externa, de preferência o próprio sistema de receita, e ela passa a ser a referência para decisões que envolvem dinheiro: orçamento, meta, comissão, projeção. Os números de plataforma passam a ser indicadores de direção, úteis para comparar variações dentro de uma mesma configuração e não confiáveis como medida absoluta de resultado. Essa escolha é uma decisão de governança e precisa ser explícita, porque na ausência dela cada área cita o número que lhe convém.

Regra de 72 horas e revisão em até 28 dias

Relatório de plataforma não é fotografia; é estado provisório. Conversões podem ser revisadas depois de registradas, à medida que eventos atrasados chegam, que atribuições são recalculadas e que duplicações são resolvidas. O horizonte mais citado para essa revisão de dados em até 28 dias, e deve ser lido como intervalo de mercado, sujeito a mudança e a confirmação no painel do período.

A distribuição dessas revisões é desigual. Observação recorrente de mercado é que a maior parte do ajuste acontece nos primeiros dias, com uma fração substancial concentrada nas primeiras 72 horas. Daí uma regra operacional simples, a que chamamos aqui de regra de 72 horas: decisões de pausa tomadas com dados do próprio dia estão sendo tomadas sobre uma fração do resultado final, frequentemente algo entre 40% e 60% dele, com variação por tipo de conversão e ciclo de compra.

A consequência é prática e diz respeito a velocidade. Usar o retorno do dia para desligar uma campanha é pisar no freio com o carro ainda acelerando: os números que chegariam nas horas seguintes poderiam inverter a conclusão. Isso não significa nunca agir rápido; significa separar decisões reversíveis de decisões estruturais e reservar janelas curtas apenas para o que pode ser revertido sem custo.

Consentimento: o descompasso entre cliente e servidor

Há um defeito que é simultaneamente jurídico e estatístico. Se a barra de consentimento bloqueia tags no navegador antes da escolha do visitante, mas o servidor continua enviando eventos para a plataforma independentemente dessa escolha, os dois lados passam a operar sobre populações diferentes. O painel passa a mostrar o comportamento de uma população que inclui pessoas que recusaram medição.

Isso é risco de conformidade, porque o tratamento está ocorrendo sem base alinhada à escolha manifestada, e também é risco analítico, porque a amostra deixa de corresponder à população sobre a qual se decide. Em termos de medição, o efeito é perverso: a estimativa passa a ser alimentada por uma amostra enviesada, e o viés não é visível no relatório.

O mesmo cuidado vale para ofertas com consentimento, isto é, para os pontos da jornada em que consentimento é obtido em troca de acesso a material ou condição. Nesses pontos, o consentimento precisa valer para os dois caminhos de envio, não apenas para o navegador. Coerência entre cliente e servidor é pré-requisito de qualquer relatório que se pretenda usar para decidir.

Por que a estimativa se propaga

Um número de relatório raramente fica no relatório. Ele alimenta modelos de atribuição multitoque, que distribuem crédito entre pontos de contato e orientam decisões táticas de semana a semana. Ele alimenta também exercícios de modelagem de mistura de mídia, usados para decisão de orçamento trimestral. As duas camadas têm funções diferentes e são complementares: uma é tática, outra é estratégica.

As duas, porém, dependem de insumos corretos. Um modelo multitoque construído sobre conversões parcialmente estimadas é um modelo de várias camadas erguido sobre uma base que já contém suposição. Ele não fica menos sofisticado por isso; fica menos confiável de um modo mais difícil de perceber, porque a sofisticação da camada superior esconde a fragilidade da inferior.

Modelagem de mistura tem uma propriedade diferente que a torna, nesse aspecto, mais robusta: trabalha com dados agregados e séries longas, e por isso é menos sensível a ruído de identificador. Ainda assim, se a série de entrada estiver inflada de forma sistemática e crescente, o coeficiente estimado para o canal estará errado na mesma direção. Nenhum método downstream conserta um insumo torto.

O que este texto não é: teste de incrementalidade

É importante não misturar duas perguntas que parecem próximas e são diferentes. A pergunta deste texto é de composição: dentro do número que estou lendo agora, quanto foi observado e quanto foi inferido. A pergunta do teste de incrementalidade é de causalidade: este resultado teria acontecido se eu não tivesse veiculado este anúncio.

O teste de incrementalidade responde à segunda pergunta com desenho experimental, comparando grupos expostos e não expostos. Ele é o instrumento adequado para saber se uma campanha gera ou apenas colhe. Ele não informa, porém, qual fração do seu relatório diário é estimativa, e não substitui a reconciliação com fonte externa. Já tratamos de desenho de teste em texto anterior desta série; aqui apenas marcamos a fronteira, porque confundir as duas coisas leva empresas a comprar um experimento quando o problema era de leitura de relatório.

O limite honesto

Nada do que foi descrito permite afirmar que a sua conta tem uma inflação de determinado tamanho. A plataforma não publica a proporção de resultado modelado por campanha de forma padronizada, e qualquer valor exato que apareça em material de terceiros deve ser tratado como estimativa de estimativa. O que se pode fazer, e é suficiente, é medir a sua própria distância entre plataforma e sistema interno com método constante e conviver com esse número em vez de ignorá-lo.

A recomendação final é de postura, não de ferramenta. Documente janela de atribuição antes de discutir desempenho. Estabeleça uma fonte de verdade externa antes de discutir orçamento. Adote a regra de 72 horas antes de discutir pausa. E mantenha o índice de inflação de conversões modeladas como uma constante explícita do seu planejamento, com o mesmo status de uma taxa de cancelamento ou de um prazo médio de recebimento.

Isso não garante que a decisão seguinte seja correta. Garante apenas que ela seja tomada sabendo de que material o número foi feito, o que é uma condição mínima e, curiosamente, ainda rara.