A sua aplicação envia três notificações num minuto e o telemóvel do jogador mostra-lhes um único banner. Isto não é um erro no seu fornecedor de push. É o cooldown de notificações do Android, ativado por defeito no Android 16, e reescreve silenciosamente as regras para todos os remetentes de alto volume. Se envia notificações push para uma aplicação de apostas ou jogos, os seus momentos mais valiosos são exatamente aqueles que ele visa: um golo, uma alteração nas odds e um prompt de levantamento de dinheiro chegam nos mesmos sessenta segundos. Este post cobre o que o cooldown faz, os limites de taxa do FCM que já existiam por baixo dele, e os padrões de design de envio que mantêm a sua aplicação ouvida.
O que o cooldown de notificações do Android faz a uma rajada
O Android 16 atingiu a versão estável a 10 de junho de 2025, e o cooldown de notificações foi lançado com ele, ativado por defeito. O comportamento foi documentado pela primeira vez nas pré-visualizações para programadores do Android 16 no final de 2024, quando ainda era uma opção de ativação. Na versão estável, o Google ativou-o para todos.
A mecânica é simples. Quando uma aplicação envia uma rajada de notificações, a primeira alerta normalmente, com volume total, com um banner completo. Cada notificação subsequente na rajada é progressivamente reduzida em volume e minimizada visualmente, durante até um minuto, e a rajada é agrupada sob um único banner. Nada é apagado. As notificações ainda chegam, ainda ficam na bandeja, ainda contam nos seus relatórios de entrega. Simplesmente deixam de exigir atenção.
Este último ponto é importante para a forma como lê os seus painéis. A taxa de entrega não se moverá. O que se move é tudo o que está a jusante da atenção: visualizações, cliques e as conversões que os seus segundos e terceiros envios deveriam impulsionar.
Notificações do Android 16: o que ainda alerta, o que é silenciado
O cooldown não trata todas as notificações do Android 16 da mesma forma. Chamadas, alarmes e conversas prioritárias estão isentas; alertam normalmente, não importa quão rápido se acumulem. Todo o resto está sujeito à curva de silenciamento, e isso abrange todas as notificações de aplicações de apostas, tanto de marketing como transacionais.
Uma nota de aplicabilidade, e é uma inferência em vez de uma declaração documentada da plataforma: o cooldown opera na camada de notificação, pelo que, por mecanismo, deve aplicar-se tanto a notificações push de aplicações entregues via FCM como a notificações push web que o Chrome renderiza no Android. Se a sua marca tem uma aplicação e um site móvel, trate as notificações do Android 16 de ambos os canais como partilhando um orçamento de atenção no mesmo dispositivo.
Os limites de taxa do FCM já o estavam a limitar
O tempo de espera é a camada visível. Por baixo, o Firebase Cloud Messaging impõe há anos limites de envio por dispositivo. A documentação do FCM define os limites em 240 mensagens por minuto e 5.000 por hora para um único dispositivo, e alerta que remetentes que operam perto desses limites correm o risco de a aplicação ser sinalizada como abusiva.
Nenhuma campanha sensata envia 240 mensagens por minuto para um utilizador. Mas estes limites do FCM são por dispositivo, não por campanha, o que significa que cada sistema que executa envia contra o mesmo orçamento partilhado: o seu CRM, os alertas de odds do seu motor de negociação, o seu agendador de promoções, a sua camada transacional. Uma arquitetura onde quatro sistemas se comportam de forma razoável pode ainda assim produzir um padrão a nível de dispositivo que é interpretado como abuso pelo FCM e como um pico no tempo de espera.
Os dois mecanismos acumulam-se. Os limites do FCM limitam o que pode fisicamente chegar; o tempo de espera da notificação do Android decide quanto do que chega é notado. Remetentes de alto volume agora projetam contra ambos simultaneamente.
Por que as notificações de aplicações de apostas disparam em primeiro lugar
As aplicações de apostas disparam não porque as equipas de CRM são descuidadas. Disparam porque os melhores momentos do produto são inerentemente simultâneos. Um golo num jogo seguido é, no mesmo instante, um alerta de resultado, um movimento de odds e uma oportunidade de levantamento. Três sistemas diferentes controlam cada uma dessas mensagens, e nenhum deles verifica o que os outros dois acabaram de enviar.
Aqui está o pico como o telemóvel do jogador o experiencia sob o tempo de espera:
| Tempo | Sistema | Notificação | O que o jogador experiencia |
|---|---|---|---|
| 0:00 | CRM / feed de eventos | “GOLO. 1–0 no jogo que está a seguir” | Alerta completo: som, vibração, banner |
| 0:15 | Motor de negociação | “Odds alteradas no mercado do próximo golo” | Silenciado: volume reduzido, minimizado, agrupado |
| 0:40 | Motor de promoções | “Levantamento agora disponível na sua aposta aberta” | Ainda mais silenciado: quase sem som, colapsado no grupo |
A parte dolorosa é a ordem. O pedido de levantamento, a única notificação nesse pico com receita direta associada, é a que o tempo de espera enterrou, porque chegou em terceiro. Quem envia primeiro, domina o minuto. Neste momento, na maioria das pilhas de notificações de aplicações de apostas, o vencedor é qualquer sistema que tenha a menor latência, não a mensagem que mais importa.
A sequência de push do dia do jogo sempre precisou de sequenciamento deliberado. O tempo de espera transforma isso de arte em requisito.
Padrões de design que sobrevivem a picos de notificações push
Não pode desativar o tempo de espera para os seus utilizadores, e não deveria querer fazê-lo; pune exatamente o padrão que os seus jogadores já ressentiam. A correção é arquitetónica. Quatro padrões impedem que os picos de notificações push consumam o seu alcance.
Espaçar envios por minutos, não segundos
A janela de tempo de espera dura até um minuto. Quaisquer duas notificações que controle e que cheguem dentro dessa janela competem por um alerta. Portanto, imponha um intervalo por subscritor medido em minutos entre mensagens distintas, e imponha-o em todo o lado, incluindo o caminho transacional que a maioria das equipas esquece de contar. Um alerta de golo às 0:00 e um pedido de levantamento às 2:30 alertam ambos normalmente. O mesmo par com trinta segundos de diferença é um alerta e um fantasma.
Atribua um único proprietário ao envio em rajada
Para cada momento previsível, decida antecipadamente qual notificação o possui. Quando um golo acontece, o alerta de pontuação, a alteração das odds ou o prompt de levantamento é acionado? Escolha um, geralmente o mais próximo da receita ou aquele a que o jogador se subscreveu explicitamente, e suprima ou atrase os restantes. Níveis de prioridade superam sistemas de corrida.
Colapse as atualizações numa única notificação
O rastreamento de odds é o infrator clássico: cinco alterações de odds não devem ser cinco notificações. Use a substituição de mensagens, onde o novo payload atualiza a notificação existente na bandeja em vez de empilhar uma nova. O FCM suporta o comportamento de colapso há anos. Uma notificação de odds ao vivo e continuamente atualizada nunca aciona o cooldown, e é vista como uma funcionalidade em vez de ruído.
Atrasar a distribuição por segmento
Um envio para 500.000 subscritores que sai numa única onda produz picos a nível populacional também, colidindo com qualquer outra coisa que os seus sistemas enviem nessa janela. Divida a distribuição em ondas de segmentos: apostadores ao vivo no jogo seguido primeiro, depositantes recentes a seguir, segmentos mais frios minutos depois ou nem por isso. O seu modelo de segmentação de jogadores já define as ondas; a distribuição apenas precisa de as respeitar.
O limite de frequência de notificações e as horas de silêncio completam o trabalho
Os quatro padrões acima corrigem o minuto. O limite de frequência de notificações corrige o dia e a semana. O cooldown é a aplicação pelo Google, ao nível do sistema operativo, de uma disciplina que os melhores remetentes já impuseram a si mesmos, e não será o último mecanismo de aplicação. Defina limites internos por subscritor por dia e por semana, e escale-os por calor do segmento:
| Segmento | Máx./dia | Máx./semana |
|---|---|---|
| Ativo nos últimos 7 dias, segue eventos ao vivo | 3–4 em dias de jogo | 10–12 |
| Ativo nos últimos 7 dias, ritmo de casino | 2 | 8–10 |
| A desvanecer-se, 8–20 dias de silêncio | 1 | 3–4 |
| Inativo, 21+ dias | — | 1, depois reativar ou suprimir |
As horas de silêncio são o limite rígido abaixo dos limites: defina uma janela de não incomodar e não deixe que nada de marketing a atravesse. Neste vertical, o limite de frequência de notificações é também proteção do jogador, não apenas higiene de entrega. Limites, horas de silêncio e uma regra estrita de não urgência em prompts de depósito são a mesma prática vista de dois ângulos, e os operadores que mantêm essa linha dão aos jogadores uma razão para manter as notificações ativadas. O manual de retenção para sites de apostas cobre toda a pilha de higiene.
Construir a disciplina de espaçamento no PushEngage
Cada padrão acima é construível no PushEngage Workflows hoje, sem infraestrutura de envio personalizada. Sites de apostas e jogos no PushEngage enviaram mais de 3,5 mil milhões de notificações, e os controlos de modelação de envio existem porque os remetentes nesse volume precisam deles.
Nós de espera, disponíveis nos planos Business e superiores, são a unidade primitiva de espaçamento: insira uma espera de minutos, horas ou dias entre quaisquer dois envios num fluxo de trabalho, para que nenhuma sequência que desenhe possa sobrecarregar um assinante. Nós de decisão e critérios de saída, nos mesmos planos, são como um fluxo de trabalho verifica o estado antes de disparar, que é como se parece na prática "atribuir o proprietário de sobrecarga única": se a mensagem de prioridade mais alta já foi enviada, saia em vez de acumular.
As horas de silêncio são configuradas por fluxo de trabalho com uma opção de fallback à sua escolha: pular o envio completamente, ou reagendá-lo para um minuto após o fim da janela, resolvido no fuso horário de cada assinante. Use reagendar para ofertas com prazo de validade e pular para alertas vinculados a momentos; uma notificação de pontapé inicial entregue às 09:01 é ruído. O agendamento ciente do fuso horário também lhe dá um leque segmentado sem scripts, já que as ondas podem sair na hora local em vez de como um único disparo global.
Duas capacidades situam-se mais acima na escada de planos: caminhos de divisão A/B dentro de um fluxo de trabalho começam no Premium, e gatilhos de eventos personalizados e webhooks, as peças que permitem que os eventos do seu motor de negociação ou carteira iniciem um fluxo de trabalho diretamente, começam no Growth. Se estiver a mapear a configuração completa do lado da aplicação, comece com notificações push para aplicações de apostas, o guia pilar para esta série.
O Chrome está a jogar a mesma jogada na web
Se também enviar notificações push web, a mesma lógica de envolvimento agora fiscaliza esse canal. Desde janeiro de 2026, o Chrome pontua diariamente cada origem de envio nas notificações push em relação ao tempo que os utilizadores realmente passam no site, e limita os remetentes que classifica como disruptivos. Mecanismo diferente, mensagem idêntica: as plataformas agora medem a atenção, e os remetentes que visam utilizadores envolvidos mantêm o seu alcance enquanto os sobrecarregadores o perdem. A versão do lado da web desta história, e a arquitetura de segmentação que responde a ela, é abordada em porquê a segmentação é agora um requisito de entregabilidade.
O que mudar antes do seu próximo dia de jogo
Três movimentos, em ordem. Primeiro, audite os envios do mês passado para rajadas de notificações push no mesmo dispositivo: extraia qualquer assinante que recebeu duas ou mais notificações num minuto, identifique quais sistemas colidiram e anote com que frequência a notificação enterrada foi aquela com receita associada. Segundo, atribua a cada momento previsível uma única notificação proprietária e rebaixe as restantes para atualizações colapsadas ou seguimentos atrasados. Terceiro, mova todas as sequências recorrentes para fluxos de trabalho com nós de espera, limites de frequência e horas de silêncio, para que o espaçamento seja imposto pela plataforma em vez da memória da equipa.
O período de arrefecimento das notificações do Android não lhe retirou o alcance. Retirou a ilusão de que três notificações num minuto eram três oportunidades para ser visto. Os remetentes que espaçam, priorizam e colapsam alertarão com volume total, enquanto os disparos dos seus concorrentes colapsam num grupo silencioso. Se pretende os controlos de modelação de envio sem os construir, as notificações push de aplicações no PushEngage vêm com nós de espera, horas de silêncio e agendamento por fuso horário em todos os níveis de planos pagos, apoiadas por uma garantia de devolução do dinheiro em 14 dias.
