Em algum momento nos últimos dezoito meses, as plataformas deixaram 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 tudo à força e, nos Pixels mais recentes, arquiva envios promocionais em um pacote colapsado e silencioso. O Google Mensagens limita quantos novos usuários um remetente RCS de baixa reputação pode alcançar. Se você pesquisou “chrome notification crackdown” ou “why are my push notifications not delivered”, esta página é a referência: todas as mudanças, a fonte primária por trás delas, quem elas afetam e as correções específicas que garantem a entrega do remetente.
Este é um documento vivo. Atualizamo-lo 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, pois explica cada entrada na tabela abaixo. Nenhuma dessas plataformas está a matar notificações. Todas elas estão a dividir as notificações em duas classes: envios de alto volume e baixo envolvimento são estrangulados, silenciados, agrupados ou cancelados — enquanto notificações relevantes e orientadas por eventos mantêm a entrega completa e, em alguns casos, obtêm uma colocação 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 | Alterar | Quem é afetado | Eficaz | 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 a 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 | Declarative Web Push: web push sem service worker, sem penalidade de push silencioso para payloads declarativos | Remetentes de web push que visam utilizadores 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 | Cooldown 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 10 de junho de 2025 | Android Authority; nosso mergulho profundo |
| Chrome (desktop + Android) | Revogação automática de permissão de notificação via Safety Check para sites de baixo envolvimento e alto volume | Sites que enviam muitas notificações nas quais os usuários nunca clicam | Anunciado a 10 de outubro de 2025; em implementação | Blog do Chromium |
| Google Messages | Agrupamento de “remetentes desconhecidos”; vistos de verificação de empresas verificadas e marca padronizada para RCS | Empresas a enviar mensagens a utilizadores que não as guardaram | A partir de meados de outubro de 2025 (em implementação) | Android Authority |
| Android 16 QPR2 (Pixel) | Organizador de Notificações: IA no dispositivo organiza notificações de Promoções e Notícias num pacote silencioso e colapsado por defeito; resumos de IA para conversas | Envios de notificações push de aplicações promocionais em Pixels atuais (6 países, inglês) | Dezembro de 2025 | 9to5Google |
| Chrome (desktop + Android) | Limites de taxa da API Push: sites classificados como disruptivos limitados a 1.000 mensagens push/minuto com HTTP 429 acima disso; escada de penalização de 1 → 7 → 14 dias | Remetentes de alto volume com baixo envolvimento por utilizador | Em implementação a partir de janeiro de 2026 | Chrome para Desenvolvedores |
| RCS para Empresas | Limites de tráfego baseados em reputação: limites de utilizadores únicos por cada 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 subscriçã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 o detalhe por plataforma, na ordem em que aparecerá no seu painel.
Chrome: limites de taxa, permissões revogadas automaticamente e filtragem de spam por ML
O Chrome é onde a maioria das equipas de retenção sente o aperto primeiro, porque o web push é o canal próprio de maior volume que a maioria das marcas de comércio eletrónico utiliza. Três mecanismos separados estão agora ativos e eles acumulam-se.
Limites de taxa da API Push para sites “disruptivos”
Desde janeiro de 2026, o Chrome avalia diariamente cada site com base em três fatores: mensagens push enviadas por tempo de permanência dos utilizadores no site, pedidos de permissão apresentados por tempo no site e o nível de envolvimento do utilizador com o site (pontuação de envolvimento do site mais minutos em primeiro plano). Um site que falhe o teste é classificado como disruptivo e limitado a 1.000 mensagens push por minuto. Tudo o que exceder o limite recebe uma resposta HTTP 429 do serviço de push.
A penalidade aumenta. O primeiro dia disruptivo resulta num limite de 1 dia. Um segundo dia consecutivo estende-o para 7 dias. A partir do terceiro dia, o limite dura 14 dias de cada vez — e o contador só é reposto após 42 dias consecutivos de comportamento limpo. O Google não publicou um número de versão do Chrome para a implementação; o mecanismo é avaliado pelo servidor e chegou silenciosamente.
Faça os cálculos com a sua própria lista. Com 1.000 mensagens por minuto, um envio para 500.000 subscritores demora mais de oito horas a ser concluído. Uma notificação push de venda relâmpago que precisava de ser entregue em quinze minutos agora é entregue ao longo de um dia de trabalho completo, e a janela de receita que deveria ter atingido desapareceu. Esse é o custo real: não uma proibição, uma decadência — a sua receita de carrinho recuperado e os números de cliques para receita diminuem enquanto o seu painel de entrega ainda diz “enviado”.
Note o âmbito. O limite aplica-se apenas à API Push em segundo plano; as notificações enviadas a partir de um separador aberto através da API Notifications não são afetadas. A própria formulação do Google é que “quase todos os websites não serão afetados” — o alvo é o pequeno conjunto de remetentes que enviam um grande volume para um público que deixou de responder. Se está nesse conjunto é uma questão mensurável, e a autoauditoria abaixo explica como.
Revogação automática de permissão
O segundo mecanismo remove subscritores que pensava possuir. Anunciado a 10 de outubro de 2025, a Verificação de Segurança do Chrome revoga agora automaticamente a permissão de notificação de sites que combinam um envolvimento do utilizador muito baixo com um elevado volume de notificações enviadas — o mesmo tratamento que já aplicava a permissões de câmara e localização não utilizadas. A equipa de produto do Chrome justificou-o com um número: menos de 1% de todas as notificações recebem qualquer interação dos utilizadores.
Os detalhes que importam para um remetente:
- As aplicações web instaladas estão isentas. Um subscritor que adicionou o seu site ao seu ecrã principal ou ambiente de trabalho mantém a permissão.
- O utilizador é notificado quando o Chrome remove uma permissão e pode restaurá-la através da Verificação de Segurança ou revisitando o seu site e voltando a optar por participar.
- O Google relatou que, em testes, a sobrecarga de notificações diminuiu significativamente com “apenas uma alteração mínima no total de cliques em notificações” — e que os sites que enviam volumes menores viram as taxas de cliques aumentar.
Leia o último ponto novamente, porque é toda a repressão numa única frase. Os cliques nunca estiveram na cauda da lista. Os sites que enviavam menos ganhavam mais por envio. O Chrome está agora a impor a higiene da lista que os remetentes de alto desempenho já praticavam: o seu segmento inativo já não é um número de vaidade no contador de subscritores, é uma responsabilidade que desencadeia a aplicação.
O Google não publicou os limiares numéricos para “baixo envolvimento” ou “alto volume”, pelo que nenhum fornecedor lhe pode prometer um teto seguro. O que pode controlar é a proporção que o sistema está claramente a medir: interações por notificação entregue.
Análise de ML no dispositivo no Android
O terceiro mecanismo, ativo desde maio de 2025, coloca um modelo de machine learning entre a sua notificação e os olhos do utilizador. O Chrome no Android analisa o conteúdo de web push recebido no dispositivo (o web push é encriptado de ponta a ponta, pelo que a análise tem de ser local — o modelo lê o título, o corpo e os rótulos dos botões de ação). As notificações que correspondem a padrões de engano ou spam são apresentadas com um aviso e uma opção de cancelar subscriçã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: falsa urgência, lacunas de clickbait, estilo enganoso de mensagens do sistema. Se a cópia da sua notificação puder ser confundida com um modelo de fraude de prémios, em alguns telefones agora é enviada com um rótulo de aviso e uma porta de saída anexada.
O que o histórico do Chrome lhe diz sobre o que vem a seguir
Nada disto é um desvio. O Chrome silenciou o pedido de permissão para sites de baixa aceitação em fevereiro de 2020, e depois estendeu a aplicação para prompts abusivos e conteúdo abusivo mais tarde nesse mesmo ano. A vaga de 2025-2026 move a aplicação do momento de adesão para a própria relação de envio. A direção tem sido unilateral durante seis anos: cada lançamento torna o envolvimento mais importante. Planeie que os limites se tornem mais rigorosos, não mais frouxos.
Android 16: arrefecimento, agrupamento forçado e o pacote silencioso de Promoções
As alterações do Android afetam o push de aplicações em vez do navegador, e alteram o que "entregue" significa em vez de se a entrega acontece.
Arrefecimento de notificações, ativado por defeito quando o Android 16 ficou estável em 10 de junho de 2025, visa rajadas. A primeira notificação numa rajada alerta com volume total e um banner completo; cada uma subsequente dentro de aproximadamente um minuto é progressivamente mais silenciosa e visualmente minimizada, e a rajada colapsa sob um único banner. Chamadas, alarmes e conversas prioritárias estão isentos; promoções e pushes transacionais não. Nada é apagado e os relatórios de entrega não se movem — que é exatamente por isso que a mudança é perigosa. O seu painel diz três entregues; o telefone do utilizador apresentou um. Publicámos uma análise completa da mecânica e das correções de design de envio no nosso guia de arrefecimento de notificações do Android 16.
Agrupamento forçado remove uma escolha que os programadores costumavam ter: o Android 16 agrupa todas as notificações da mesma aplicação, quer a aplicação tenha optado por participar ou não. Combinado com o arrefecimento, os segundos e terceiros pushes de qualquer sequência rápida são agora silenciosos, itens de linha colapsados em vez de banners.
O Organizador de Notificações é o mais aguçado dos três. A ser lançado desde dezembro de 2025 com o Android 16 QPR2 nos telemóveis das séries Pixel 9 e 10 (9to5Google), utiliza um modelo no dispositivo para classificar notificações em Promoções, Notícias, Social e Sugeridas — e as categorias Promoções e Notícias estão ativadas por defeito, arquivando notificações correspondentes num pacote colapsado na secção silenciosa da sombra. O lançamento é restrito hoje (Pixels recentes, seis países, inglês), mas o padrão importa: nos dispositivos que a Google controla totalmente, um push promocional já não toca, já não faz banner, e fica dobrado até o utilizador procurar. Ao lado dele, resumos de IA no dispositivo comprimem notificações de conversação.
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) fornecem eventos genuinamente em tempo real, rastreados pelo utilizador — uma entrega a caminho, o estado de uma encomenda — com posicionamento persistente e elevado. Os lançamentos de 2026 do Google continuaram a estender esta via de conteúdo em tempo real, embora os detalhes do que será lançado para além do Android 16 ainda estejam a ser definidos e valha a pena verificar as notas de lançamento atuais do Android antes de construir com base nelas. A intenção do design já é inequívoca: o conteúdo que o utilizador está a rastrear ativamente é promovido; o conteúdo que o remetente quer que o utilizador note é organizado para fora do caminho.
Por baixo 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 que mantêm perto do limite a arriscar uma marcação de abuso. Todos os sistemas que a sua empresa executa contra a mesma aplicação partilham 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 os seus portões desde o início: o web push no iOS sempre exigiu que o utilizador adicionasse primeiro o seu site ao seu Ecrã Principal (um filtro deliberado de alta intenção, em vigor desde o iOS 16.4), e a política da App Store tem limitado há muito tempo o marketing push.
O que mudou:
- Web Push Declarativo foi lançado no iOS/iPadOS 18.4 em março de 2025 e chegou ao Mac no Safari 18.5 (WebKit). Permite executar web push a partir de uma carga útil JSON padronizada sem um service worker e remove a penalidade de push silencioso para mensagens declarativas porque a própria carga útil garante uma notificação visível. O push de service worker legado continua a funcionar; o formato declarativo é o caminho futuro em que a Apple quer que os remetentes estejam.
- O iOS 26, segundo relatos, define os sites do Ecrã Principal para abrir como web apps por defeito, o que alarga a superfície onde o web push do iOS pode ser executado. Só vimos isto documentado de forma secundária 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 da sua app, não transporte dados pessoais sensíveis e — para promoções ou marketing direto — seja enviado apenas a utilizadores que optaram explicitamente por ele através de linguagem de consentimento na interface do utilizador da sua app, com uma opção de exclusão dentro da app. O abuso "pode resultar na revogação dos seus privilégios."
Para uma equipa de retenção, a conclusão do iOS é que a Apple pré-filtrou o seu público por si. Um assinante de web push do iOS escolheu instalar o seu site; um assinante de push de app optou por receber 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 mais novo canal
Se estiver a adicionar RCS ou WhatsApp ao seu conjunto — e para recuperação de carrinho e atualizações de encomendas, deve estar a avaliar canais de mensagens — o Google já instalou a camada de aplicação que o web push demorou seis anos a obter.
De acordo com a documentação do RCS para Empresas do Google, cada remetente comercial (agente) tem uma reputação — Alta, Média ou Baixa — impulsionada pelo feedback do utilizador e por denúncias de spam, e todos os novos agentes começam com Baixa. A reputação define um limite de tráfego: o número de utilizadores únicos com os quais o agente pode iniciar conversações por um período contínuo de 28 dias. As respostas a conversações iniciadas pelo utilizador estão isentas. A aplicação entrou em vigor para agentes promocionais na Índia a 7 de janeiro de 2026, foi reforçada a 1 de abril de 2026 com um limite geral para remetentes de baixa reputação, e a consola de programador reporta agora o nível de reputação, o limite de tráfego, a tendência de spam e os motivos de cancelamento ao longo de janelas de 7 e 28 dias.
Do lado do consumidor, o Google Messages tem agrupado mensagens de remetentes não guardados em "Remetentes desconhecidos" desde meados de outubro de 2025 e está a implementar marcas de verificação verificadas e branding comercial padronizado — evidências de desmontagem sobre alguns detalhes, mas a direção corresponde a todo o resto neste documento. No RCS não obtém um período de carência para desenvolver maus hábitos: o alcance é conquistado pelo envolvimento desde a primeira mensagem.
Está em risco? A autoauditoria {#self-audit}
O Chrome e o Google publicam os fatores, mas não os limiares, pelo que a auditoria honesta é relativa: meça se se parece com o remetente que estes sistemas foram construídos para impedir. Execute estas oito verificações contra os seus últimos 30 dias de envios. Cada "não" é uma constatação. Várias destas verificações só fazem sentido contra números externos, pelo que as execute em conjunto com os nossos referenciais de notificações push de 2026, onde as distribuições percentílicas para a taxa de visualização e a taxa de cliques mostram o que o remetente mediano, p75 e p90 realmente atinge.
- Rácio de interação. A 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 o seu CTR tiver um zero após o ponto decimal, está dentro do perfil contra o qual o Chrome está a aplicar.
- Volume vs. visitas. O primeiro fator disruptivo de sites do Chrome são os pushes enviados por tempo gasto no site. Está a enviar mais notificações a um assinante típico por semana do que esse assinante tem sessões consigo por semana? Um assinante que visita mensalmente e recebe pushes diariamente falha este rácio.
- Cauda inativa. Que percentagem da sua lista não clicou em nenhuma notificação em 90 dias? Se mais de metade dos seus envios forem para essa cauda, a sua taxa de envolvimento agregada está a ser definida por pessoas que já saíram — e as plataformas avaliam o agregado.
- Disciplina de prompt. Solicita a permissão de notificação na primeira visualização da página, antes que o visitante tenha feito algo? A taxa de aceitação do prompt é um critério de inscrição de UI discreta e um fator de perturbação do site. 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 reflete diretamente na sua taxa de adesão.
- Partilha massiva. Que percentagem do seu volume de envio mensal são envios massivos não segmentados para toda a lista, em comparação com notificações acionadas por algo que o destinatário fez (carrinho abandonado, preço reduzido, item de volta em stock, encomenda enviada)? Acima de cerca de metade de envios massivos, você tem um volume elevado exatamente no padrão que todos os mecanismos desta página penalizam.
- Limites de frequência e horas de silêncio. Você impõe um limite por assinante em todas as campanhas e sistemas que podem enviar — marketing, transacional, RSS e qualquer ferramenta secundária? O arrefecimento e agrupamento forçado do Android significam que remetentes descoordenados agora se canibalizam visivelmente no mesmo dispositivo.
- Honestidade da cópia. Alguma notificação recente sobreviveria ao teste de um leitor cético de “isto é enganoso?” — sem urgência falsa, sem disfarce de mensagem do sistema, sem iscas? O classificador no dispositivo do Chrome já está a executar esse teste no Android.
- Tendência de cancelamento de subscrição. A sua taxa de cancelamento de subscrição por envio é estável ou está a diminuir? No RCS, agora alimenta uma pontuação de reputação com um limite de tráfego rígido anexado; no push web, é o seu aviso antecipado. O nosso guia para reduzir as taxas de cancelamento de subscrição de notificações push cobre o diagnóstico em profundidade.
Avalie-se honestamente. Cinco ou mais respostas limpas e a repressão é, na sua maioria, uma vantagem para si — o envio aleatório dos seus concorrentes está a ser limitado enquanto os seus envios continuam a chegar. Três ou mais constatações e deve assumir que já está a perder alcance que não consegue ver num 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 — pelo que as correções convergem. Estas seis ações, por ordem de prioridade.
1. Corte a cauda inativa antes que as plataformas a cortem por si. Crie um segmento de inativos (sem clique em 90 dias), execute uma sequência honesta de reativação através dele, depois pare de enviar para os não respondedores. Isto é contraintuitivo para equipas que tratam o tamanho da lista como o KPI, mas a matemática é unidirecional agora: um assinante dormente contribui com zero receita e degrada ativamente a proporção de envolvimento que o Chrome pontua. No PushEngage, a segmentação dinâmica mantém o balde de inativos automaticamente e, como o preço conta apenas os assinantes ativos, cortar o peso morto reduz a sua fatura em vez do seu alcance.
2. Mover o volume de envios de 'blasts' para 'triggers'. Uma notificação de abandono de carrinho, um alerta de descida de preço, um aviso de reposição de stock — estes geram cliques porque o próprio comportamento do destinatário os agendou. Mover mesmo metade do seu volume mensal de envios baseados em calendário para campanhas acionadas aumenta a sua taxa de interação em todos os fatores que o Chrome mede, e é para onde a receita estava de qualquer forma: envios acionados atribuem a carrinhos recuperados e encomendas concluídas, não a impressões. Apresentámos o argumento completo, com as definições de classe de campanha e a matemática de receita por envio, em porquê a era dos 'blasts' acabou de terminar.
3. Segmentar o que ainda é transmitido. Alguns envios são legitimamente amplos — uma promoção em toda a loja, a notícia de última hora de um editor. 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 notificações push por visita de cada assinante defensável. A segmentação é agora um requisito de entregabilidade, não uma gentileza de personalização — essa publicação contém o caso completo de entregabilidade.
4. Aplicar um limite de frequência em todos os canais e sistemas. O período de 'cooldown' do Android 16 tornou isto concreto: o seu CRM, a sua camada transacional e o seu calendário promocional partilham um orçamento de atenção no dispositivo, quer partilhem ou não um painel de controlo. Defina um limite por assinante e horas de silêncio ao nível da plataforma, abrangendo notificações push web, notificações push de app e WhatsApp em conjunto, para que quatro sistemas razoáveis não possam compor um padrão abusivo. Isto 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. Corrigir o momento da permissão ('opt-in'). Mover o pedido de permissão para trás de uma ação que sinaliza intenção, usar um pedido em duas etapas para que o pedido ao nível do navegador só seja acionado com um 'sim', e aceitar a lista menor e mais limpa. A taxa de aceitação do pedido alimenta a pontuação do Chrome em ambas as extremidades — registo com UI discreta e avaliação do site disruptivo — e uma lista consentida é também simplesmente a lista que clica.
6. Fazer com que a cópia sobreviva a um classificador. Declarações diretas, urgência real apenas quando o prazo é real, identidade do remetente óbvia. No Android, um modelo de ML lê o seu título e corpo antes do utilizador. Copiar honesto foi sempre uma melhor prática de retenção; agora é também um requisito de entrega.
Se 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, horas de silêncio e atribuição de receita por notificação estão todos integrados, em planos que faturam apenas por assinantes ativos — o modelo de preços por acaso aponta na mesma direção que as plataformas agora impõem. O que nenhuma ferramenta pode fazer é decidir parar de enviar 'blasts'; essa parte é política, e é sua.
FAQ
Porque é que as minhas notificações push não estão a ser entregues em 2026? Verifique quatro suspeitos por ordem. Primeiro, a auto-revogação do Chrome: se o número de subscritores estiver a diminuir silenciosamente, os subscritores com baixo envolvimento podem estar a perder a permissão através da Verificação de Segurança. Segundo, limites de taxa do Chrome: se os envios para listas grandes demoram subitamente horas ou os registos do seu serviço push respondem com HTTP 429, é provável que tenha sido classificado como perturbador. Terceiro, apresentação Android: no Android 16, a entrega ainda acontece, mas os picos são silenciados e agrupados, e nos Pixels mais recentes, os pushes promocionais aterram num pacote silencioso — entregues, não vistos. Quarto, as causas aborrecidas que precedem a repressão: subscrições expiradas, erros do service worker e definições de notificação a nível do sistema operativo.
O Chrome baniu as notificações push? Não. O Chrome limita a taxa de sites que classifica como perturbadores (alto volume, baixo envolvimento) e revoga permissões que os utilizadores ignoram demonstrativamente. 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 aumentar.
Qual a taxa de envolvimento que me mantém a salvo da auto-revogação do Chrome? O Google não publicou limites e qualquer fornecedor que lhe cite um número seguro está a adivinhar. Os factos publicados: menos de 1% de todas as notificações recebem alguma interação, e a revogação visa a combinação de envolvimento muito baixo com alto volume de envio. A estratégia defensável é manter a sua taxa de cliques bem longe dessa linha de base e parar de enviar para subscritores que deixaram 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 envolvimento são medidos contra “um site”. Remetentes que usam uma plataforma push são avaliados com base no comportamento do seu próprio domínio, não no agregado do 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 nas notificações push no Android 16? Três coisas: arrefecimento de notificações (picos progressivamente silenciados por até um minuto, ativados por defeito, chamadas e alarmes isentos), agrupamento forçado das notificações de cada aplicação 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 num pacote recolhido silencioso por defeito. Mecânicas completas no nosso guia de arrefecimento do Android 16.
A repressão aplica-se ao iOS? As restrições da Apple datam principalmente de antes: o push web do iOS requer que o utilizador adicione o seu site ao seu Ecrã Principal, e a Diretriz 4.5.4 da App Store requer opt-in explícito mais um opt-out na aplicação 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 estão sujeitas a limites 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 dos utilizadores e em denúncias de spam; agentes com reputação baixa (incluindo todos os agentes novos) enfrentam limites no número de utilizadores ú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 na consola do programador 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 envio em massa com limites de taxa costumava competir pela mesma barra de notificações que você. As plataformas estão a fortalecer o canal para os remetentes para os quais o canal foi construído — e a afastar os restantes.
Última atualização e registo de alterações {#changelog}
Este hub é mantido como uma referência viva. Convenção: a data de "Última atualização" só muda para atualizações substanciais (uma plataforma a lançar, anunciar ou documentar uma alteração), não para edições de texto. Cada atualização substancial recebe uma linha no registo de alterações com uma fonte. Se estiver a citar esta página, cite-a com a sua data de última atualização.
- 2026-09-21 — Publicação inicial. Abrange: Limites de taxa da API Push do Chrome (janeiro de 2026), Revogação automática de permissões do Chrome (anunciada em outubro de 2025), Deteção de notificações por ML no dispositivo do Chrome (maio de 2025), Ciclo de arrefecimento + agrupamento forçado do Android 16 (junho de 2025), Organizador de Notificações QPR2 do Android 16 (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 em remetentes desconhecidos e marca de verificação do Google Messages (a partir de outubro de 2025).
Algo mudou e não registámos? A forma mais rápida de nos informar é através do widget de chat nesta página.
