A sua revisão de retenção de segunda-feira abre no mesmo gráfico de sempre. A retenção no Dia 1 mantém-se em cerca de 27%. O Dia 7 desceu para 8%. No Dia 30, menos de dois em cada cem jogadores ainda abrem a aplicação. As notificações push que enviou na semana passada obtiveram uma taxa de abertura respeitável e, ainda assim, a curva não se moveu. Essa lacuna, entre uma notificação que é clicada e um jogador que realmente volta e continua a jogar, é todo o problema de como a maioria dos estúdios usa notificações push para retenção de jogos.
Os números acima não são invulgares. Os benchmarks de jogos mobile de 2025 da GameAnalytics colocam a retenção mediana no Dia 7 entre 3,4% e 3,9%, com até os títulos do quartil superior a atingir cerca de 7–8%, e a retenção mediana no Dia 30 abaixo de 1%. O push é um dos poucos canais próprios que podem intervir antes que um jogador desça essa curva. Mas só funciona quando é construído como um conjunto de fluxos de trabalho acionados, ligados ao comportamento e receita dentro do jogo, e não como um calendário de envios em massa medidos por aberturas.
Este artigo apresenta essa abordagem: por que as aberturas são o placar errado, os quatro momentos do ciclo de vida que decidem se um jogador retorna, quatro fluxos de trabalho de notificações push que pode construir contra eles, a via push de app-mais-push de web que os seus concorrentes ignoram, e como atribuir cada notificação à receita dentro do jogo em vez de cliques.
- Por que a maioria das notificações push de jogos são abertas e ignoradas
- Retenção é um ciclo de vida, não um envio em massa: os quatro momentos que decidem se um jogador volta
- Quatro fluxos de trabalho de notificações push para retenção de jogos (gatilhos, tempo, critérios de saída)
- Push de app e push de web juntos: o canal que a SERP esqueceu
- Ligue cada notificação à receita dentro do jogo, não às aberturas
- A segmentação é o trabalho de retenção: progressão, gastos e recência
- O que o push não pode consertar, e o que ele realmente custa
Por que a maioria das notificações push de jogos são abertas e ignoradas
Uma abertura não é um retorno. Um retorno não é uma sessão. Uma sessão não é progressão. E a progressão é o que realmente prevê se um jogador ainda está por perto no Dia 30. Quando uma notificação gera um clique, mas o jogador sai da tela inicial, ou joga por quarenta segundos e sai, a curva de retenção não se importa que a sua taxa de abertura tenha sido de 22%.
Esta é a armadilha de medição em que quase todos os guias sobre notificações push de jogos caem. Eles otimizam o título, o emoji e a hora de envio para aumentar as aberturas, e depois relatam a taxa de abertura como a vitória. As aberturas são, na melhor das hipóteses, um indicador principal e, na pior, uma métrica de vaidade. O comportamento que você precisa é um jogador que retorna e atinge o próximo marco significativo.
O 'push can cue' que ativa esse comportamento. Não consegue fingir. Uma notificação pode colocar um jogador de volta em frente a um motivo para jogar: uma recompensa não reclamada, a vez de um amigo, uma barra de energia cheia, um evento limitado a terminar em breve. O que acontece a seguir é decidido pelo seu 'game loop'. Assim, o trabalho das notificações 'push' para a retenção de jogos é restrito e específico: entregar o motivo certo para voltar, ao jogador certo, no momento em que esse motivo é real, e depois medir se ele progrediu, não se clicou.
Retenção é um ciclo de vida, não um envio em massa: os quatro momentos que decidem se um jogador volta
As estratégias de retenção de jogadores que realmente funcionam disparam com base no comportamento, não no calendário. "Terça-feira às 18h para todos" é um disparo em massa. "Dispara no momento em que um jogador instala, mas não terminou o tutorial após 20 minutos" é um gatilho. Os gatilhos mapeiam para momentos do ciclo de vida, e quatro momentos fazem a maior parte do trabalho.
As estratégias de retenção de jogadores que se mapeiam para cada momento
| Momento do ciclo de vida | O sinal comportamental | O que está em risco |
|---|---|---|
| Primeira sessão | Instalado, mas o primeiro marco não atingido | O penhasco de 'churn' mais acentuado em toda a curva; a maioria dos jogadores que desistem, desistem aqui |
| Integração para o hábito | Jogou algumas vezes, ainda não formou rotina | O jogador nunca se torna regular; o Dia 7 colapsa |
| Hábito para leal | Joga regularmente, atinge uma sequência ou um muro de progressão | Um regular frustrado ou entediado deriva para o estado dormente |
| A escorregar para o estado dormente | Dias desde a última sessão a cruzar um limiar | O jogador desapareceu a menos que seja reativado; o custo total de readquisição avizinha-se |
Cada momento é um gatilho à espera de ser construído. O momento da primeira sessão é aquele que o resto da SERP trata como uma nota de rodapé, embora seja onde a maior parte da curva é perdida. Um jogador que não atinge uma primeira vitória nos minutos iniciais raramente volta por conta própria. Esse é um gatilho em tempo real, não um e-mail para o dia seguinte.
Quatro fluxos de trabalho de notificações push para retenção de jogos (gatilhos, tempo, critérios de saída)
Aqui estão quatro fluxos de trabalho que cobrem o ciclo de vida acima. Cada um é definido da forma como um operador de retenção o deve definir: um gatilho que o inicia, o tempo entre os toques, o trabalho da mensagem e a parte que quase todos os artigos concorrentes omitem, um critério de saída para que o jogador pare de ouvir um fluxo de trabalho assim que este tiver cumprido a sua função. Pode construir o fluxo de trabalho visualmente sem um ticket de engenharia, o que é importante quando as pessoas que gerem a retenção não são as mesmas que gerem a construção.
| Fluxo de trabalho | Gatilho | Cronometragem | Trabalho de mensagem | Critério de saída |
|---|---|---|---|---|
| Salvar a primeira sessão | Instalar sem primeiro marco | +20 min, +24 h | Puxar o jogador de volta para a primeira vitória que quase alcançou | Primeiro marco alcançado |
| Construtor de hábitos / guardião de sequências | 2+ sessões, sem rotina diária | Diariamente à hora habitual de jogo do jogador, máx. 1/dia | Proteger uma sequência, apresentar o motivo de abertura de hoje | Hábito formado (ex: 5 sessões em 7 dias) ou o jogador fica dormente → passa para a recuperação |
| Progressão e reentrada de recompensa | Recompensa não reclamada, energia reabastecida ou conteúdo novo | Baseado em eventos, dispara quando a razão se torna verdadeira | “A sua recompensa está à espera” / “A sua vez no jogo” | Recompensa reclamada ou conteúdo visualizado |
| Recuperação de jogador que está a desistir | 7–14 dias desde a última sessão | +7 dias, +14 dias, depois para | Oferecer uma razão específica para regressar, não culpa | Jogador regressa, ou o fluxo de trabalho termina (sem insistência interminável) |
Algumas notas que uma compilação real respeitaria. A poupança da primeira sessão é o fluxo de trabalho de maior impacto que possui, porque intervém na parte mais acentuada da curva; o seu primeiro contacto deve referenciar a coisa exata que o jogador estava prestes a receber, extraída dos seus próprios modelos de integração de notificações push. Uma poupança da primeira sessão é realmente uma notificação de boas-vindas com um prazo anexado.
O guardião da sequência tem de respeitar as horas de silêncio e um limite de frequência, ou torna-se a razão pela qual um jogador o silencia. O fluxo de trabalho de recuperação existe para reativar jogadores inativos antes que desapareçam para sempre. É deliberadamente curto aqui, dois contactos e uma paragem definitiva, porque a reativação profunda é uma disciplina própria; se quiser o design completo da sequência, veja como reativar jogadores inativos.
Exemplo de texto para a poupança da primeira sessão, segundo contacto: “Estava a duas jogadas de limpar o Nível 1. Ainda lá está quando quiser.” Sem ponto de exclamação, sem falsa urgência, uma referência concreta a onde o jogador parou realmente.
Push de app e push de web juntos: o canal que a SERP esqueceu
O que as notificações push de aplicações para jogos não conseguem alcançar
Todos os artigos concorrentes sobre este tópico assumem uma superfície de entrega: uma aplicação móvel a disparar notificações push de jogos através de FCM ou APNs. A maior parte da cobertura de notificações push de aplicações para jogos para por aí, numa única superfície. Essa suposição deixa os jogadores inalcançáveis. Os jogos não vivem apenas dentro de uma aplicação instalada.
Vivem em sites complementares onde os jogadores verificam tabelas de classificação, em compilações HTML5 e de navegador, em páginas de comunidade e notas de atualização, e em launchers de desktop. Um jogador que nunca instala a aplicação, ou que a desinstalou mas ainda visita o seu site, é invisível para uma pilha apenas de aplicações.
É aqui que a execução de notificações push web em conjunto com notificações push de aplicações para jogos muda a matemática. A opção de push web não é limitada por uma instalação na loja de aplicações, pelo que um visitante do seu jogo de navegador ou site complementar pode subscrever com um clique, e pode alcançá-lo novamente, quer ele descarregue ou não a aplicação. Considere um jogador que joga o seu jogo HTML5 no desktop no trabalho e nunca tocou na compilação móvel. O push da aplicação não o pode alcançar. O push web pode, com a mesma notificação "é a sua vez" que a aplicação envia.
O objetivo não é "usar duas ferramentas". É uma única identidade de subscritor, um único fluxo de trabalho e um único limite de frequência que abrange ambas as superfícies, para que um jogador que esteja ativo na aplicação não seja também contactado na web pelo mesmo evento. Essa orquestração entre canais próprios é o movimento que nenhum concorrente apenas de aplicações na primeira página de resultados consegue fazer.
Ligue cada notificação à receita dentro do jogo, não às aberturas
Um proprietário de retenção tem, eventualmente, de defender o canal junto de alguém que controla o orçamento. “O nosso impulso de reactivação obteve uma taxa de abertura de 19%” não sobrevive a essa conversa. “O nosso fluxo de trabalho de salvamento da primeira sessão devolveu 4.100 jogadores no mês passado, dos quais 1.300 atingiram o ponto de primeira compra, gerando 11.400$ em receita de compras no jogo” sobrevive.
A cadeia que precisa de instrumentar corre: notificação entregue → sessão iniciada → marco ou progressão atingida → compra no jogo ou impressão de anúncio → LTV de 30 dias. O rastreamento de objetivos ao nível da notificação fecha o ciclo, atribuindo a receita ao fluxo de trabalho específico e ao toque que a produziu, em vez de a notificações push como um bloco indiferenciado.
Assim que puder ver a receita por fluxo de trabalho, deixará de otimizar para aberturas e começará a cortar os toques que movem cliques mas não dinheiro, e a duplicar aqueles que movem LTV.
Tornar as notificações de compra dentro do jogo uma linha de receita rastreada
É assim também que as notificações de compra no jogo ganham o seu lugar. Rastreie as notificações de compra no jogo como o seu próprio fluxo de trabalho com rastreamento de objetivos associado, e a receita por toque deixa de ser um palpite. Uma mensagem “a sua recompensa está à espera” não é uma gentileza de retenção quando pode mostrar que devolveu jogadores que depois converteram. É uma linha de receita que pode atribuir, defender e escalar.
A segmentação é o trabalho de retenção: progressão, gastos e recência
Todos os guias dizem “segmente os seus jogadores”. Poucos dizem como, para um jogo. A versão de retenção do RFM é construída a partir de três eixos que já rastreia: nível de progressão, nível de gastos e recência (dias desde a última sessão). Cruzá-los e os fluxos de trabalho acima tornam-se mais precisos, de amplos a cirúrgicos.
Três segmentos compostos que vale a pena construir primeiro:
- Jogador de alto valor a deslizar. Nível de gastos superior, progressão profunda, 7+ dias desde a última sessão. Este é o seu jogador mais caro de perder e o mais barato de reconquistar, por isso direcione-o para uma reconquista priorizada com uma razão genuinamente valiosa para regressar, não um empurrão genérico.
- Desistente do tutorial. Instalado, nunca atingiu o primeiro marco, baixa recência. O salvamento da primeira sessão existe exatamente para este segmento; não desperdice mensagens de sequência numa jogadora que nunca começou.
- Casual de fim de semana. Progressão média, joga apenas sábado e domingo. Suprima os envios durante a semana e concentre o mantenedor da sequência na sua janela de jogo real.
A segmentação é o que impede que estas estratégias de retenção de jogadores se tornem ruído. O mesmo fluxo de trabalho que retém um jogador de baleia a deslizar incomodará um desistente do tutorial. O segmento decide em quem cada gatilho dispara, e acertar nisso é a maior parte da diferença entre um canal que os jogadores mantêm e um canal que eles silenciam.
O que o push não pode consertar, e o que realmente custa
O push amplifica um loop de jogo que vale a pena revisitar. Não o pode fabricar. Se os jogadores abandonam porque o loop principal é fraco, o pico de dificuldade é injusto, ou a monetização é hostil, nenhuma cadência de notificação manterá a curva, e enviar mais push para um jogo que os jogadores decidiram abandonar apenas acelera as desinscrições. A versão honesta das notificações push para retenção de jogos começa por aceitar que o push é um caminho de regresso, não uma razão para jogar.
Nesse sentido, a questão do custo é importante. Adquirir um novo jogador implica um custo de instalação completo: gastos com UA, taxas da loja, todo o funil. Reativar jogadores inativos custa uma fração disso, porque a relação e o canal já existem. O modelo de preços deve corresponder a essa lógica.
O PushEngage cobra apenas por assinantes ativos, pelo que quando um jogador fica inativo e deixa de ser contactado, a fatura encolhe em vez de crescer com uma lista à qual já não envia mensagens. Compare isso com a faturação por mensagem ou preços por tamanho de lista, e com as compensações do preço das notificações push do Firebase que os estúdios ponderam quando o volume de notificações push de aplicações para jogos aumenta.
Esse é o modelo em que o PushEngage opera: pague apenas por assinantes ativos.
Essa é a matemática da retenção numa só linha: o crescimento mais barato que um jogo tem é o jogador que já o instalou. Crie os quatro fluxos de trabalho, execute-os em notificações push de aplicações e web, segmente por progressão e gastos, e meça em receita. É assim que as notificações push para retenção de jogos deixam de ser um envio semanal e começam a mover a curva que abre todas as segundas-feiras.
Pronto para criar o seu primeiro fluxo de trabalho de recuperação na primeira sessão? Comece com o plano de pagar apenas por assinantes ativos e implemente-o esta semana.
