Ad refresh é a técnica de recarregar um novo anúncio no mesmo espaço, dentro da mesma sessão, sem o usuário trocar de página. Bem configurado, aumenta receita total em 20-50% no mesmo tráfego. Mal configurado, viola políticas do Google e destrói o eCPM. Três regras inegociáveis: (1) AdSense puro proíbe refresh, então só funciona dentro do GAM com declaração formal; (2) o anúncio só pode atualizar quando está efetivamente visível na tela do usuário, com aba ativa; (3) intervalo mínimo de 30 segundos. Este guia cobre os dois tipos de gatilho, a interação com header bidding, o impacto em Core Web Vitals e quando refresh simplesmente não compensa.
Refresh é uma das alavancas técnicas mais sedutoras pra publishers que rodam Google Ad Manager. A matemática parece imbatível: mesmo tráfego, mais impressões, mais receita. Em uma planilha simplificada, ativar refresh dobra inventário.
Na realidade, raramente funciona assim. A interação entre refresh e o resto do stack (header bidding, floor prices, viewability, políticas de SSPs) é cheia de armadilhas. Publishers que ligam refresh sem método costumam ver crescimento marginal de receita acompanhado de queda em métricas premium — viewability afunda, anunciantes top fogem, e em alguns meses o stack inteiro performa pior do que antes.
Pronto para Decolar?
Junte-se a milhares de publishers que já estão maximizando sua receita com a tecnologia espacial da WinUp.
Esse guia mostra como configurar refresh de forma defensável: o que aumenta receita de verdade, o que o Google permite e o que ele bane na surdina, e quando refresh simplesmente não é a alavanca certa pro seu inventário.
O que é ad refresh (rápido)
Ad refresh é o recarregamento de um anúncio dentro do mesmo espaço, na mesma página, sem que o usuário navegue. Após um gatilho — tempo passado, interação do usuário, evento da página — o JavaScript dispara nova requisição ao ad server, recebe um novo criativo, e renderiza no mesmo container DOM.
Exemplo concreto: usuário entra num artigo longo. O sidebar mostra anúncio do Anunciante A. Depois de 45 segundos com o anúncio visível na tela, o slot atualiza pra um anúncio do Anunciante B. Você gerou duas impressões a partir do mesmo pageview, no mesmo espaço.
A distinção crítica: refresh acontece dentro de uma sessão de página, não na navegação entre páginas. Se o usuário recarrega a página manualmente ou clica num link interno, isso não é refresh — é uma nova sessão, com novo leilão completo.
Os dois tipos de refresh
Refresh por tempo
O mais comum e mais simples de implementar. Um timer começa quando o anúncio é renderizado (ou quando se torna visível, dependendo da configuração) e dispara nova requisição quando o intervalo expira. Intervalos típicos: 30 a 60 segundos.
Funciona melhor em formatos onde o usuário passa tempo: artigos longos, fóruns, conteúdo em vídeo, ferramentas interativas. É também o mais escrutinado pelas redes de demanda — refresh por tempo sem condicionais de engajamento gera impressões “fantasma” (usuário foi pro café, aba aberta no fundo, anúncio recarregando sozinho).
Refresh por evento
O anúncio atualiza quando o usuário faz alguma ação concreta: navega entre abas internas, avança um slide de galeria, joga uma rodada de jogo, troca de aba em ferramenta de comparação, ultrapassa marco específico de scroll. Cada refresh está atrelado a uma interação real.
Esse modelo é muito mais defensável do ponto de vista de qualidade de inventário. Cada impressão recarregada corresponde a um momento de atenção do usuário, não a um timer que rodou no escuro. SSPs e DSPs tendem a precificar refresh por evento melhor que refresh por tempo puro.
Na prática, a maioria das implementações maduras combina os dois: refresh por tempo com condicionais de engajamento embutidas (anúncio visível + aba ativa + sem fullscreen). Quando essas condições falham, o timer pausa. É o melhor dos dois mundos.
O que o Google permite (e o que ele bane)
Esse é o ponto onde publishers se metem em encrenca por desconhecer regra básica. As políticas variam por produto do Google.
Google AdSense: refresh é proibido
Texto oficial das políticas do AdSense: anúncios não podem ser recarregados programaticamente pelo publisher. A única forma “permitida” de servir novo anúncio é o usuário navegar pra outra página ou recarregar manualmente.
Isso significa que publishers que rodam só AdSense puro não podem fazer ad refresh. Ponto. Tentativas de burlar essa regra (refresh disfarçado, scripts de “recarregamento de conteúdo” que disparam novos anúncios) são detectadas pelo Google e resultam em suspensão de conta. Não vale o risco.
Google Ad Manager e AdX: refresh permitido com declaração
GAM e AdX permitem refresh, mas exigem que o publisher declare o inventário recarregado dentro do próprio sistema. A configuração é em Inventário → Ad units → Inventory Rules, onde você marca quais ad units atualizam, qual o gatilho (tempo, evento, ambos) e qual o intervalo mínimo.
Recomendação oficial do Google: 30 segundos mínimo entre refreshes. Pra mobile apps, faixa permitida vai até 120 segundos. Configurações abaixo de 30 segundos são consideradas violação.
Não declarar inventário com refresh é violação de política. Consequências variam: redução silenciosa de demanda premium (DSPs param de licitar nas suas impressões), exclusão de PMPs (deals privados), até suspensão de AdX em casos persistentes.
Outras redes (SSPs externas)
Cada SSP tem política própria. Magnite, Index Exchange, PubMatic, Amazon Publisher Services — todas aceitam refresh, mas com transparência. Tipicamente você sinaliza no bid request que aquela impressão é refresh (via pos e refresh flags no OpenRTB) e o comprador decide se quer competir ou não.
A regra prática vale pra qualquer parceiro: transparência sempre. Tentar enganar o mercado dizendo que impressão refresh é primeira impressão funciona por algumas semanas e quebra a confiança comercial por anos.
A economia do refresh: por que receita extra raramente é proporcional
O instinto diz: dobrei impressões, vou dobrar receita. Não é como funciona. Refresh tem três fatores que comprimem o ganho:
Primeira impressão vale mais. Anunciantes top valorizam a impressão inicial — é onde a atenção do usuário está mais alta. Lances pra primeira impressão são consistentemente maiores que pra segunda, terceira, quarta.
Frequency capping. Muitos anunciantes limitam quantas vezes um mesmo usuário vê o mesmo anúncio. Após a primeira impressão pra aquele usuário, parte da demanda fica indisponível pras impressões seguintes.
Desconto explícito por parte de SSPs. Alguns SSPs aplicam desconto algorítmico em lances de impressões refresh. Você está leiloando um inventário que o comprador sabe ser “segundo lance no mesmo espaço”.
O efeito cumulativo é claro:
| Ciclo | eCPM relativo | Observação |
|---|---|---|
| 1ª impressão (inicial) | 100% | Baseline |
| 2ª (1º refresh) | 60-75% | Primeira queda significativa |
| 3ª (2º refresh) | 40-55% | Frequency capping ativo |
| 4ª (3º refresh) | 25-40% | Maioria dos premium fora |
| 5ª+ | Frequentemente <25% | Risco de gerar mais latência que receita |
Esses números variam por nicho, GEO e qualidade de inventário, mas o padrão é universal: decaimento exponencial, não linear. Por isso a maioria das implementações maduras limita o número total de refreshes por sessão — tipicamente entre 2 e 4 ciclos por slot, dependendo do tipo de conteúdo.
Ganho típico de receita total com refresh bem configurado: 20-50% sobre baseline. Implementações mal feitas frequentemente entregam menos de 10%, ou até negativam quando o eCPM colapsa em segmentos premium.
Refresh e header bidding: a complexidade que ninguém menciona
Pra publishers que rodam Prebid.js (ou alguma forma de header bidding), refresh adiciona camada técnica que afeta diretamente a performance do leilão.
Cada refresh é um novo leilão completo
Quando o slot atualiza, todo o ciclo de header bidding roda de novo: requisição pra cada bidder configurado, espera de respostas dentro do timeout (geralmente 1-2 segundos), envio dos lances pro GAM como key-values, decisão final do ad server.
Isso tem três consequências práticas:
- Latência multiplica. Se seu timeout de Prebid é 1.500ms, cada refresh adiciona pelo menos isso de processamento. Em mobile com conexão fraca, o impacto na bateria e performance percebida é real.
- Bid density tende a cair em refresh. Nem todo bidder responde sempre. No 2º e 3º refresh, alguns bidders deixam de licitar — seja por timeout, por filtros internos de qualidade de inventário, ou por frequency cap. Resultado: leilões com menos competição, lances menores.
- Server-side bidding ajuda muito aqui. Prebid Server (vs Prebid client-side) tem latência substancialmente menor por requisição, o que melhora o desempenho de refreshes frequentes. Pra publishers que dependem muito de refresh, migração pra server-side bidding costuma ser ROI claro.
Correlator e rastreamento de sessão
O GAM usa um valor de correlator pra agrupar requisições da mesma pageview. Quando você faz refresh, precisa atualizar o correlator pra que o GAM trate o refresh como novo conjunto de requisições, não como continuação da pageview anterior.
Prebid.js gerencia isso automaticamente quando você usa os métodos nativos de refresh (pbjs.requestBids com configuração apropriada). Implementações customizadas (alguém escreveu o refresh do zero) frequentemente esquecem desse detalhe, e geram contagem errada de impressões — que aparece como discrepância entre relatórios do GAM e dos SSPs lá no fim do mês.
Refresh e Core Web Vitals: o problema do CLS
Refresh interage com Cumulative Layout Shift (CLS), uma das métricas centrais dos Core Web Vitals e fator de ranking no Google. CLS mede movimento visual inesperado na página depois do carregamento inicial.
O problema: se o anúncio recarregado tem dimensões diferentes do anterior, o container redimensiona, e tudo abaixo dele “pula” na tela. Isso é CLS catastrófico.
Como prevenir:
- Fixe altura e largura do container do anúncio explicitamente no CSS. Não deixe o slot adaptar-se ao criativo — força o criativo a se adaptar ao slot.
- Configure tamanhos aceitos consistentes. Se o slot original aceita 300×250 e 300×600, defina altura mínima na largura maior. Melhor ainda: limite a um único tamanho.
- Refresh apenas em slots visíveis. CLS é medido sobre mudanças visíveis ao usuário. Se o slot está fora do viewport quando recarrega, a mudança nem entra na conta.
Lazy loading combinado com refresh funciona bem: o anúncio inicial carrega quando o usuário scrolla próximo do slot, e o timer de refresh só começa depois que o anúncio está renderizado e visível. Isso protege Core Web Vitals e maximiza viewability ao mesmo tempo.
As 7 regras práticas que separam refresh que funciona de refresh que destrói receita
1. Viewability é pré-requisito, não opcional
Nunca atualize anúncio fora do viewport. Use Intersection Observer pra detectar visibilidade real. O timer só roda quando o anúncio cumpre o threshold MRC (50% de pixels visíveis por pelo menos 1 segundo contínuo). Anúncio saiu da tela? Timer pausa.
2. Aba ativa é pré-requisito
Use Page Visibility API pra detectar se o usuário trocou de aba ou minimizou o navegador. Refresh em aba inativa gera impressão zerada de valor — pra o anunciante é fraude, pra você é métrica que destrói reputação do inventário.
3. Intervalo mínimo de 30 segundos (idealmente 45-60)
30 segundos é o piso do Google. Mas em muitos casos, 45-60 segundos performa melhor — anúncio fica tempo suficiente pra gerar engajamento real, eCPM se mantém mais alto, taxa de viewability acima dos thresholds premium.
4. Limite o número de ciclos
Refresh infinito é receita pra desastre. Configure máximo de 2-4 refreshes por slot por sessão, dependendo do tipo de conteúdo. Sessão muito longa sem limite costuma fazer eCPM despencar nos ciclos finais.
5. Exclua campanhas garantidas
Deals de Programmatic Guaranteed e Preferred Deals frequentemente têm cláusulas de entrega específicas que não consideram refresh. Configure no GAM pra que esses deals só rodem na primeira impressão do slot — refresh fica reservado pro Open Auction.
6. Declare tudo no GAM
Inventory Rules → marque cada ad unit que faz refresh, com gatilho e intervalo. Sem isso, você está em violação de política do Google. E não é cosmético: relatórios do GAM passam a separar impressões refresh de iniciais, o que ajuda na análise.
7. A/B test antes de escalar
Não ligue refresh no site todo de uma vez. Rode em 30% do tráfego usando custom criteria como divisor (igual ao que recomendei no artigo de regras de preço). Compare por 7-10 dias:
- Receita total por sessão (a métrica que importa)
- eCPM por ciclo de refresh (pra ver até onde compensa)
- Viewability média (alerta se cair abaixo de 70%)
- Bid density (se SSPs estão competindo menos, é sinal de problema)
Só escala pra 100% se receita total subiu E viewability se manteve. Se receita subiu mas viewability caiu, você está trocando dinheiro de curto prazo por reputação de inventário de longo prazo — péssimo negócio.
Quando ad refresh NÃO vale a pena
Algumas situações em que ativar refresh é trabalho com retorno questionável ou negativo:
Conteúdo muito curto. Páginas onde o usuário fica menos de 30-40 segundos não têm tempo pra um refresh significativo acontecer. Receita esperada cobre o esforço técnico? Geralmente não.
Audiência majoritariamente mobile com conexão fraca. Refresh adiciona requisições JavaScript. Em 3G/4G ruim, o impacto em performance percebida (LCP, INP) costuma derrubar Core Web Vitals e prejudicar SEO. O ganho de receita não compensa a perda de tráfego.
Inventário já no teto de eCPM. Se você tem nicho premium com viewability altíssima e demanda concorrendo de forma agressiva, refresh frequentemente prejudica a média — porque adiciona ciclos de baixo eCPM ao mix.
Stack tecnicamente frágil. Sites com header bidding mal configurado, scripts conflitantes, ou sem condicionais de viewability funcionais não devem ativar refresh. A taxa de problemas técnicos sobe, e o ganho marginal é absorvido por instabilidade.
Sem ferramentas de medição decentes. Se você não tem como medir viewability por ciclo, bid density por refresh, ou receita por sessão segmentada, você está voando cego. Refresh sem medição vira otimização baseada em fé — e fé não paga conta.
Para fechar
Ad refresh é uma das alavancas técnicas mais subutilizadas e ao mesmo tempo mais mal implementadas em monetização programática. Publishers que ignoram o recurso deixam 20-50% de receita extra na mesa; publishers que ativam sem método acabam piorando o stack.
A diferença está em entender que refresh não é botão de “ligar mais receita”. É um sistema condicionado: só roda quando o usuário está vendo, só compensa quando o eCPM por ciclo continua razoável, só é defensável quando declarado e transparente. Quem trata refresh como interruptor binário perde dinheiro nas duas direções — perde ao ignorar, perde ao ativar errado.
Quem trata como sistema vivo, com viewability como condição, número de ciclos como limite, A/B test como método e declaração formal como obrigação ganha o que o refresh pode entregar de verdade: mais receita do mesmo tráfego, sem queimar inventário nem reputação. A pergunta não é “ativar ou não” — é “estou preparado pra implementar com método”. A resposta sincera define o resto.
