Todos os outros canais perdoam. Um e-mail ignorado fica parado na caixa de entrada. Uma mensagem in-app que perdeu o momento é fechada e esquecida. Uma notificação push que irrita alguém faz o canal inteiro ser desligado, para sempre, com um toque, numa tela do sistema operacional onde o seu produto não tem voz nem segunda chance.
Essa assimetria é a disciplina inteira. O push não é uma versão mais barulhenta das suas outras mensagens; é um pequeno orçamento de interrupções, não renovável, que o usuário concedeu a você, e o trabalho é gastá-lo apenas com coisas que valiam a interrupção.
Este guia mostra como a permissão realmente funciona, a regra de roteamento que separa o push das mensagens in-app, como é uma mensagem que recebe toques, com que frequência você pode enviar, o que medir e os padrões de falha que matam um programa de push em silêncio, muito antes de alguém perceber.
Principais aprendizados
- A permissão é de tiro único. Quem recusa o pedido do sistema praticamente sai do canal para sempre, então prepare o terreno antes de dispará-lo.
- A regra de roteamento: se pode esperar até a próxima sessão, não é push. É uma mensagem in-app ou um item do feed.
- Disparado por evento vence agendado. Uma mensagem enviada quando algo passou a ser verdade é relevante por construção.
- Limite a frequência por usuário, não por campanha. O usuário sente o total, não a estrutura das suas campanhas.
- Categorias vencem um botão único. Quem pode silenciar um tipo não silencia todos.
- A taxa de opt-out é o KPI de verdade. A taxa de toque mede a mensagem; o opt-out mede o estrago.
O que é, de fato, uma notificação push
Notificação push: definição
Uma notificação push é uma mensagem exibida pelo sistema operacional fora do seu produto (na tela de bloqueio, na central de notificações ou como banner no desktop) e entregue com o app aberto ou não. No celular, ela passa pelo serviço de push da plataforma; na web, exige um service worker e uma permissão explícita. O que a define é o modelo de permissão, não o formato: concedida uma vez, revogável com um toque e raramente reconsiderada.
Dessa definição saem duas consequências, e a maioria dos erros com push vem de não levá-las a sério:
O destinatário está numa reunião, no metrô ou dormindo. Nada sobre o momento pode ser presumido, e é por isso que a relevância tem que vir de um evento, não de uma agenda.
Os usuários não respondem "por favor, pare". Eles desativam as notificações, e você perde todas as mensagens futuras, inclusive as realmente urgentes. Não existe fluxo de recuperação para isso.
Push vs mensagens in-app: a decisão de roteamento
A maioria dos times não tem um problema de push. Tem um problema de roteamento: mensagens que pertenciam ao produto foram enviadas como push porque o push parecia mais importante. A distinção é simples e se sustenta sob pressão.
Só o quadrante superior esquerdo justifica gastar a permissão.
A metade in-app deste diagrama é onde a maior parte das mensagens de um SaaS realmente pertence, e ela é tratada em detalhe nos nossos guias de mensagens in-app e de notificações in-app e feeds. O push é o canal estreito no topo; ele deve parecer estreito.
O teste que encerra discussões: esta mensagem valeria um colega tocar no ombro do destinatário? Se não, também não vale uma interrupção na tela de bloqueio, por mais importante que pareça no calendário de campanhas.
O problema da permissão: conquistar o opt-in
Tudo o que vem depois depende de uma única caixa de diálogo que você não pode estilizar, não pode testar em A/B e, na prática, não pode mostrar duas vezes. Pedi-la no primeiro acesso, antes de o usuário saber o que o seu produto faz, quanto mais o que você enviaria, é o padrão mais caro da categoria.
O padrão que funciona é um opt-in em duas etapas: primeiro a sua própria mensagem, e o pedido do sistema só para quem já disse sim.
A etapa de preparação é repetível e gratuita. O pedido do sistema não é nenhuma das duas coisas.
Três detalhes fazem a etapa de preparação funcionar:
-
Peça num momento que prove o valor
Logo depois de o usuário fazer algo cujo resultado ele vai querer saber: iniciar uma tarefa demorada, configurar um alerta, convidar um colega. O pedido se explica sozinho, e esse é o único argumento que funciona de forma confiável.
-
Diga exatamente o que você vai enviar
"Vamos avisar quando uma exportação terminar" conquista um sim. "Ative as notificações para ficar por dentro" conquista um não, porque o usuário entende, com razão, que é uma permissão para enviar qualquer coisa, para sempre.
-
Ofereça categorias, não um botão único
Alertas, menções, novidades do produto. Quem pode desligar a categoria barulhenta mantém a útil. Um botão de tudo ou nada transforma uma campanha ruim numa perda total.
As mensagens de preparação são mensagens in-app comuns, disparadas por comportamento, ou seja, o mesmo mecanismo dos gatilhos de onboarding; a única diferença é aonde o sim leva.
A etapa de preparação fica dentro do produto, onde você controla o texto e pode pedir de novo mais tarde.
Anatomia de um push que recebe toques
Uma notificação push é lida em cerca de um segundo, na tela de bloqueio, cortada. A restrição é tão dura que a estrutura é praticamente fixa:
| Parte | Função | Regra prática |
|---|---|---|
| Título | Dizer o que aconteceu | Comece pelo substantivo. Considere invisível tudo o que vier depois de uns quarenta caracteres. |
| Corpo | Acrescentar o único detalhe que decide se é preciso agir agora | Quem, o quê, quanto. Não uma segunda frase de persuasão. |
| Deep link | Levar à coisa em si, não à tela inicial | Um toque que cai num dashboard desperdiçou a notificação. |
| Ações | Deixar o usuário concluir sem abrir o app | Aprovar, adiar, marcar como lida, só quando a ação é realmente de uma etapa. |
✅ Assim
- "Dana aprovou sua solicitação de orçamento"
- "Exportação pronta: 4.812 linhas"
- "A sincronização noturna falhou às 02:14"
- "3 pessoas responderam ao seu comentário"
❌ Não assim
- "Você tem uma nova notificação"
- "Não perca as novidades desta semana!"
- "👋 Quanto tempo! Que tal voltar?"
- "Atualização importante sobre a sua conta" (sobre nada importante)
Repare no que a coluna da esquerda tem em comum: cada exemplo nomeia uma coisa específica que mudou. Esse é o ofício inteiro. Uma notificação é um fato, não um argumento de venda, a mesma disciplina que separa uma boa microcopy de UX de texto de enchimento.
Timing, frequência e horários de silêncio
O maior ganho disponível no push não está no texto. Está em trocar campanhas agendadas por gatilhos de evento: enviar porque algo passou a ser verdade, e não porque chegou a terça-feira.
- Dispare no evento. Uma tarefa concluída, uma menção, um limite ultrapassado, uma aprovação pendente. A relevância é estrutural, não editorial.
- Use o fuso horário do destinatário. Não o do seu escritório. Um envio agendado que respeita o horário local é uma mensagem diferente do mesmo envio às 3 da manhã.
- Mantenha horários de silêncio. Envios de madrugada geram opt-outs, não aberturas, e para o que for realmente urgente o usuário geralmente já configurou um alerta.
- Limite por usuário, não por campanha. Três campanhas que "só enviam duas vezes por semana" são seis interrupções para quem está do outro lado.
- Agrupe o que puder ser agrupado. Cinco comentários no mesmo documento são uma notificação, não cinco. Agrupar é a boa vontade mais barata do canal.
- Em B2B, prefira o horário comercial. Os benchmarks de consumo sobre picos à noite não se aplicam a um software que as pessoas usam no trabalho.
Uma correção estrutural vale mais do que uma dúzia de experimentos de ajuste: um limite de frequência aplicado por usuário em todas as campanhas, com um único responsável. Sem isso, cada time otimiza sua própria agenda de envios e o usuário sente a soma, que ninguém está medindo.
O que medir
Por padrão, as análises de push mostram números lisonjeiros. Estes são os que realmente dizem algo:
Parcela dos usuários elegíveis que concederam a permissão, separada por onde você pediu. É aqui que a preparação se prova, e é o teto de todo o resto.
Concedidos menos revogados, desinstalados e tokens expirados. A diferença entre "inscritos" e usuários alcançáveis costuma ser bem maior do que os times imaginam.
Por tipo de notificação, nunca misturada. Um único alerta transacional pode sustentar a média do programa inteiro enquanto todas as campanhas abaixo dele são ignoradas.
O toque levou à ação que a notificação sugeria? Uma taxa de toque alta que termina num beco sem saída é um resultado pior do que ser ignorado.
O número mais importante do push, e o que mais falta nos dashboards. Acompanhe por campanha e por semana em relação ao volume.
O número que o destinatário realmente sente. Envios subindo com resultados estáveis é a assinatura de um canal sendo queimado.
Leia essas métricas junto com o restante do seu quadro de engajamento, e não num dashboard só de push; a abordagem do nosso guia de métricas de engajamento de usuários se aplica diretamente, e o caso de reengajamento tem suas próprias sutilezas, tratadas em como reconquistar usuários inativos.
Seis formas como programas de push morrem
-
Pedir no primeiro acesso
A permissão é gasta antes de o produto ter demonstrado qualquer coisa. Tudo o que vem depois fica limitado por essa única decisão, e ela não pode ser refeita.
-
Tratar o push como canal de marketing
Calendários de campanha geram envios tenha acontecido algo ou não. O canal deriva de "algo que você precisa saber" para "algo que precisamos que você veja", e os usuários reagem de acordo.
-
Ninguém responsável pela frequência
Três times enviando "só umas duas por semana" cada um produzem um fluxo que ninguém desenhou. A frequência precisa ser limitada de forma central, por usuário, ou ela não está limitada.
-
Preferências de tudo ou nada
Sem categorias, uma única campanha irrelevante custa todas as notificações futuras para aquele usuário, inclusive as transacionais em que ele realmente confia.
-
Deep links que não levam a lugar nenhum
Tocar em "Dana aprovou sua solicitação" e cair numa tela inicial ensina ao usuário que tocar não vale a pena. É a forma mais rápida de treinar uma base inteira a ignorar você.
-
Nunca medir o opt-out
A taxa de toque entra no relatório; silenciamentos e revogações, não. O programa parece estável até o momento em que o público alcançável caiu pela metade em silêncio, e aí já não há como recuperar.
Fazendo direito a metade in-app
Passe pela matriz de roteamento com honestidade e a maior parte da lista de mensagens sai do push: anúncios de funcionalidades, orientação de onboarding, dicas, pesquisas, itens do changelog, empurrões para uma configuração inacabada. Elas pertencem ao lugar onde o usuário já está trabalhando, e são as mensagens que mais fazem pela adoção, porque chegam com a interface a que se referem ali mesmo, na tela.
Essa é a metade que o Kompassify cobre: anúncios in-app, tooltips, checklists e pesquisas, segmentados por perfil e comportamento, criados num editor visual em vez de num release. Inclusive a mensagem de preparação que conquista a permissão de push, para começo de conversa, e os anúncios de funcionalidades que nunca deveriam ter ido parar numa tela de bloqueio.
Tudo o que pode esperar pela próxima sessão pertence a este lugar, não à tela de bloqueio.
Envie menos, acerte mais
O Kompassify permite que times de produto, onboarding e customer success cuidem da metade in-app: anúncios, guias, checklists e pesquisas, segmentados por perfil, com dados de adoção de cada um e sem ticket para a engenharia. Grátis até 100 usuários ativos mensais, planos a partir de $129/mês, em conformidade com o GDPR e hospedado na UE.
Comece grátis →A versão em uma frase
O push é uma permissão finita, então prepare o terreno antes de pedi-la, gaste-a apenas com mensagens que sejam ao mesmo tempo urgentes e pessoais, limite a frequência por usuário e não por campanha, e envie todo o resto in-app, onde a mensagem chega com o contexto que a torna útil.
Perguntas frequentes
O que é uma notificação push?
Uma notificação push é uma mensagem que o sistema operacional exibe fora do seu produto, na tela de bloqueio, na central de notificações ou como banner no desktop, entregue com o app aberto ou não. No celular, ela chega pelo serviço de push da plataforma; na web, exige um service worker e uma permissão explícita. O que a define não é o formato, mas o modelo de permissão: o usuário concede o acesso uma vez, pode revogá-lo para sempre com um toque e raramente volta atrás. Isso faz do push o único canal de mensagens em que um mês ruim custa o próprio canal, e não apenas uma mensagem ignorada.
Qual é a diferença entre notificações push e mensagens in-app?
O push alcança usuários que não estão no seu produto; as mensagens in-app alcançam quem está. Essa única diferença decide todo o resto. O push interrompe o dia de alguém, então precisa valer a interrupção e tratar de algo urgente ou pessoal: uma aprovação pendente, uma tarefa concluída, uma conta em risco. As mensagens in-app chegam quando o usuário já está no contexto, então podem ensinar, anunciar e guiar, e não custam nada em permissão. A regra de roteamento que mantém os times honestos: se a mensagem pode esperar até a próxima sessão, ela não é um push.
Como aumentar a taxa de opt-in de notificações push?
Não peça no primeiro acesso. Na prática, o pedido de permissão do sistema só pode ser exibido uma vez, e quem recusa praticamente sai do canal para sempre. Prepare o terreno: espere um momento em que as notificações claramente beneficiam o usuário, como quando ele acabou de convidar um colega, iniciou uma tarefa demorada ou configurou um alerta. Depois mostre sua própria explicação in-app dizendo exatamente o que você vai enviar e com que frequência, e só dispare o pedido do sistema para quem disser sim ali. Ofereça categorias granulares em vez de tudo ou nada e deixe as configurações fáceis de achar, porque quem pode silenciar um tipo não silencia todos.
Qual é o melhor horário para enviar notificações push?
O melhor horário é o momento em que a mensagem passou a ser verdade, não um espaço no calendário. Notificações disparadas por eventos (o relatório ficou pronto, a aprovação chegou, o deploy falhou) superam campanhas agendadas porque são relevantes por construção. Quando você agendar, respeite o fuso horário local do destinatário, não o seu, mantenha horários de silêncio durante a noite e limite o número de envios por usuário por semana, não por campanha, já que o usuário sente o total, não a estrutura das suas campanhas. Para software B2B, o horário comercial no fuso do destinatário é um padrão muito melhor do que os picos noturnos citados em benchmarks de consumo.
Quantas notificações push são demais?
A resposta honesta depende de cada produto, não de um número universal, e ela é descoberta pelas taxas de opt-out, não escolhida de antemão. Acompanhe a parcela de usuários que desativam as notificações a cada semana em relação a quantos envios receberam, e você verá o ponto em que a curva se dobra. Esse é o seu teto, e ele costuma ser mais baixo do que o marketing espera. Duas regras estruturais ajudam mais do que qualquer número: limite a frequência por usuário, não por campanha, e separe categorias para que as pessoas possam silenciar o tipo barulhento sem silenciar o útil.
Notificações push funcionam para SaaS B2B?
Para um conjunto restrito de mensagens, sim: tudo o que for realmente urgente e pessoal, como uma aprovação que trava o trabalho de outra pessoa, uma tarefa que falhou ou um alerta que o próprio usuário configurou. Para todo o resto, produtos B2B costumam se dar melhor com mensagens in-app e um feed de notificações, porque a atenção do usuário já está dentro do produto no horário de trabalho e o orçamento de interrupções é gasto pelos colegas dele, não por você. Anúncios de funcionalidades, orientações de onboarding e conteúdo educativo quase nunca justificam um push; justificam uma mensagem exibida na próxima vez que o usuário estiver no produto, onde você também pode mostrar o que fazer em seguida.