Quando uma notificação push traz o jogador de volta — e quando ela só é deslizada para descartar?
A maioria das equipes trata o push como um problema de redação: escreva um copy melhor, envie mais, veja a taxa de abertura subir. Esse enquadramento está errado. O push é um problema de tempo e direcionamento disfarçado de redação, e quase todo mini-jogo envia demais porque a única métrica no painel é a abertura. Isto é o que realmente decide se uma notificação conquista uma sessão ou uma desinstalação.
Q: Por que a maioria das campanhas de push falha em silêncio mesmo com a taxa de abertura saudável?
Porque a taxa de abertura mede a coisa errada. O jogador que abre sua notificação às 9h provavelmente já abriria o jogo às 9h —você creditou a si mesmo um retorno que não causou. O que importa é o retorno incremental: segmento notificado menos um holdout que não recebeu nada. Rode essa comparação e um número surpreendente de pushes "bem-sucedidos" mostra um lift perto de zero. A segunda falha é o horário de envio. Uma notificação entregue às 3h local —porque seu servidor roda em UTC— é deslizada, não tocada, e treina o jogador a ignorá-lo. A terceira, e a que ninguém quer ouvir: a notificação não é o produto. Se o deep link joga o jogador numa tela inicial genérica em vez da missão exata que ele deixou pela metade, você gastou o capital de atenção e o converteu em nada.
Q: Quando você envia realmente, e para quem?
Quase nunca envia para todos. Segmente por estado do ciclo de vida, porque um jogador D2 e um dormente D40 precisam de mensagens opostas. A coorte inicial (D1–D3) recebe dicas de onboarding —mas só os que travam, não os já viciados. O segmento dormente (D14+) é onde o push justifica seu custo e onde você ganha desinstalações, então é o que mais precisa de contenção. Use uma lente RFM-lite: recência da última sessão, frequência antes de cair e o valor que deixaram na mesa —uma missão inacabada, um saldo, uma sequência prestes a expirar. Dispare por comportamento quando puder; envios de calendário são o padrão preguiçoso e se notam. E respeite as horas de silêncio locais por fuso, não as do seu escritório.
Q: Como você evita a fadiga que dispara uma desinstalação?
A fadiga é cumulativa e invisível até que opt-outs e desinstalações disparam —quando você vê, já pagou. O bug estrutural é que cada equipe possui um gatilho e ninguém possui o total. Uma campanha limita a duas por semana; outros três times limitam a duas cada; o jogador recebe seis. Você precisa de um teto global de frequência, por usuário por semana, num único lugar. Depois divulgação progressiva: comece suave e escalone só com sinais de alta intenção. E meça a desinstalação atribuível ao push —a maioria dos painéis não tem isso, então as equipes seguem enviando além do limite para uma fuga que não enxergam. Se não isola esse número, você opera a alavanca mais destrutiva vendado.
Q: Como é um programa de push que realmente move a retenção?
Um experimento controlado, não um boletim. Mantenha 5–10% dos usuários de fora para sempre e observe o retorno incremental D7 e D30 contra eles; mate qualquer gatilho que não supere o holdout. Os deep links aterrissam no meio do loop, nunca na inicial. Copy e horário de envio localizados, não traduzidos e esquecidos. E a parte desconfortável para um mini-jogo casual: a maior alavanca de retenção quase sempre é o próprio design do loop do jogo —o próximo passo a fazer—, não o CRM. O push é um imposto que você paga a um balde com vazamento, não o conserto. Gaste o primeiro dólar no loop; gaste o push nos jogadores que o loop já ganhou mas que se desviaram.
| Tipo de gatilho | Retorno incremental | Risco de fadiga | Quando vale a pena |
|---|---|---|---|
| Dica onboarding (só travados) | médio | baixo | D1–D3, por comportamento |
| Lembrete corte de hábito | alto | médio | D5–D10, antes da sequência |
| Recuperação dormente | alto | muito alto | D14+, teto estrito |
| Envio em massa / calendário | ~zero | alto | quase nunca |
