Em algum momento nos últimos dezoito meses, as plataformas pararam de pedir aos remetentes para se comportarem e começaram a impor isso. O Chrome agora limita a taxa de sites que classifica como disruptivos e revoga silenciosamente a permissão de notificação de sites que os usuários ignoram. O Android 16 silencia rajadas de notificações por padrão, agrupa forçadamente tudo e, nos Pixels mais recentes, arquiva promoções em um pacote colapsado e silencioso. O Google Mensagens limita quantos novos usuários um remetente de RCS de baixa reputação pode alcançar. Se você pesquisou "chrome notification crackdown" ou "por que minhas notificações push não estão sendo entregues", esta página é a referência: cada mudança, a fonte primária por trás dela, quem ela afeta e as correções específicas que mantêm um remetente entregue.
Este é um documento vivo. Nós o atualizamos quando uma plataforma lança ou anuncia uma mudança, e cada revisão é registrada no changelog na parte inferior. Última atualização: 17 de agosto de 2026.
Uma nota de enquadramento antes dos detalhes, porque explica cada entrada na tabela abaixo. Nenhuma dessas plataformas está matando notificações. Todas elas estão dividindo as notificações em duas classes: envios de alto volume e baixo engajamento são limitados, silenciados, agrupados ou cancelados — enquanto notificações relevantes e orientadas por eventos mantêm a entrega completa e, em alguns casos, obtêm um posicionamento melhor do que antes. A repressão não é contra o push. É contra o blast.
O que mudou: a linha do tempo da repressão de notificações de 2026
| Plataforma | Mudança | Quem é afetado | Efetivo | Fonte |
|---|---|---|---|---|
| Chrome (desktop + Android) | UI de permissão mais silenciosa: prompt silenciado para usuários que geralmente bloqueiam e para sites com baixas taxas de aceitação de prompt; posteriormente estendido para sites com prompts ou conteúdo abusivos | Sites que solicitam na primeira visualização da página ou enviam conteúdo enganoso | Chrome 80, fevereiro de 2020 (aplicação estendida até 2020) | Blog do Chromium |
| Safari / iOS | Web Push Declarativo: web push sem service worker, sem penalidade de push silencioso para payloads declarativos | Remetentes de web push com destino a usuários da Apple | iOS/iPadOS 18.4 (março de 2025); Mac no Safari 18.5 (maio de 2025) | Blog do WebKit |
| Chrome no Android | ML no dispositivo sinaliza notificações de web push suspeitas como "possivelmente enganosas ou spam" com cancelamento em um toque | Remetentes cujos padrões de cópia de notificação correspondem a spam | Maio de 2025 | Blog do Chromium |
| Android 16 | Esfriamento de notificações (rajadas progressivamente silenciadas, ativadas por padrão) e agrupamento forçado de notificações de todos os aplicativos | Remetentes de push de aplicativos de alta frequência; rajadas de qualquer tipo | Estável em 10 de junho de 2025 | Android Authority; nosso mergulho profundo |
| Chrome (desktop + Android) | Revogação automática de permissão de notificação via Verificação de Segurança para sites de baixo engajamento e alto volume | Sites que enviam muitas notificações nas quais os usuários nunca clicam | Anunciado em 10 de outubro de 2025; em implantação | Blog do Chromium |
| Google Mensagens | Agrupamento de "remetentes desconhecidos"; selos de verificação de empresas verificadas e marca padronizada para RCS | Empresas enviando mensagens para usuários que não as salvaram | A partir de meados de outubro de 2025 (em implantação) | Android Authority |
| Android 16 QPR2 (Pixel) | Organizador de Notificações: IA no dispositivo organiza notificações de Promoções e Notícias em um pacote silencioso e colapsado por padrão; resumos de IA para conversas | Remetentes de push de aplicativos promocionais em Pixels atuais (6 países, inglês) | Dezembro de 2025 | 9to5Google |
| Chrome (desktop + Android) | Limites de taxa da API de push: sites classificados como disruptivos limitados a 1.000 mensagens push/minuto com HTTP 429 acima disso; escada de penalidade de 1 → 7 → 14 dias | Remetentes de alto volume com baixo engajamento por usuário | Em implantação a partir de janeiro de 2026 | Chrome para Desenvolvedores |
| RCS para Empresas | Limites de tráfego baseados em reputação: limites de usuários únicos por período de 28 dias para agentes promocionais de baixa reputação (ativo na Índia; novos agentes começam com baixa reputação); análises de tendências de spam e motivos de cancelamento de inscrição | Remetentes promocionais de RCS, especialmente novos agentes | 7 de janeiro / 16 de fevereiro / 1º de abril de 2026 | Notas de lançamento do RCS para Empresas |
Agora os detalhes por plataforma, na ordem em que aparecerão no seu painel.
Chrome: limites de taxa, permissões revogadas automaticamente e triagem de spam por ML
O Chrome é onde a maioria das equipes de retenção sente o aperto primeiro, porque o push da web é o canal próprio de maior volume que a maioria das marcas de e-commerce utiliza. Três mecanismos separados estão agora ativos e eles se somam.
Limites de taxa da API de push para sites "disruptivos"
Desde janeiro de 2026, o Chrome avalia diariamente cada site em relação a três fatores: mensagens push enviadas por tempo de permanência dos usuários no site, prompts de permissão exibidos por tempo no site e o nível de engajamento do usuário com o site (pontuação de engajamento do site mais minutos em primeiro plano). Um site que falha no teste é classificado como disruptivo e limitado a 1.000 mensagens push por minuto. Tudo acima do limite recebe uma resposta HTTP 429 do serviço de push.
A penalidade aumenta. O primeiro dia disruptivo gera um limite de 1 dia. Um segundo dia consecutivo o estende para 7 dias. A partir do terceiro dia, o limite é de 14 dias de cada vez — e o contador só é redefinido após 42 dias consecutivos de comportamento limpo. O Google não publicou um número de versão do Chrome para a implantação; o mecanismo é avaliado pelo servidor e chegou silenciosamente.
Faça os cálculos com sua própria lista. Com 1.000 mensagens por minuto, um envio para 500.000 assinantes leva mais de oito horas para ser concluído. Um push de venda relâmpago que precisava ser entregue em quinze minutos agora é entregue ao longo de um dia de trabalho completo, e a janela de receita que deveria atingir desapareceu. Esse é o custo real: não uma proibição, uma decadência — sua receita de carrinho recuperado e números de cliques para receita diminuem enquanto seu painel de entrega ainda diz "enviado".
Note o escopo. O limite se aplica apenas à API Push em segundo plano; notificações disparadas de uma aba aberta via API de Notificações não são afetadas. O próprio posicionamento do Google é que “quase todos os sites não serão afetados” — o alvo é o pequeno conjunto de remetentes que enviam alto volume para um público que parou de responder. Se você está nesse conjunto é uma questão mensurável, e a autoauditoria abaixo detalha isso.
Revogação automática de permissão
O segundo mecanismo remove assinantes que você pensava possuir. Anunciado em 10 de outubro de 2025, o Safety Check do Chrome agora revoga automaticamente a permissão de notificação de sites que combinam baixo engajamento do usuário com alto volume de notificações enviadas — o mesmo tratamento que já aplicava a permissões de câmera e localização não utilizadas. A equipe de produto do Chrome justificou isso com um número: menos de 1% de todas as notificações recebem alguma interação dos usuários.
Os detalhes que importam para um remetente:
- Aplicativos web instalados são isentos. Um assinante que adicionou seu site à tela inicial ou desktop mantém a permissão.
- O usuário é notificado quando o Chrome remove uma permissão e pode restaurá-la através do Safety Check ou revisitando seu site e optando novamente.
- O Google relatou que em testes, o excesso de notificações caiu significativamente com “apenas uma mudança mínima no total de cliques em notificações” — e que sites que enviam volumes menores viram as taxas de cliques aumentarem.
Leia esse último ponto novamente, porque ele é toda a repressão em uma única frase. Os cliques nunca estiveram no final da lista. Sites que enviavam menos ganhavam mais por envio. O Chrome agora está aplicando a higiene da lista que os remetentes de alto desempenho já praticavam: seu segmento inativo não é mais um número de vaidade no contador de assinantes, é uma responsabilidade que aciona a aplicação.
O Google não publicou os limites numéricos para “baixo engajamento” ou “alto volume”, então nenhum fornecedor pode prometer um teto seguro. O que você pode controlar é a proporção que o sistema está claramente medindo: interações por notificação entregue.
Triagem de ML no dispositivo no Android
O terceiro mecanismo, ativo desde maio de 2025, coloca um modelo de machine learning entre sua notificação e os olhos do usuário. O Chrome no Android analisa o conteúdo de web push recebido no dispositivo (web push é criptografado de ponta a ponta, então a análise deve ser local — o modelo lê o título, corpo e rótulos dos botões de ação). Notificações que correspondem a padrões de engano ou spam são exibidas com um aviso e uma opção de cancelar inscrição com um toque.
Os hábitos de cópia que enganam os classificadores de spam são aqueles em que os remetentes de baixa qualidade se apoiam: urgência falsa, lacunas de clickbait, estilo enganoso de mensagens do sistema. Se a cópia da sua notificação puder ser confundida com um modelo de golpe de prêmio, em alguns telefones agora ela vem com um rótulo de aviso e uma porta de saída anexada.
O que o histórico do Chrome diz sobre o que vem a seguir
Nada disso é uma guinada. O Chrome silenciou o prompt de permissão para sites de baixa aceitação em fevereiro de 2020, depois estendeu a aplicação para prompts abusivos e conteúdo abusivo mais tarde naquele mesmo ano. A onda de 2025-2026 move a aplicação do momento de opt-in para o próprio relacionamento de envio. A direção tem sido unilateral por seis anos: cada lançamento torna o engajamento mais importante. Planeje que os limites se tornem mais rígidos, não mais frouxos.
Android 16: cooldown, agrupamento forçado e o pacote silencioso de Promoções
As mudanças do Android afetam o push de aplicativos em vez do navegador, e mudam o que "entregue" significa em vez de se a entrega acontece.
Cooldown de notificação, ativado por padrão quando o Android 16 ficou estável em 10 de junho de 2025, visa rajadas. A primeira notificação em uma rajada alerta com volume total e um banner completo; cada uma subsequente em aproximadamente um minuto fica progressivamente mais silenciosa e visualmente minimizada, e a rajada colapsa sob um único banner. Chamadas, alarmes e conversas prioritárias estão isentos; pushes de marketing e transacionais não. Nada é excluído e os relatórios de entrega não se movem — que é exatamente por isso que a mudança é perigosa. Seu painel diz três entregues; o telefone do usuário apresentou uma. Publicamos uma análise completa da mecânica e das correções de design de envio em nosso guia de cooldown de notificação do Android 16.
Agrupamento forçado remove uma escolha que os desenvolvedores costumavam ter: o Android 16 agrupa todas as notificações do mesmo aplicativo, quer o aplicativo tenha optado por isso ou não. Combinado com o cooldown, os segundo e terceiro pushes de qualquer sequência rápida agora são itens silenciosos e colapsados em vez de banners.
O Organizador de Notificações é o mais afiado dos três. Sendo lançado desde dezembro de 2025 com o Android 16 QPR2 nos telefones das séries Pixel 9 e 10 (9to5Google), ele usa um modelo no dispositivo para classificar notificações em Promoções, Notícias, Social e Sugeridas — e as categorias de Promoções e Notícias estão habilitadas por padrão, arquivando notificações correspondentes em um pacote colapsado na seção silenciosa da sombra. O lançamento é restrito hoje (Pixels recentes, seis países, inglês), mas o padrão importa: nos dispositivos que o Google controla totalmente, um push promocional não toca mais, não exibe mais banner e fica dobrado até que o usuário procure. Ao lado dele, resumos de IA no dispositivo comprimem notificações de conversas.
O mesmo ciclo do SO também construiu a via oposta. As notificações centradas no progresso do Android 16 (o padrão Live Updates) oferecem eventos genuinamente ao vivo e rastreados pelo usuário — uma entrega a caminho, o status de um pedido — com posicionamento persistente e elevado. Os lançamentos de 2026 do Google continuaram a estender essa via de conteúdo ao vivo, embora os detalhes do que será lançado além do Android 16 ainda estejam sendo definidos e valham a pena verificar as notas de lançamento atuais do Android antes de você criar para eles. A intenção do design já é inequívoca: o conteúdo que o usuário está rastreando ativamente é promovido; o conteúdo que o remetente quer que o usuário perceba é organizado para fora do caminho.
Abaixo da camada do SO, os limites de longa data por dispositivo do Firebase Cloud Messaging ainda se aplicam — 240 mensagens por minuto e 5.000 por hora para um único dispositivo, com remetentes sustentados perto do limite arriscando uma marcação de abuso. Todo sistema que sua empresa executa contra o mesmo aplicativo compartilha esse orçamento.
iOS e Safari: um tipo mais silencioso de portão
A história da Apple de 2025-2026 é menos uma repressão do que uma abertura controlada, porque a Apple construiu seus portões desde o início: o web push no iOS sempre exigiu que o usuário adicionasse seu site à tela inicial primeiro (um filtro deliberado de alta intenção, em vigor desde o iOS 16.4), e a política da App Store há muito tempo restringe o marketing push.
O que mudou:
- Declarative Web Push foi lançado no iOS/iPadOS 18.4 em março de 2025 e chegou ao Mac no Safari 18.5 (WebKit). Ele permite que você execute web push a partir de um payload JSON padronizado sem um service worker e remove a penalidade de push silencioso para mensagens declarativas porque o payload em si garante uma notificação visível. O push de service worker legado continua funcionando; o formato declarativo é o caminho para o futuro que a Apple quer que os remetentes sigam.
- O iOS 26, segundo relatos, define os sites da Tela Inicial como padrão para abrir como web apps, o que amplia a superfície onde o web push do iOS pode ser executado. Vimos isso documentado apenas de segunda mão até agora; trate-o como direcional até que a documentação da Apple seja explícita.
- A política permanece inalterada e rigorosa. A Diretriz de Revisão de Apps 4.5.4 ainda exige que o push não seja obrigatório para o funcionamento do seu app, não contenha dados pessoais sensíveis e — para promoções ou marketing direto — seja enviado apenas a usuários que optaram explicitamente por meio de linguagem de consentimento na interface do seu app, com um opt-out no aplicativo. O abuso "pode resultar na revogação dos seus privilégios."
Para uma equipe de retenção, a conclusão do iOS é que a Apple pré-filtrou seu público para você. Um assinante de web push do iOS escolheu instalar seu site; um assinante de push de app escolheu optar pelo marketing. Ambas as listas são pequenas e de alta intenção — o que significa que queimá-las com frequência de explosão é mais caro por assinante do que em qualquer outro lugar.
RCS: limites de reputação chegam ao canal mais novo
Se você está adicionando RCS ou WhatsApp ao seu mix — e para recuperação de carrinho e atualizações de pedidos, você deve estar avaliando canais de mensagens — o Google já instalou a camada de aplicação que o web push levou seis anos para obter.
De acordo com a documentação do RCS for Business do Google, cada remetente comercial (agente) tem uma reputação — Alta, Média ou Baixa — impulsionada pelo feedback do usuário e relatórios de spam, e todos os novos agentes começam com Baixa. A reputação define um limite de tráfego: o número de usuários exclusivos com os quais o agente pode iniciar conversas a cada 28 dias. Respostas a conversas iniciadas pelo usuário são isentas. A aplicação entrou em vigor para agentes promocionais na Índia em 7 de janeiro de 2026, foi reforçada em 1º de abril de 2026 com um limite entre agentes para remetentes de baixa reputação, e o console do desenvolvedor agora relata o nível de reputação, limite de tráfego, tendência de spam e motivos de cancelamento de inscrição em janelas de 7 e 28 dias.
No lado do consumidor, o Google Mensagens tem agrupado mensagens de remetentes não salvos em "Remetentes desconhecidos" desde meados de outubro de 2025 e está implementando marcas de verificação verificadas e branding comercial padronizado — evidências em fase de desmontagem sobre alguns detalhes, mas a direção corresponde a todo o resto neste documento. No RCS, você não tem um período de carência para criar maus hábitos: o alcance é conquistado pelo engajamento desde a primeira mensagem.
Você está em risco? A autoauditoria {#self-audit}
O Chrome e o Google publicam os fatores, mas não os limites, portanto, a auditoria honesta é relativa: meça se você se parece com o remetente que esses sistemas foram criados para impedir. Execute estas oito verificações em seus últimos 30 dias de envios. Cada "não" é uma constatação. Várias dessas verificações só têm sentido contra números externos, portanto, execute-as em conjunto com nossos benchmarks de notificações push de 2026, onde as distribuições percentuais de taxa de visualização e taxa de cliques mostram o que o remetente mediano, p75 e p90 realmente atinge.
- Razão de interação. Sua taxa de cliques de web push está significativamente acima da linha de base de interação de menos de 1% do ecossistema que o Chrome citou ao justificar a revogação automática? Se sua CTR tem um zero após o ponto decimal, você está dentro do perfil contra o qual o Chrome está aplicando a aplicação.
- Volume vs. visitas. O primeiro fator de site disruptivo do Chrome são os pushes enviados por tempo gasto no site. Você está enviando mais notificações para um assinante típico por semana do que esse assinante tem sessões com você por semana? Um assinante que visita mensalmente e recebe notificações diárias falha nessa razão.
- Cauda inativa. Qual a porcentagem da sua lista não clicou em nenhuma notificação em 90 dias? Se mais da metade dos seus envios for para essa cauda, sua taxa de engajamento agregada está sendo definida por pessoas que já saíram — e as plataformas avaliam o agregado.
- Disciplina de prompt. Você solicita permissão de notificação na primeira visualização da página, antes que o visitante tenha feito algo? A taxa de aceitação de prompt é um critério de inscrição de UI discreta e um fator de site disruptivo. Solicitar após uma ação demonstrada (segunda visualização da página, adicionar ao carrinho, criação de conta) é a correção, e isso aparece diretamente em sua taxa de opt-in.
- Compartilhamento em massa. Qual porcentagem do seu volume de envio mensal são envios em massa para toda a lista sem segmentação, em comparação com notificações acionadas por algo que o destinatário fez (carrinho abandonado, preço reduzido, item de volta em estoque, pedido enviado)? Acima de aproximadamente metade de envios em massa, você está com volume pesado exatamente no padrão que todos os mecanismos nesta página penalizam.
- Limites de frequência e horários de silêncio. Você aplica um limite por assinante em todas as campanhas e sistemas que podem enviar — marketing, transacional, RSS e qualquer segunda ferramenta? O cooldown e o agrupamento forçado do Android significam que remetentes descoordenados agora se canibalizam visivelmente no mesmo dispositivo.
- Honestidade na cópia. Alguma notificação recente sobreviveria ao teste de um leitor cético de “isso é enganoso?” — sem urgência falsa, sem cosplay de mensagem do sistema, sem lacunas de isca? O classificador no dispositivo do Chrome já está executando esse teste no Android.
- Tendência de cancelamento de inscrição. Sua taxa de cancelamento de inscrição por envio está estável ou caindo? No RCS, agora alimenta uma pontuação de reputação com um limite de tráfego rígido anexado; no push da web, é seu aviso antecipado. Nosso guia para reduzir as taxas de cancelamento de inscrição de notificações push cobre o diagnóstico em profundidade.
Avalie-se honestamente. Cinco ou mais respostas limpas e a repressão é principalmente uma vantagem para você — o spray-and-pray de seus concorrentes está sendo limitado enquanto seus envios continuam chegando. Três ou mais descobertas e você deve assumir que já está perdendo alcance que não pode ver em um relatório de entrega.
O manual de conformidade: correções que se sustentam
Todos os mecanismos acima medem a mesma quantidade subjacente — valor por notificação — portanto, as correções convergem. Essas seis ações, em ordem de prioridade.
1. Corte a cauda inativa antes que as plataformas a cortem por você. Crie um segmento de inativos (sem clique em 90 dias), execute uma sequência honesta de reengajamento através dele e, em seguida, pare de enviar para não respondentes. Isso é contraintuitivo para equipes que tratam o tamanho da lista como o KPI, mas a matemática é unidirecional agora: um assinante inativo contribui com zero receita e degrada ativamente a proporção de engajamento na qual o Chrome o pontua. No PushEngage, a segmentação dinâmica mantém o bucket de inativos automaticamente e, como a precificação conta apenas assinantes ativos, cortar peso morto reduz sua conta em vez de seu alcance.
2. Mova o volume de envio de disparos para gatilhos. Um push de abandono de carrinho, um alerta de queda de preço, um aviso de reposição de estoque — estes geram cliques porque o próprio comportamento do destinatário os agendou. Mover até metade do seu volume mensal de disparos baseados em calendário para campanhas acionadas aumenta sua taxa de interação em todos os fatores que o Chrome mede, e é para onde a receita estava indo de qualquer forma: envios acionados são atribuídos a carrinhos recuperados e pedidos concluídos, não a impressões. Apresentamos o argumento completo, com as definições de classes de campanha e a matemática de receita por envio, em por que a era dos disparos acabou de terminar.
3. Segmente o que ainda é transmitido. Alguns envios legitimamente vão para todos — uma promoção na loja inteira, a notícia de última hora de uma editora. Amplo não é o mesmo que não segmentado. Dividir uma transmissão por comportamento, histórico de compras ou afinidade de categoria aumenta os cliques em cada fatia e mantém a taxa de push por visita de cada assinante defensável. A segmentação é agora um requisito de entregabilidade, não uma gentileza de personalização — essa postagem carrega o caso completo de entregabilidade.
4. Aplique um limite de frequência em todos os canais e sistemas. O cooldown do Android 16 tornou isso concreto: seu CRM, sua camada transacional e seu calendário promocional compartilham um orçamento de atenção no dispositivo, quer compartilhem ou não um painel. Defina um limite por assinante e horários de silêncio no nível da plataforma, abrangendo push da web, push do aplicativo e WhatsApp juntos, para que quatro sistemas razoáveis não possam se compor em um padrão abusivo. Isso só funciona se um motor de segmentação vir todos os envios — o argumento prático mais forte para consolidar canais em vez de executar uma ferramenta por canal.
5. Corrija o momento do opt-in. Mova o prompt de permissão para trás de uma ação que sinalize intenção, use um prompt de duas etapas para que a solicitação no nível do navegador só seja acionada com um sim, e aceite a lista menor e mais limpa. A taxa de aceitação do prompt alimenta a pontuação do Chrome em ambas as extremidades — o registro com UI discreta e a avaliação do site disruptivo — e uma lista consentida é simplesmente a lista que clica.
6. Faça o texto sobreviver a um classificador. Alegações diretas, urgência real apenas quando o prazo é real, identidade do remetente óbvia. No Android, um modelo de ML lê seu título e corpo antes do usuário. Textos honestos sempre foram uma prática melhor de retenção; agora também é um requisito de entrega.
Se você executar estes seis no PushEngage, o resumo honesto de onde o produto ajuda: campanhas acionadas, segmentos RFM e comportamentais, limites de frequência entre canais, horários de silêncio e atribuição de receita por notificação são todos integrados, em planos que cobram apenas por assinantes ativos — o modelo de precificação por acaso aponta na mesma direção que as plataformas agora impõem. O que nenhuma ferramenta pode fazer é decidir parar de disparar; essa parte é política, e é sua.
FAQ
Por que minhas notificações push não estão sendo entregues em 2026? Verifique quatro suspeitos em ordem. Primeiro, revogação automática do Chrome: se o número de seus assinantes estiver diminuindo silenciosamente, assinantes de baixo engajamento podem estar perdendo a permissão por meio da Verificação de Segurança. Segundo, limites de taxa do Chrome: se os envios para listas grandes de repente levarem horas ou seu serviço de push registrar respostas HTTP 429, você provavelmente foi classificado como disruptivo. Terceiro, apresentação do Android: no Android 16, a entrega ainda acontece, mas os picos são silenciados e agrupados, e nos Pixels mais recentes, os pushes promocionais chegam a um pacote silencioso — entregues, mas não vistos. Quarto, as causas chatas que antecedem a repressão: assinaturas expiradas, erros de service-worker e configurações de notificação no nível do sistema operacional.
O Chrome baniu as notificações push? Não. O Chrome limita a taxa de sites que ele classifica como disruptivos (alto volume, baixo engajamento) e revoga permissões que os usuários demonstram ignorar. Um remetente cujas notificações são clicadas não é afetado por nenhum dos mecanismos, e os testes do Google descobriram que remetentes de menor volume viram as taxas de cliques aumentarem.
Qual taxa de engajamento me mantém seguro contra a revogação automática do Chrome? O Google não publicou limites e qualquer fornecedor que lhe diga um número seguro está adivinhando. Os fatos publicados: menos de 1% de todas as notificações recebem alguma interação, e a revogação visa a combinação de engajamento muito baixo com alto volume de envio. A estratégia defensável é manter sua taxa de cliques bem clara dessa linha de base e parar de enviar para assinantes que pararam de responder.
Os limites de taxa do Chrome afetam toda a minha conta ou apenas um site? A linguagem de avaliação do Chrome é por site — mensagens, prompts e engajamento são medidos em relação a “um site”. Remetentes que usam uma plataforma de push são avaliados com base no comportamento de seu próprio domínio, não no agregado de seu fornecedor. O Google não publicou orientações além disso, portanto, trate os detalhes entre domínios como não confirmados.
O que mudou para notificações push no Android 16? Três coisas: resfriamento de notificações (picos progressivamente silenciados por até um minuto, ativados por padrão, chamadas e alarmes isentos), agrupamento forçado das notificações de cada aplicativo e — a partir da atualização QPR2 de dezembro de 2025 em Pixels recentes — o Organizador de Notificações, que arquiva notificações de Promoções e Notícias em um pacote silencioso e recolhido por padrão. Mecânicas completas em nosso guia de resfriamento do Android 16.
A repressão se aplica ao iOS? As restrições da Apple são em sua maioria anteriores a ela: o push da web do iOS exige que o usuário adicione seu site à sua Tela de Início, e a Diretriz da App Store 4.5.4 exige opt-in explícito mais um opt-out no aplicativo para marketing push. A mudança de 2025 é o Declarative Web Push (iOS 18.4 / Safari 18.5), um formato mais simples e sem service-worker, sem penalidade de push silencioso para mensagens declarativas.
As mensagens empresariais RCS também têm limite de taxa? Sim, por reputação. O Google atribui a cada agente empresarial RCS uma reputação Alta/Média/Baixa com base no feedback do usuário e em denúncias de spam; agentes de baixa reputação (incluindo todos os novos agentes) enfrentam limites para usuários únicos iniciados por período de 28 dias. A aplicação está ativa para agentes promocionais na Índia desde o início de 2026, com relatórios de reputação e tendências de spam no console do desenvolvedor para todos.
O web push ainda vale a pena em 2026? Para remetentes que acionam e segmentam, mais do que antes: o tráfego de spray-and-pray com estrangulamento costumava competir pela mesma barra de notificações que você. As plataformas estão fortalecendo o canal para os remetentes para os quais o canal foi construído — e afastando o resto.
Última atualização e changelog {#changelog}
Este hub é mantido como uma referência viva. Convenção: a data da “Última atualização” muda apenas para atualizações substanciais (uma plataforma lançando, anunciando ou documentando uma mudança), não para edições de cópia. Cada atualização substancial recebe uma linha de changelog com uma fonte. Se você estiver citando esta página, cite-a com sua data de última atualização.
- 21/09/2026 — Publicação inicial. Abrange: limites de taxa da API de Push do Chrome (janeiro de 2026), revogação automática de permissões do Chrome (anunciado em outubro de 2025), triagem de notificações de ML no dispositivo do Chrome (maio de 2025), cooldown do Android 16 + agrupamento forçado (junho de 2025), Organizador de Notificações do Android 16 QPR2 (dezembro de 2025), Web Push Declarativo (iOS 18.4 / Safari 18.5, 2025), limites de tráfego baseados em reputação RCS e análises de tendências de spam (janeiro-abril de 2026), alterações de remetente desconhecido e marca verificada do Google Mensagens (a partir de outubro de 2025).
Algo mudou e não registramos? A maneira mais rápida de nos informar é através do widget de chat nesta página.
