Como analisar impressões não preenchidas e recuperar receita perdida

Se o Google Ad Manager mostra impressões não preenchidas, vá direto ao segmento que está perdendo oportunidades. A discussão genérica sobre taxa de preenchimento pode esperar. Identifique se o bloqueio está no preço, na elegibilidade, na resposta da demanda ou no tempo de execução da página e priorize a correção na fila de tarefas. A análise só serve se virar um chamado que alguém consiga resolver.

Principais pontos

• Trate as impressões não preenchidas primeiro como um problema de segmento, não como um diagnóstico do site inteiro.
• Use as dimensões do GAM para separar problemas gerais de veiculação de perdas em um único slot.
• Pressão dos pisos de preço, lacunas de segmentação e latência deixam sinais diferentes; não aplique a mesma correção.
• Priorize as correções pela receita em risco, pelo grau de confiança no diagnóstico e pelo esforço necessário, para direcionar o tempo da engenharia ao que traz retorno.
• Os alertas devem detectar quedas na taxa de preenchimento logo no início, mas o ganho real é ter uma fila clara de correções após o diagnóstico.

Onde as impressões não preenchidas aparecem no Google Ad Manager

Para analisar inventário não preenchido no Google Ad Manager, monte o relatório com os campos que ajudam a explicar a veiculação: bloco de anúncios, tamanho solicitado, categoria de dispositivo, país, tipo de item de linha, grupo de rendimento e tempo. O total bruto mostra o volume de oportunidades perdidas pelo ad server. Para saber onde a perda aconteceu, você precisa abrir esse número pelas dimensões.

Comece pelos relatórios do GAM, usando dimensões de inventário e métricas compatíveis. Reúna bloco de anúncios, tamanhos solicitados, categoria de dispositivo, país, tipo de item de linha, grupo de rendimento e unidade de tempo no mesmo contexto de relatório. A lista de dimensões e métricas está na referência de relatórios do Google Ad Manager, e essa compatibilidade faz diferença: combinar impressões veiculadas de um tipo de relatório com solicitações de anúncios de outro pode distorcer a leitura da taxa de preenchimento.

Leia o relatório como um mapa, não como um placar

A taxa de preenchimento do site inteiro pode esconder justamente o posicionamento que está perdendo impressões. Compare um 970x250 na página inicial com uma âncora fixa no mobile ou um 300x250 abaixo do artigo: a demanda compradora muda, assim como a visibilidade, as regras de atualização e os tempos de execução do layout. Na média geral, os posicionamentos fortes acabam compensando os fracos.

A primeira pergunta é simples: a falha afeta o inventário inteiro ou está concentrada em algum ponto? Se as impressões não preenchidas subirem em boa parte do inventário na mesma hora, confira as conexões de demanda, a implantação das tags, o estado do consentimento e a configuração de veiculação. Se a alta ficar restrita a um bloco, tamanho ou template, investigue mudanças no piso de preço, na segmentação, no mapeamento de tamanhos ou no layout.

Separe a veiculação do GAM das falhas nas fontes de demanda

Uma fonte de demanda pode falhar com o GAM funcionando normalmente. A contribuição do AdX caiu, mas Open Bidding ou Prebid.js continuam retornando lances? Esse incidente é diferente de um slot sem anúncios elegíveis. Abra os dados por tipo de item de linha e canal de demanda. Essa separação ajuda a encaminhar o problema para quem pode resolvê-lo: yield, operações de campanha ou engenharia.

Quando o relatório apontar um slot específico, abra o Google Publisher Console na página em produção. A inspeção mostra o bloco de anúncios, os tamanhos solicitados, os pares de chave-valor, os tempos das solicitações e os detalhes da veiculação. A documentação da ferramenta está na ajuda do Google Publisher Console. Com essa inspeção, a pista do dashboard ganha uma causa concreta: falta de mapeamento de tamanhos, chave-valor incorreto, bloqueio na veiculação ou uma solicitação normal que voltou sem preenchimento.

Como diagnosticar se a causa é o preço mínimo, a segmentação ou a latência

As três falhas mais comuns deixam sinais distintos. Com um piso alto demais, existe demanda elegível, mas ela não supera o preço mínimo. Na incompatibilidade de segmentação, pouca ou nenhuma demanda é elegível. Já na latência, o leilão acontece, só que os lances ou as chamadas de anúncio chegam tarde demais. Baixar o piso ajuda no primeiro caso. Nos outros, a causa continua lá.

A diferença central está na economia do leilão. Quando o problema é o piso, os compradores tiveram a chance de dar lances, mas o preço mínimo para fechar ficou alto demais naquele contexto. Na segmentação ou na latência, a oportunidade foi restringida ou chegou tarde, antes de o preço fazer diferença. Mexer na camada errada pode até aumentar o preenchimento. A receita por solicitação, porém, pode cair.

Segmentação de impressões não preenchidas por bloco de anúncios e fonte de demanda

Confirmou que a perda não afeta o site inteiro? Compare o inventário afetado em cada fluxo de leilão. Se o 300x250 no fim do artigo no mobile apresenta baixo preenchimento apenas quando falta demanda do Prebid.js, comece pelos logs do wrapper e pelos pares de chave-valor. Alterar o piso global do GAM não é o próximo passo nesse diagnóstico.

“As páginas de artigos no mobile estão com baixo preenchimento” ainda é um recorte amplo demais. Ele mistura templates, lazy loading, composição do tráfego e tempos do leilão. Para orientar a investigação, o diagnóstico precisa chegar a algo como: “300x250 no fim do artigo no mobile, tráfego dos EUA, lances do Prebid ausentes após a alteração no lazy loading.” Com essa frase, engenharia, yield e ad ops sabem onde começar a verificar.

Separe o baixo preenchimento persistente dos picos pontuais na fila de trabalho. O primeiro pede testes de pisos, demanda, layout ou elegibilidade. Já um pico após uma mudança de regra no Cloudflare, a publicação de um template, uma atualização da CMP ou a implantação de tags deve ir para a análise de incidentes. Nesses casos, corrigir a regressão técnica pode ser suficiente para recuperar a monetização.

Priorização das correções pelo potencial de receita

Priorize as tarefas pela estimativa de receita em risco, não pelo gráfico que parece pior. Mantenha a mesma base de cálculo: solicitações afetadas, preenchimento normal, preenchimento atual e CPM líquido observado ou receita por mil solicitações naquele segmento. O volume pesa. Uma pequena perda percentual em um bloco sticky com muitas solicitações pode custar mais do que uma queda acentuada em um bloco de nicho.

• Receita em risco: dê uma nota de 1 a 5 com base nas solicitações de anúncios afetadas multiplicadas por um CPM realista para aquele segmento. Use o CPM ou a receita por mil solicitações de anúncios do segmento, não as médias da conta inteira, porque um bloco no topo da página em desktop nos EUA e um bloco no rodapé com baixa visibilidade não são equivalentes.
• Confiança na causa raiz: dê uma nota de 1 a 5 com base na qualidade das evidências. Um relatório do GAM com confirmação no Google Publisher Console e logs do Prebid.js merece uma nota de confiança maior do que uma queda isolada no dashboard.
• Esforço de implementação: dê uma nota de 1 a 5, em que 1 corresponde a um ajuste de configuração de campanha ou de piso e 5 exige engenharia, implantação do wrapper, QA e coordenação da publicação. Uma tarefa de alto esforço ainda pode ter prioridade, mas não deve ser escolhida às cegas.
• Risco de reversão: classifique como baixo, médio ou alto conforme a facilidade de desfazer a mudança. É mais fácil reverter um teste de Regras de precificação unificadas em um único bloco de anúncios do que uma mudança no comportamento do lazy loading no site inteiro.
• Regra de priorização: corrija primeiro os casos com alta receita em risco, alta confiança e esforço baixo ou moderado. Se a receita em risco for alta, mas a confiança for baixa, reúna mais uma evidência de diagnóstico antes de alterar as configurações de monetização.
• Classificação por tipo de correção: ajustar pisos costuma exigir pouco esforço de implementação, mas pode prejudicar o CPM se o ajuste for mal aplicado; revisar a segmentação exige esforço médio e tem alto potencial de ganho quando há falhas de elegibilidade; trabalhar no timeout ou no wrapper exige mais esforço, mas pode recuperar demanda que nunca chegou ao GAM; mudanças no roteamento da demanda ajudam quando um caminho específico até o comprador tem desempenho fraco, não quando o próprio slot está mal configurado.

Veja um caso concreto: um sticky 320x50 no mobile dos EUA costuma preencher 90.000 de 100.000 solicitações diárias, mas passa a preencher 80.000. São 10.000 oportunidades preenchidas a menos, antes de aplicar seu CPM líquido real. Já um 300x600 com queda de 20% no preenchimento pode chamar mais atenção no gráfico. Só deve ganhar prioridade, porém, se a receita em risco for maior.

Leve essa estimativa para um backlog de correções com cinco campos: responsável, causa suspeita, evidências de suporte, receita em risco e janela de reteste. Registre as evidências primeiro. Depois, classifique confiança e esforço. “Alta confiança, baixo esforço” indica uma mudança reversível de configuração apoiada por uma tendência clara no segmento. “Baixa confiança, alto esforço” aponta para trabalho de engenharia cuja hipótese ainda não foi comprovada.

Configuração de alertas para quedas na taxa de preenchimento

Configure alertas para recortes em que alguém consiga agir: bloco de anúncios, tamanho, dispositivo, localização geográfica, fonte de demanda ou um template de valor já conhecido. Em posicionamentos de alto volume, comece com um critério prático: preenchimento 10 pontos percentuais abaixo da mediana do mesmo horário nos últimos sete dias, em duas verificações consecutivas a cada 15 minutos. Exija também um mínimo de solicitações, como 5.000, para evitar ruído. Usa o Looker Studio? Deixe explícitos o conector, os filtros e a atualização dos dados. O Google explica como configurar as fontes de dados na documentação de fontes de dados do Looker Studio.

1. Escolha segmentos para monitorar com volume suficiente para fazer diferença. Comece pelos blocos de anúncios que mais geram receita, pelo inventário de alto valor dos EUA, por posicionamentos sticky ou com refresh e pelos principais caminhos de demanda, como AdX, Open Bidding e Prebid.js.
2. Crie linhas de base móveis por hora e tipo de dia. Compare o comportamento de terça-feira às 14h com o de tardes de terça-feira equivalentes, não com o de domingo à noite ou com o padrão de tráfego de um feriado.
3. Configure alertas tanto para variações na taxa de preenchimento quanto para o volume de impressões não preenchidas. Uma variação percentual em um posicionamento de baixo volume é ruído; uma mudança moderada em um bloco com muitas solicitações pode ser relevante.
4. Separe os alertas de monetização dos alertas técnicos. Use os relatórios do GAM para identificar mudanças na veiculação e cruze esses dados com o monitoramento de páginas e tags em ferramentas como Google Analytics 4, Looker Studio e sua stack de observabilidade. O Looker Studio permite conectar fontes de dados a dashboards, conforme descrito na ajuda sobre fontes de dados do Looker Studio.
5. Inclua dados de desempenho da página para contextualizar os blocos sensíveis à latência. Se as métricas de Core Web Vitals ou o comportamento da CDN mudarem ao mesmo tempo que a perda de lances, investigue a camada técnica antes de alterar os pisos; as orientações do Google sobre Core Web Vitals são a referência adequada para as métricas de experiência do usuário usadas nessa análise.
6. Encaminhe os alertas aos responsáveis com uma primeira verificação obrigatória. Um alerta sobre uma fonte de demanda deve ir para yield ou operações programáticas; um alerta de slot ausente após um deploy deve incluir engenharia; um alerta de segmentação deve chegar à equipe de tráfego de ad ops.
7. Suprima os alertas em períodos de ruído conhecido. Testes de piso, novas versões do wrapper, grandes campanhas de venda direta e eventos sazonais de tráfego devem ser identificados para que o fluxo de alertas não acostume a equipe a ignorar regressões reais.

O alerta precisa deixar claro quem verifica o quê primeiro. “Taxa de preenchimento em queda” não dá à equipe um caminho para investigar. Compare com: “Artigo mobile 300x250, EUA, preenchimento caiu 12 pontos em relação à linha de base do mesmo horário, sem respostas de lance do Prebid desde o deploy das 9h00 ET”. A investigação já tem direção. Ad ops confere o GAM e os pares de chave-valor; yield examina as respostas dos bidders; engenharia revisa o deploy e os erros no console.

O que corrigir primeiro depois de encontrar a perda

Corrija primeiro a camada que bloqueou o leilão. Só então mexa na que define o preço. Se o slot tinha segmentação errada, renderizou tarde ou ficou sem lances de uma fonte de demanda, baixar os pisos pode recuperar preenchimento no curto prazo e deixar a falha intacta. Em problemas de elegibilidade ou de tempo, o preço deve ser o último ajuste.

Se as evidências apontarem para os pisos

Mexa nos pisos apenas no menor segmento com pressão de preço comprovada. Nas Regras de precificação unificadas, faça o recorte por inventário, tamanho, dispositivo ou localização geográfica, conforme sua configuração permitir. Compare a receita por mil solicitações de anúncios antes e depois. Olhar só o preenchimento favorece vendas baratas; a receita por solicitação revela se recuperar aquelas impressões compensou.

Defina a janela de reteste, o valor para reversão e o limite de controle do teste de piso. Aplique a mudança ao bloco e ao tamanho afetados, por exemplo, e compare períodos com o mesmo padrão de dia da semana. Evite alterar o site inteiro enquanto o mix de tráfego muda. O preenchimento subiu, mas a receita por mil solicitações de anúncios caiu? Você melhorou a aparência do resultado. Deixe o piso anterior registrado no chamado: a reversão não pode depender da memória de alguém.

Se as evidências apontarem para a concorrência ou o roteamento

Se o AdX, o Open Bidding ou um parceiro do Prebid.js deixar de contribuir, descubra em qual situação ele está: não respondeu, respondeu tarde ou respondeu sem competitividade ou elegibilidade. A correção muda em cada caso. Perder por preço faz parte do leilão. Já um bidder que excede o timeout ou um deal excluído pela segmentação exige investigação operacional.

Nos deals do DV360, confira a elegibilidade do inventário, da localização geográfica, do dispositivo e do tamanho previstos antes de chamar a equipe de demanda. No wrapper, compare o horário da resposta do lance com o da chamada ao servidor de anúncios. Timeout de 1.200 ms e resposta do parceiro nos logs aos 1.500 ms? O lance não chegou ao GAM a tempo. E, se o GPT disparar antes de o callback do wrapper definir a segmentação, nem um lance alto entra na disputa.

Se as evidências apontarem para problemas técnicos de veiculação

Preenchimento insuficiente causado por falha técnica deve ser tratado como incidente. Revise as versões recém-publicadas e as alterações nas tags de anúncios. Confira também os limiares de lazy loading, o comportamento da CMP quando aplicável, as configurações de CDN ou de borda, os erros de JavaScript e os atrasos na renderização dos espaços publicitários. Reduzir latência exige cuidado com a experiência do usuário. O Google e o web.dev definem as Core Web Vitals com base em carregamento, interatividade e estabilidade visual nas orientações sobre Core Web Vitals, portanto, não tente “corrigir” o preenchimento à custa de mudanças de layout ou de atrasos no conteúdo principal.

Depois de cada correção, reteste o recorte que mostrou a perda. Mantenha o mesmo bloco de anúncios, tamanho, dispositivo, região e fonte de demanda, em uma janela de tempo comparável. A melhora do preenchimento total em outro segmento não resolve o problema original. Use o segmento afetado como controle e acompanhe a receita por mil solicitações de anúncios para confirmar se a recuperação do preenchimento trouxe ganho real.

Uma boa análise de impressões não preenchidas deixa uma fila menor de ações, com alvos claros. Comprove a falha, estime a perda potencial em dólares e escolha a correção que combine menor risco com maior potencial de ganho. Depois, reteste o segmento exato. Isso evita uma semana de reduções de piso quando a perda veio de outro lugar: uma chamada tardia do wrapper, uma regra de segmentação errada no GAM ou uma versão publicada do template que mudou o momento de renderização dos espaços publicitários.

Perguntas frequentes

O que significa impressões não preenchidas no GAM?

FAQ: O que significa “impressões não preenchidas” no Google Ad Manager? O GAM recebeu uma requisição de anúncio, mas não veiculou um anúncio elegível para aquela oportunidade. Onde travou? Na prática, o problema costuma estar no piso de preço, na segmentação, na concorrência entre fontes de demanda ou na latência. A análise precisa identificar qual camada bloqueou a impressão. Avaliar se a taxa de preenchimento é “boa” sem esse contexto ajuda pouco.

Como identificar se os pisos de preço estão causando impressões não preenchidas?

FAQ: Como saber se os pisos de preço estão causando impressões não preenchidas? Veja se o preenchimento caiu em tamanhos, blocos de anúncios, dispositivos ou regiões específicos logo após uma mudança de piso. Depois, faça um teste controlado com um piso mais baixo. Se o preenchimento melhorar e a receita por mil requisições de anúncios se mantiver ou subir, a pressão de preço provavelmente contribuía para o problema. A lacuna continuou? Verifique a elegibilidade, a veiculação e os tempos de execução.

Você deve analisar as impressões não preenchidas primeiro por bloco de anúncios ou por fonte de demanda?

FAQ: Devo começar a análise por bloco de anúncios ou por fonte de demanda? Se o problema estiver concentrado em poucos posicionamentos, comece pelo bloco. Layout, mapeamento de tamanhos, pisos de preço e chaves-valor costumam ser específicos de cada posicionamento. Já uma queda em muitos posicionamentos ao mesmo tempo pede uma análise por fonte de demanda, assim como uma mudança que coincida com o comportamento de um bidder, do AdX, do Open Bidding ou de um deal.

Qual limiar de alerta é útil para quedas na taxa de preenchimento?

FAQ: Qual limiar de alerta devo usar para monitorar a taxa de preenchimento? Use o histórico de cada posicionamento como referência. Um número único para o site inteiro esconde diferenças relevantes. Como ponto de partida, combine uma queda em pontos percentuais em relação à mediana do mesmo horário com um volume mínimo de requisições. Ajuste o alerta conforme o valor do posicionamento: um bloco na página inicial ou um anúncio âncora fixo pede acompanhamento mais rigoroso do que um rodapé de baixo volume.

Reduzir os pisos de preço pode resolver as impressões não preenchidas?

Fontes: Referência de relatórios do Google Ad Manager; Ajuda do Google Publisher Console; Documentação das fontes de dados do Looker Studio; Orientações sobre Core Web Vitals.