Fadiga de notificações: como medir e como reduzir

Fadiga de notificações é um inscrito que parou de ler as suas notificações e ainda não avisou você.

Esse é o problema inteiro numa frase. Ninguém escreve para reclamar. A permissão continua concedida por um tempo. O número de envios parece o mesmo do mês passado. O que muda é mais silencioso: os mesmos tipos de matéria recebem menos interações, novos visitantes recusam o pedido com mais frequência, endpoints começam a falhar e a base encolhe na maioria das semanas, mesmo sem nada ter mudado no fluxo de trabalho.

Se você quer a resposta curta para "como reduzir a fadiga de notificações push": limite a exposição por pessoa em vez de por campanha, e aplique o limite antes do envio em vez de ler sobre ele depois. O resto desta página explica como saber se você tem um problema de fadiga e o que de fato mudar.

Como a fadiga aparece na operação

Fadiga não é um número só. Ela aparece como quatro curvas diferentes, e elas se movem em velocidades diferentes.

A curva de opt-out. Descadastros concentrados nas horas seguintes a um envio. É o sinal mais rápido e o que todo mundo já tem. Ele subestima bastante, porque a maioria dos inscritos cansados nunca clica em cancelar a inscrição.

A curva de recusa de permissão. A parcela de visitantes que recusa o seu pedido. Ela sobe quando a sua marca ensinou ao público em geral que as suas notificações não valem a pena, e é a única curva que prejudica a aquisição em vez da retenção. O capítulo de PWA do Web Almanac 2025, feito a partir de um rastreamento do HTTP Archive em julho de 2025, relata que usuários de desktop ignoram pedidos de notificação 78% das vezes, com 16% de aceitação no mobile. Isso é comportamento de pedidos num rastreamento, não o seu site, mas define a linha de base contra a qual você está trabalhando.

A curva de sequência ignorada. Pessoas que continuam inscritas, continuam recebendo e não interagiram com as últimas cinco, dez, vinte mensagens. Essa é a verdadeira população em fadiga, e quase nenhum dashboard de push a mostra. O Chrome afirma que menos de 1% de todas as notificações recebe alguma interação dos usuários, o que dá uma ideia do tamanho desse grupo na web como um todo.

A curva de remoção silenciosa. Inscrições que desaparecem sem um clique de cancelamento. Algumas são dispositivos mortos e dados do navegador apagados. Outras são o navegador decidindo pelo leitor.

Essa última é a mudança que transformou a fadiga de uma questão de cortesia numa questão de entrega.

O navegador agora faz parte da sua política de fadiga

Três coisas aconteceram, e já estão em vigor. Nada disto é previsão.

Em outubro de 2025 o Chrome lançou a remoção automática da permissão de notificações para sites com que o usuário não interagiu recentemente, quando o engajamento é muito baixo e o volume de notificações é alto. O Chrome informa o usuário. O usuário pode conceder a permissão de novo no Safety Check ou no próprio site, ou desligar a revogação automática. Aplicativos web instalados não são revogados por esse recurso. Vale para desktop e Android.

Em janeiro de 2026 o Chrome começou a implantar limites de taxa na Push API para sites que enviam muitas notificações com pouco engajamento no site. Um site considerado disruptivo fica limitado a não menos que 1.000 mensagens por minuto, e as requisições excedentes recebem HTTP 429. Os fatores diários que o Chrome cita são mensagens push por tempo no site, pedidos de permissão por tempo no site e engajamento, medido como site engagement score e minutos em primeiro plano. A escalada é de um dia, depois sete dias, depois catorze; o estado é zerado depois de 42 dias consecutivos sem comportamento disruptivo. Isso vale só para a Push API, não para a Notifications API. O Chrome afirma que quase todos os sites não serão afetados.

Em agosto de 2026 a Chrome Security descreveu o conjunto todo como uma defesa em várias camadas: revogação automática por baixo engajamento e para sites com avisos repetidos de notificações suspeitas, detecção comportamental de redes coordenadas de abuso, limites de taxa do lado do servidor no FCM e um modelo de permissão simplificado, incluindo cancelamento com um toque no Android. Os usuários revisam as permissões revogadas no Safety Hub.

Leia de novo a lista de fatores do limite de taxa, porque é a frase mais útil que qualquer fabricante de navegador já publicou sobre o assunto. Os fatores são proporções. Não mensagens por dia, e sim mensagens por unidade de atenção que você de fato conquistou. Um site que publica o tempo todo e segura os leitores na página aguenta um volume que marcaria um site com a mesma quantidade de envios e nenhum engajamento.

O que você não consegue fazer é descobrir o limite por engenharia reversa. O Chrome não publica a sua pontuação interna, e quem diz que a reproduz está chutando. Trate o navegador como uma fronteira externa rígida e defina a sua própria política bem dentro dela.

Como medir a fadiga na sua própria lista

Isto é um procedimento, não um benchmark. Usa dados que você já tem em qualquer fornecedor de push mais o seu analytics, e a primeira versão pode estar rodando em uma semana.

1. Defina o denominador

Defina um inscrito ativo de forma explícita: um endpoint válido que recebeu pelo menos uma mensagem nos últimos 30 dias e não retornou falha permanente. Escreva a definição. A maioria das discussões sobre tamanho de lista é, na verdade, uma discussão sobre dois denominadores diferentes.

2. Monte um registro por envio

Para cada envio, registre: audiência elegível, entregues, interações, opt-outs em 24 horas e endpoints removidos como inválidos em 24 horas. Cinco números por linha. O seu fornecedor tem quatro deles; o quinto costuma exigir o log de erros de entrega.

3. Monte um contador de exposição por inscrito

Para cada inscrito, guarde as mensagens recebidas nos últimos 7 dias e as mensagens consecutivas sem interação. Esses dois inteiros são todo o modelo de fadiga que importa, e são o que a maioria das plataformas não guarda.

4. Agrupe por sequência ignorada

Os limites desses grupos são um ponto de partida para um teste, não um benchmark medido. O que importa é dividir a lista, porque uma média da lista inteira esconde completamente o formato.

5. Acompanhe o movimento líquido da lista toda semana

Novas permissões concedidas, menos descadastros, menos endpoints inválidos removidos. Faça o gráfico semanal contra o volume de envios. Se a linha fica negativa nas semanas de volume alto e positiva nas de volume baixo, você tem a resposta, e numa forma que um editor aceita.

Uma ressalva honesta: nenhum navegador diz qual remoção foi uma revogação automática. Você vê o endpoint retornar uma falha permanente, e o motivo é inferido, não informado. Não apresente causas inferidas como se fossem medidas.

O que realmente reduz a fadiga

Tetos de frequência por inscrito. Um teto de oito envios por dia para o site não diz nada sobre a pessoa que recebeu os oito. Limite o que uma pessoa recebe num dia e numa semana. Essa mudança sozinha costuma fazer mais do que todo o resto desta lista.

Deduplicação de tema e de matéria. A mesma matéria chegando duas vezes ao mesmo leitor com dois títulos diferentes é a forma de fadiga mais evitável que existe. Deduplique pelo conteúdo, não pela linha da campanha, e acrescente um cooldown por tema para que uma história em andamento não consuma a semana inteira de um leitor.

Janelas de silêncio. Envios de rotina respeitam uma janela local de envio com fuso horário real. Entregar de madrugada compra um pouco de alcance e muito ressentimento, e é o jeito mais rápido de ensinar alguém a desligar o canal inteiro.

Descanso para sequências ignoradas. Pare de enviar para quem ignorou as últimas mensagens, e mantenha essas pessoas inscritas enquanto isso. Um descanso é uma decisão. Não é uma campanha que falhou, e protege a permissão que você já pagou para conquistar.

Um piso de valor. Alguns envios não deveriam acontecer em frequência nenhuma. Se o conteúdo é fraco, o número certo de destinatários é zero, e um teto com folga não é motivo para preenchê-lo.

Um override explícito. Breaking news precisa passar por cima da política. Faça disso uma decisão nomeada e registrada, e não uma exceção geral, senão toda matéria vira breaking news em um mês.

A fadiga vem antes do envio, não num relatório

A maior parte das ferramentas de push coloca a fadiga na aba de analytics. Você envia e depois descobre quanto custou. Aí a permissão já foi, e o custo de aquisição para repô-la é real.

A versão que funciona trata a fadiga como uma política que o envio precisa cumprir. Tetos por inscrito, intervalo mínimo, horários de silêncio, regras de dormência e um piso de valor são avaliados na hora do envio, os destinatários inelegíveis saem antes da entrega e o motivo fica registrado para que alguém possa discutir com ele depois. Essa última parte importa mais do que parece. Numa redação, a contenção perde toda discussão em que não consegue mostrar números.

Se você quer escrever isso numa forma portátil, a Open Attention Policy é um formato JSON aberto exatamente para esses campos, com um validador sob licença MIT. Você pode usá-la com qualquer fornecedor, inclusive um que não seja o nosso.

Limitações e ressalvas dos navegadores

• As plataformas da Apple se comportam de outro jeito. O Declarative Web Push chegou no Safari 18.4, em 31 de março de 2025, para web apps na Tela de Início no iOS e no iPadOS, usando um payload JSON padronizado e sem service worker instalado. Os sinais de interação desses inscritos não são idênticos aos do Chrome, então não os junte num único modelo de fadiga sem verificar.
• Os limites de taxa do Chrome valem para a Push API, não para a Notifications API. Notificações disparadas localmente são outra superfície.
• Não existe uma API entre navegadores que diga por que uma inscrição terminou. As remoções silenciosas são inferidas.
• Todo número de navegador nesta página vem do Chrome, do WebKit ou do HTTP Archive, com data acima. O EngageNudge não publicou um benchmark de fadiga próprio, e não vamos inventar um para fazer uma página parecer autorizada.

Como o EngageNudge lida com isso

O EngageNudge avalia a política de fadiga antes de um Nudge sair, não depois. Limites de exposição diários e semanais, tempo mínimo entre Nudges, sinais de sequência ignorada, proteção de leitores dormentes, cooldowns por tema, horários de silêncio e um override explícito de breaking news são todos entradas de uma única decisão de enviar ou pular, e um pulo fica registrado como decisão, não como erro.

A nota de reputação já está no seu dashboard hoje: um número com uma faixa, os fatores por trás dele e um e-mail para o dono do workspace quando um site entra na zona de risco. As perdas são separadas por causa: cancelamento, revogação pelo navegador, falha de entrega, para que uma queda possa ser lida em vez de adivinhada. A nota é só sua. Não é publicada em lugar nenhum nem compartilhada com outros sites.