Frequência de notificações push: quantas vezes um site de notícias deve enviar?
Não existe um número certo, e qualquer fonte que dê um sem dizer qual é a amostra está vendendo alguma coisa. O que existe é um teto que o navegador impõe, um orçamento que os seus leitores definem e um piso dado pelo valor de cada envio. É assim que você encontra o seu próprio número.
A resposta honesta é que depende, e a parte útil é do que depende.
Não existe um número publicável para quantas vezes um site de notícias deve enviar notificações push. Quem cita "duas a cinco por dia para editores" está repetindo um blog de fornecedor sem amostra nomeada ou fazendo a média de sites que não têm nada em comum com o seu. O que existe, e com o que você pode agir hoje, é um teto que o navegador impõe, um orçamento que está nas mãos dos seus leitores e um piso definido pelo que um envio individual realmente vale.
Duas frequências que se confundem
Quase toda discussão improdutiva sobre frequência de push vem de misturar estas duas.
| Frequência do site | Frequência por inscrito | |
|---|---|---|
| O que conta | Envios que saem da sua conta por dia | Notificações que uma pessoa recebe por dia |
| Quem se importa | A redação, a mesa, o calendário de campanhas | O leitor, o navegador, a saúde da sua lista |
| Definida por | O ritmo de publicação | Segmentação, tetos e elegibilidade |
| Efeito na fadiga | Indireto | Direto |
Uma redação que envia 20 vezes por dia, em que um leitor típico recebe duas, é um produto completamente diferente de uma que envia quatro e todo leitor recebe as quatro. A segunda é mais agressiva, e a contagem de envios no dashboard diz o contrário.
Então a pergunta "com que frequência devemos enviar" são na verdade duas perguntas, e só a segunda tem uma resposta de fadiga. Defina primeiro o número por inscrito. A frequência do site passa a ser um problema editorial e de segmentação, e não de confiança da audiência.
O teto que o Chrome realmente impõe
Esta parte não é opinião, e não é previsão. Está em vigor desde 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, e o estado é zerado depois de 42 dias consecutivos sem comportamento disruptivo. 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.
Separadamente, desde outubro de 2025 o Chrome remove automaticamente a permissão de notificações de 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, que 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 afetados. Desktop e Android.
Disso saem duas coisas, e as duas mudam como você deve pensar no número.
Primeiro, a medida aplicada é uma proporção, não uma contagem. Mensagens push por tempo no site. Pedidos de permissão por tempo no site. Um site cujos leitores ficam e voltam tem mais espaço do que um site com a mesma contagem de envios e nenhum engajamento, o que significa que "quantas por dia" é a unidade errada e "quantas por unidade de atenção que conquistamos" é a certa.
Segundo, a aplicação é por site, mas a revogação automática é por pessoa. Uma frequência que está boa no agregado pode estar tirando permissões, em silêncio, do terço menos engajado da sua lista.
Você não consegue calcular onde está em relação ao limite do Chrome. A pontuação interna não é publicada, e modelá-la é adivinhação. Defina o seu próprio teto bem abaixo do deles e pare de procurar a borda.
Por que esta página não tem uma tabela de benchmark por categoria
Eu poderia colocar aqui uma tabela com uma linha por vertical e um número plausível em cada. Ela ia ranquear. Também seria inventada.
Só publicamos fatos de navegador e de mercado a partir de um registro de afirmações datado, com fonte primária, e não existe fonte aprovada para "sites de notícias enviam X notificações por dia". Os blogs de fornecedores que publicam taxas de opt-in e frequências de envio por país não dizem qual é o denominador, não descrevem a amostra e, na maioria, medem a própria base de clientes. Retratos de detecção de tecnologia mostram quais sites rodam uma plataforma de push, não com que frequência esses sites enviam.
Então esta página dá um método em vez de um número, e o resultado que ele produz é seu. Qualquer número que publicamos vem com o método e a fonte ao lado, tirados do registro de afirmações.
Um método para encontrar o seu número
1. Comece pelo teto por inscrito
Escolha um máximo que uma única pessoa pode receber num dia e numa semana. Escolha de propósito, escreva e faça dele a restrição dentro da qual todo o resto funciona. Se a redação reclamar, o número está fazendo o trabalho dele.
2. Defina um piso de valor antes de definir uma contagem
Alguns envios não deveriam sair em frequência nenhuma. Defina o que uma matéria precisa superar antes de virar um Nudge: um limite de confiança no conteúdo, uma regra por tipo de matéria, o que a sua mesa aceitar. Um teto com folga não é uma instrução para preenchê-lo.
3. Separe rotina de urgência, de forma explícita
Envios de rotina ficam dentro do teto, respeitam horários de silêncio e pulam inscritos dormentes. Envios urgentes podem passar do teto por meio de um override nomeado e registrado. Se o override não é registrado, tudo vira urgente em um mês. Já vi isso acontecer.
4. Guie-se pela qualidade por envio, não por envios por dia
O número que vale pendurar na parede é quanto um envio custa e devolve, não quantos você conseguiu fazer.
Uma versão que funciona: para cada envio, pegue as interações por 1.000 entregues e subtraia os opt-outs e os endpoints inválidos por 1.000 entregues. Isso dá um número líquido por envio que cai quando você empurra uma matéria fraca para uma audiência ampla, exatamente o comportamento que você quer que a métrica puna. Esse é o nosso método, não um padrão do setor. Mude os pesos se a sua economia for diferente, mas mantenha a subtração, porque uma métrica sem um termo de custo sempre vai defender enviar mais.
5. Mude um passo de cada vez e segure
Mude o teto por inscrito em uma unidade, mantenha por duas a quatro semanas e acompanhe o movimento líquido da lista: novas permissões concedidas menos descadastros menos endpoints inválidos. Uma variável, por tempo suficiente para ver a lista responder. Experimentos de frequência que duram quatro dias medem o ciclo de notícias, não a sua política.
A parte que é específica de editores
Todo jornalista quer a sua matéria no push. Isso não é um defeito da redação, é a redação funcionando direito, e cada pedido individual é razoável nos seus próprios termos.
O problema é que quem cuida da audiência está discutindo contra uma pilha de pedidos individualmente razoáveis, e o único número na sala é a contagem de cliques do último envio. Contagem de cliques sempre defende enviar mais. Nada no dashboard padrão mostra quanto o envio custou em inscritos, então a contenção chega com uma opinião e perde.
É por isso que vale manter um registro por envio antes mesmo de mudar qualquer política. Cliques, opt-outs, endpoints inválidos e o movimento líquido da lista na semana, numa linha por envio. A discussão vira aritmética, e com aritmética é muito mais fácil ganhar.
Limitações e ressalvas dos navegadores
- Os limites de taxa do Chrome valem para a Push API, não para a Notifications API, e o Chrome afirma que quase todos os sites não serão afetados. Não use isso para assustar ninguém e empurrar um número.
- As plataformas da Apple são diferentes. 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. A tolerância à frequência e os sinais que você recebe de volta não são idênticos aos do Chrome.
- A mistura de navegadores muda o que tudo isso significa para você. O StatCounter informou a participação mundial de navegadores em julho de 2026 como Chrome 68,22% e Safari 16,47%; na Europa, Chrome 60,71% e Safari 18,67%; na Suécia, Chrome 57,37% e Safari 24,75%. Uma política de frequência ajustada ao comportamento do Chrome cobre uma parcela diferente da sua lista em mercados diferentes.
- Nenhum número nesta página é uma medição do EngageNudge. O método é nosso, os fatos de navegador são do Chrome e do WebKit e os números de participação são do StatCounter, todos com data acima.
Como o EngageNudge lida com a frequência
No EngageNudge, frequência é uma política que o envio precisa cumprir, e não um campo da campanha. Tetos diários e semanais por inscrito, intervalo mínimo entre Nudges, horários de silêncio, regras de dormência e um filtro para envios de baixo valor são avaliados antes da entrega, e um Nudge que não passa é pulado com o motivo registrado.
Por baixo disso ficam os holdouts, para que a pergunta "o envio extra realmente trouxe alguém de volta" tenha uma resposta que não seja a contagem de cliques.
Escrito por William Kim, fundador da EngageNudge. Revisado em 20 de agosto de 2026.