A definição é simples; o que confunde é o que está por trás dela. Este guia trata do que o critério de tempo realmente mede, do que dá para configurar, de por que o número de antes e o de agora não são comparáveis, e do erro de implementação que faz a rejeição despencar sem que nada tenha melhorado.
O que conta como rejeição hoje?
Uma sessão é considerada engajada quando cumpre qualquer um destes três critérios: dura mais do que o limite de tempo configurado, tem um evento principal registrado, ou tem duas ou mais visualizações de página ou de tela. Tudo que não cumpre nenhum dos três é rejeição.
Isso muda o sentido da palavra. Rejeição deixou de significar "viu uma página só" e passou a significar "não deu nenhum sinal de engajamento". São coisas diferentes, e a diferença produz situações desconfortáveis: quem lê seu artigo inteiro em nove segundos e sai conta como rejeição; quem abre, não lê nada e deixa a aba em primeiro plano por onze segundos, não.
O guia de GA4 trata das outras métricas que mudaram de sentido na mesma virada.
O que os 10 segundos realmente medem?
Medem tempo com a página em foco, e não tempo com a página aberta. Essa distinção resolve boa parte das dúvidas sobre números que não fecham.
A documentação da métrica de tempo de engajamento define o valor como o tempo que a pessoa passa com a sua página web em foco, ou com a tela do aplicativo em primeiro plano. E o evento correspondente é descrito como disparado quando o aplicativo está em primeiro plano ou a página está em foco por pelo menos um segundo.
Fonte: documentação do Google Analytics sobre o tempo de engajamento e sobre eventos coletados automaticamente, consultada em 15/09/2026.
As consequências práticas são mais úteis do que parecem:
Aba em segundo plano não acumula tempo. Quem abre seu link e deixa para ler depois, com a aba parada atrás de outras, não está acumulando engajamento. Aquele tempo não conta.
O comportamento de leitura em várias abas trabalha contra o seu número. É comum abrir seis resultados de uma busca em abas e ler um a um. As cinco que esperam a vez acumulam pouco tempo em foco, mesmo que sejam lidas depois.
Vídeo assistido em outra aba também não conta. Se a pessoa deixa o seu conteúdo tocando e vai fazer outra coisa, o tempo não entra, a menos que você marque eventos próprios para isso.
Dá para mudar esse critério?
Dá, e a documentação diz isso com todas as letras. Na página de configuração da tag, o Google explica que se ajusta o tempo limite da sessão escolhendo horas e minutos, e que se ajusta o cronômetro das sessões engajadas escolhendo o número de segundos, sendo o padrão 10 segundos.
Fonte: documentação do Google Analytics sobre configurar a tag, consultada em 15/09/2026.
Duas observações que fazem diferença na hora de mexer:
O teto desse cronômetro não está documentado. Circula no mercado a informação de que o intervalo permitido vai de 10 a 60 segundos. Não encontramos isso em nenhuma página oficial: as páginas que tratam do assunto declaram apenas o padrão. Onde existe máximo declarado é no outro campo, o de expiração da sessão, cujo limite oficial de 7 horas e 55 minutos está declarado na página de ajuda sobre sessões.
Mudar o cronômetro muda a série histórica. Subir o limite de 10 para 30 segundos faz a taxa de rejeição aumentar sem que o comportamento de ninguém tenha mudado. Se for mexer, anote a data no mesmo lugar em que guarda os relatórios, ou a próxima pessoa vai investigar uma queda que não existiu.
Taxa de rejeição é fator de ranqueamento?
Não há documentação dizendo que é, e há documentação que costuma ser citada errado nos dois sentidos.
O que o material oficial sobre como a busca funciona diz é que o Google usa dados de interação agregados e anônimos para avaliar se os resultados de busca são relevantes para as consultas, transformando esses dados em sinais que ajudam os sistemas a estimar relevância.
Fonte: material oficial do Google sobre como os resultados são classificados, consultado em 15/09/2026.
Repare no que essa frase diz e no que ela não diz. Ela fala de interação com os resultados de busca, e não da métrica que a sua ferramenta calcula dentro do seu site. São medições em lugares diferentes: uma acontece dentro do Google, a outra depende de uma tag que você instalou.
A negativa famosa, atribuída a John Mueller e registrada por um veículo especializado em junho de 2020, diz que a taxa de rejeição do Analytics não é usada. Ela existe apenas nesse relato, e não em documentação. Não a citamos como fato pela mesma razão pela qual não citamos a afirmação contrária: nenhuma das duas está escrita em documento oficial.
O que dá para afirmar com segurança: a sua taxa de rejeição é um indicador do seu site, não uma nota que o Google atribui a ele.
E quando a pessoa achou o que queria e saiu?
Esse caso tem nome na literatura, e a ressalva sobre ele sumiu da documentação.
A página antiga de ajuda sobre a métrica, da versão anterior do Analytics, dizia com todas as letras que, se o sucesso do site depende de a pessoa ver mais de uma página, então sim, uma rejeição alta é ruim; mas que, num site de página única como um blog, ou em conteúdos para os quais sessões de página única são esperadas, uma taxa de rejeição alta é perfeitamente normal.
A página atual, que define engajamento e rejeição, não traz nenhuma ressalva desse tipo. Ela define e encerra.
Fonte: página legada de ajuda sobre taxa de rejeição e página atual sobre taxa de engajamento e de rejeição, ambas do Google Analytics, consultadas em 15/09/2026.
O fenômeno tem formulação acadêmica, e ela vem de dentro do próprio Google: em 2009, três pesquisadores da empresa publicaram no SIGIR um trabalho sobre abandono bom, o caso em que a pessoa encerra a busca sem clicar porque já obteve o que precisava.
Fonte: Li, Huffman e Tokuda, "Good Abandonment in Mobile and PC Internet Search", SIGIR 2009, autores identificados como do Google. Referência histórica, de 2009, sobre comportamento na busca, não sobre a métrica do Analytics.
A leitura prática: em página de resposta objetiva, como horário de funcionamento, telefone, conversor ou definição curta, rejeição alta pode ser sinal de sucesso. O erro é aplicar a mesma meta para esse tipo de página e para uma página de produto.
Por que o número do Analytics antigo não serve de comparação?
Porque a métrica mudou de definição, e ninguém publicou um fator de conversão entre as duas.
Circula bastante que a rejeição "caiu de 30% a 50%" com a mudança, sem fonte que sustente a faixa. Em consulta feita em 15/09/2026, não encontramos fonte defensável para nenhum desses números: são estimativas publicadas em blogs, e mesmo os textos mais cuidadosos falam em expectativa, não em medição. O Google não mediu essa diferença publicamente nem avisa, na página da métrica, que os dois valores não são comparáveis.
O que fazer com o histórico antigo: guarde como registro de outro indicador, com o nome dele, e comece a série nova a partir da migração. Comparar os dois num mesmo gráfico produz uma tendência que não existiu.
E se você precisa mesmo de um número de comparação, o caminho honesto é medir em casa: escolha um conjunto de páginas, anote a rejeição atual e acompanhe daí para frente. É a mesma lógica de escolher poucos indicadores e defini-los por escrito que o guia de métricas de marketing detalha.
Sobre referências por setor: os números que circulam vêm de fornecedores de ferramentas de análise, calculados sobre a carteira de clientes deles, e não sobre a web. Servem para ver direção de variação, não para comparar o seu número com o deles. Um cuidado extra: edições de anos diferentes do mesmo relatório costumam ter janelas e amostras distintas, então elas não formam série temporal, ainda que sejam apresentadas lado a lado.
O que quebra a métrica em site de página única e em aplicativo?
Aqui está o erro que mais produz relatório enganoso, e ele tem duas versões opostas.
Em sites de página única, a navegação não recarrega o documento, então as visualizações precisam ser registradas por configuração. A documentação para desenvolvedores trata disso e traz um aviso específico: quem configura as tags pelo gerenciador não deve ativar o rastreamento automático de histórico no Analytics, porque isso pode levar à contagem dupla de visualizações.
Fonte: documentação do Google Analytics para desenvolvedores sobre medir aplicações de página única, com atualização declarada em 10/09/2026, consultada em 15/09/2026.
Os dois erros e o que cada um faz com o seu número:
Erro de implementação | Efeito na taxa de rejeição |
|---|---|
Navegação virtual não configurada: a sessão inteira vira uma visualização só | Infla, porque quase nenhuma sessão alcança duas visualizações |
Dois mecanismos ativos ao mesmo tempo: cada navegação conta duas vezes | Despenca, porque quase toda sessão passa do critério de duas visualizações |
O segundo é mais perigoso justamente por ser uma boa notícia: ninguém abre chamado porque a rejeição melhorou.
Em aplicativos, a contagem de telas é automática para estruturas padrão, e precisa ser feita à mão quando o aplicativo não usa uma tela separada por contexto, como acontece em jogos. Sem isso, o mesmo efeito de inflar aparece.
Como desconfiar: compare a média de visualizações por sessão antes e depois de qualquer mudança de implementação. Se ela dobrou de um dia para o outro, a rejeição que caiu junto não significa nada. Ferramentas de gravação de sessão, como as tratadas no guia do Microsoft Clarity, ajudam a confirmar olhando o que a pessoa fez de fato.
Conclusão
Taxa de rejeição hoje é o complemento da taxa de engajamento, e o critério de tempo que a define mede página em foco, e não página aberta. O limite padrão é de dez segundos e pode ser ajustado, ainda que o teto não esteja documentado; o histórico da versão anterior do Analytics não é comparável; e o mesmo número pode significar sucesso ou fracasso dependendo do que a página se propõe a fazer.
O próximo passo custa menos do que qualquer otimização: separe suas páginas em dois grupos, as que precisam de continuidade e as que entregam a resposta ali mesmo, e olhe a rejeição de cada grupo em separado. A conversa sobre "a rejeição está alta" costuma terminar aí, porque quase sempre se estava somando dois números que nunca deveriam estar juntos.
