Abra quase qualquer produto B2B e você vai encontrar um sino no canto superior direito com um número vermelho. Clique nele e aparecem um comentário de um colega, quatro mensagens automáticas de status, uma promoção de um plano que você já assina e alguma coisa de março. O número some. Ninguém aprendeu nada. Na semana seguinte o número volta, e a essa altura ninguém mais olha.
As notificações in-app são uma das poucas superfícies de produto que podem cair a valor zero enquanto continuam parecendo perfeitamente saudáveis em um dashboard. O feed continua sendo aberto, porque o badge exige. O badge continua sendo zerado, porque incomoda. Nenhum desses dois fatos significa que alguém leu alguma coisa.
Este guia trata especificamente da camada de notificações: a parte persistente, endereçada e consultada pelo usuário da sua comunicação in-app. As mensagens em massa que interrompem (modais, banners, slideouts, tooltips) são outro sistema, com outras regras, tratado no nosso guia de mensagens in-app. Saber qual dos dois você está construindo já resolve a maior parte do problema de design.
Principais pontos
- Notificações são endereçadas e persistentes; mensagens são em massa e interrompem. Misturar as duas é o que destrói o feed.
- Quatro categorias pertencem ao feed: pessoal, fluxo de trabalho, sistema e novidades relevantes do produto. Todo o resto é marketing fantasiado de sininho.
- O badge é uma promessa. Um número que nunca chega a zero ensina os usuários a ignorá-lo para sempre.
- Agrupe por objeto ou por dia. Cinco eventos sobre o mesmo documento são uma notificação, não cinco.
- Escreva na ordem autor, ação, objeto, transforme o item inteiro em link para o destino exato e mostre um horário relativo.
- A taxa de silenciamento é a métrica honesta. A taxa de clique continua boa até o momento em que as pessoas desligam a categoria.
O que são, de fato, notificações in-app
Notificação in-app, em um parágrafo
Uma notificação in-app é uma mensagem entregue dentro do seu produto a um usuário específico sobre algo que aconteceu ou que precisa da atenção dele. Normalmente ela fica em uma central de notificações permanente, aberta por um ícone de sino, tem estado de lida/não lida e continua disponível até que o usuário cuide dela. As propriedades que a definem são ser endereçada, ou seja, diz respeito a esta pessoa, e persistente: ela espera em vez de interromper, e o usuário escolhe quando olhar.
Três superfícies são confundidas o tempo todo, e a distinção não é acadêmica: ela determina onde uma comunicação deve ficar e quais regras se aplicam a ela.
| Notificação in-app | Mensagem in-app | Notificação push | |
|---|---|---|---|
| Público | Um usuário, endereçado pessoalmente | Um segmento, em massa | Um usuário, fora do produto |
| Entrega | Espera no feed, o usuário consulta | Aparece na tela, interrompe | No sistema operacional, exige permissão |
| Duração | Persistente até ser lida ou apagada | Exibida uma vez, depois some | Passageira, muitas vezes perdida |
| Uso típico | Comentário, aprovação, tarefa concluída, novidade relevante | Etapa de onboarding, anúncio, pedido de ação | Trazer de volta um usuário inativo |
| Principal risco | Virar ruído que ninguém lê | Interromper na hora errada | Permissão negada ou desinstalação |
A regra de roteamento. Se o usuário precisa ver agora para a tela atual fazer sentido, é uma mensagem. Se ele precisa de um registro e pode agir depois, é uma notificação. Se não é nenhum dos dois, se é algo que você quer que ele saiba e não algo de que ele precisa, provavelmente o lugar é o seu changelog e mais nenhum.
Dois modelos de entrega: interromper e caixa de entrada
Todo sistema de notificações precisa escolher, item por item, entre exigir atenção agora e esperar ser encontrado. A maioria dos produtos se complica quando joga tudo, por padrão, em um dos dois.
Interromper (empurrado para a tela)
- Toast, snackbar ou um banner que aparece no lugar
- Ideal para: algo que acabou de acontecer como resultado da ação do próprio usuário, ou algo urgente
- Custo: atenção, imediata e inegociável
- Limite: poucos por sessão antes de parecer um caos
Caixa de entrada (espera no feed)
- Central de notificações atrás de um sino, com estado de leitura e histórico
- Ideal para: tudo o que o usuário pode resolver depois e tudo o que ele pode querer encontrar de novo
- Custo: quase nenhum, até o feed perder a credibilidade
- Limite: generoso, mas só enquanto a taxa de acerto continuar alta
Alguns poucos itens merecem os dois: uma aprovação que trava o trabalho de outra pessoa, um pagamento que falhou, uma exportação que o usuário está ali esperando. O padrão que funciona é um toast passageiro no momento do evento mais uma entrada permanente no feed, para que o usuário que perdeu o toast ainda tenha um registro. O padrão que não funciona é o toast sozinho, que é uma notificação que você jogou fora de propósito.
A anatomia de uma central de notificações
Um feed que continua confiável tem sete partes, e as que os times deixam de lado são sempre as três últimas.
Quatro itens, quatro categorias, um evento agrupado, e cada linha diz quem fez o quê em qual coisa.
- O ponto de entrada e o badge. Um ícone consistente e fácil de encontrar, com um estado que significa algo. Número para itens que precisam de atenção individual, um simples ponto para todo o resto.
- Itens com estrutura. Autor, ação, objeto, horário, e a linha inteira clicável até o destino exato, não até um dashboard a partir do qual o usuário ainda precisa navegar.
- Um estado de leitura que se mantém. O não lido deve ser visualmente óbvio, os itens lidos devem continuar disponíveis, e abrir o painel não deve marcar tudo como lido em silêncio; é assim que as pessoas perdem coisas.
- Agrupamento. Cinco comentários em um documento são um item que se expande, não cinco linhas. Para qualquer coisa colaborativa, agrupar por objeto funciona melhor que agrupar por tempo.
- Categorias ou filtros. Quando você tem mais de uns três tipos de notificação, os usuários precisam separar "coisas esperando por mim" de "coisas que aconteceram".
- Um estado vazio que não seja um vácuo. "Você está em dia" mais um atalho para as preferências é um estado vazio realmente bom; veja nosso guia de estados vazios para o padrão geral.
- Um caminho visível até as preferências. Usuários que conseguem desligar uma categoria não desligam todas. O link deve estar no próprio painel, não três níveis abaixo nas configurações.
O que vai no feed e o que não vai
| Categoria | Exemplos | Deve acender o badge? |
|---|---|---|
| Pessoal | Menção, comentário, resposta, compartilhamento, atribuição | Sim, sempre |
| Fluxo de trabalho | Aprovação pendente, revisão solicitada, tarefa com prazo, repasse | Sim, é a categoria de maior valor |
| Sistema | Exportação pronta, importação com falha, integração desconectada, cota atingida | Só quando é preciso agir |
| Novidades do produto | Um novo recurso na área em que este usuário realmente trabalha | Raramente: um ponto, não um número |
| Promocional | Convites para upgrade, webinars, lançamentos sem relação | Não, isso simplesmente não pertence ao feed |
A quarta linha é onde entra o bom senso. Novidades do produto podem ter lugar legítimo em um feed (é um dos poucos lugares onde um usuário que volta vai procurar o que mudou), mas só quando são relevantes para aquele usuário e só como item de baixa prioridade. No momento em que anúncios de lançamento começam a acender um badge numérico, o badge deixa de significar "algo precisa de você" e passa a significar "publicamos alguma coisa", e esse é o começo do fim. Nosso guia para anunciar novas funcionalidades explica como encadear um lançamento entre superfícies, e o de release notes trata do registro duradouro para o qual o feed deve apontar, em vez de substituí-lo.
A ladeira promocional. Todo feed abarrotado chegou lá do mesmo jeito: um time sem nada para anunciar percebeu que a central de notificações tinha boas taxas de abertura e resolveu usá-la. Taxa de abertura é uma propriedade do badge, não do conteúdo; ela se sustenta por meses enquanto a confiança escorre, e quando a métrica finalmente se mexe, os usuários que silenciaram o sino não voltam mais. É o mesmo mecanismo da cegueira de banner, aplicado a um componente que as pessoas não conseguem simplesmente rolar para longe.
Como escrever a notificação
O texto de uma notificação tem uma missão especialmente rígida: é lido em menos de um segundo, fora de contexto, ao lado de outras nove linhas. Três regras fazem a maior parte do trabalho.
1. Autor, ação, objeto, nessa ordem
O usuário bate o olho nas três primeiras palavras. Coloque a pessoa e o verbo ali e cite a coisa específica, não o tipo dela.
2. Transforme o item inteiro em link para o destino exato
Não para o módulo, nem para uma lista em que o usuário ainda precisa procurar. Leve direto ao comentário, à aprovação, ao arquivo. Uma notificação que exige navegação depois do clique transferiu o trabalho para o usuário e não entregou nenhum benefício.
3. Use o vocabulário do usuário, não o do sistema
Nomes internos de objetos vazam para os modelos de notificação mais rápido do que em qualquer outra parte do produto, porque as notificações costumam ser escritas por quem construiu o evento. "Sincronização de entidade concluída" não significa nada para quem lê. Nosso guia de microcopy UX mostra os padrões de reescrita; o atalho é ler a linha em voz alta e se perguntar se um cliente novo entenderia.
Frequência, agrupamento e o badge
Não existe um limite diário universal, porque o volume tolerável depende inteiramente da taxa de acerto. Um feed em que quatro de cada cinco itens valem a pena abrir pode ser intenso; um feed em que três de cada quatro são ruído acaba silenciado em praticamente qualquer volume. Três mecanismos mantêm essa proporção saudável.
1. Agrupe por objeto, depois por tempo
Cinco comentários em um documento viram "3 pessoas comentaram em Plano de onboarding 3º tri", com opção de expandir. Um resumo de tudo o que aconteceu enquanto a pessoa estava fora é melhor que uma parede de linhas individuais que ela vai apagar sem ler. Agrupar é a mudança de maior impacto disponível para um feed barulhento.
2. Dê a cada categoria sua própria política de badge
Itens pessoais e de fluxo de trabalho somam ao número. Itens de sistema só somam quando o usuário precisa fazer algo. Novidades do produto ganham no máximo um ponto. Escrita em forma de tabela, essa é uma decisão de cinco minutos que evita a forma mais comum de degradação do feed.
3. Respeite o momento e o contexto do usuário
Notificações geradas pela ação do próprio usuário devem aparecer na hora; todo o resto pode esperar uma pausa natural. Se você também envia e-mail ou push para os mesmos eventos, suprima a duplicata quando o usuário estiver ativo no produto; ouvir a mesma coisa de três jeitos é como um sistema útil vira um sistema irritante. Nosso guia de gatilhos traz as regras gerais de timing para interrupções dentro do produto.
Um feed de novidades do produto funciona quando é relevante e de baixa prioridade: um ponto, não um número vermelho.
Preferências: o recurso de retenção mais barato do sistema
Controles granulares parecem um extra e funcionam como um seguro. Um usuário incomodado com uma categoria que só pode escolher entre tudo ou nada vai escolher nada, e aí você perde as notificações de aprovação junto com o marketing. Três níveis costumam bastar: ligar/desligar por categoria, uma escolha de canal por categoria quando existe mais de um canal, e um silenciamento temporário.
A taxa de silenciamento por categoria também é o instrumento mais honesto que você vai ter para julgar se aquela categoria merece existir. Não é uma métrica de vaidade e não chega atrasada: as pessoas desligam as coisas na mesma semana em que se irritam.
Como medir notificações in-app
| Métrica | O que ela mostra | Cuidado com |
|---|---|---|
| Taxa de abertura do feed | Se o ponto de entrada é fácil de achar e se o badge tem credibilidade | Continua alta só pela pressão do badge, muito depois de a qualidade do conteúdo desabar |
| Taxa de clique / ação por item | Se as notificações individuais valem uma ação | Precisa ser lida por categoria; uma categoria forte esconde três fracas |
| Tempo até a ação | Se o feed está de fato destravando o trabalho | Só faz sentido para itens de fluxo de trabalho em que alguém está esperando |
| Taxa de silenciamento / opt-out | Se uma categoria é bem-vinda | O único número que não dá para maquiar; trate qualquer alta como um veredito |
| Apagadas sem abrir | Se as pessoas estão descartando em vez de ler | Uma taxa alta aqui com uma taxa de abertura saudável significa que o feed é puro teatro |
Acompanhe todas essas métricas por categoria, e não no agregado, e compare as categorias entre si, não com benchmarks publicados por outros produtos; o desempenho de um feed depende quase inteiramente do que você decidiu colocar nele, o que torna sem sentido a comparação entre empresas.
Seis formas de matar uma central de notificações
- Marketing no feed. O caminho mais rápido para um sino ignorado para sempre, e o mais difícil de reverter, porque a confiança não volta quando as promoções param.
- Um badge que nunca zera. Se chegar a zero é impossível, os usuários param de tentar, e o badge vira papel de parede colorido.
- Nenhum agrupamento. Um documento ativo gerando vinte linhas torna o feed inútil para todo o resto que está nele.
- Links sem saída. Clicar em uma notificação e cair em um dashboard é o equivalente, em interação, a "se vira".
- Leitura automática silenciosa ao abrir. Marcar tudo como lido quando o painel abre faz itens se perderem para sempre e é percebido como o produto escondendo coisas.
- Preferências de tudo ou nada. O usuário que queria desligar uma categoria desliga todas, inclusive as que faziam um trabalho real.
Notificações in-app: faça e não faça
✅ Faça
- Escreva autor, ação, objeto e cite o objeto específico
- Transforme a linha inteira em link direto para o destino exato
- Agrupe eventos relacionados em um único item expansível
- Dê a cada categoria sua própria política de badge
- Deixe as preferências a um clique do painel
- Acompanhe a taxa de silenciamento por categoria e aja com base nela
❌ Não faça
- Colocar promoções no feed de notificações
- Deixar um badge numérico contar itens de pouco valor
- Marcar tudo como lido no instante em que o painel abre
- Enviar o mesmo evento por e-mail, push e feed ao mesmo tempo
- Usar nomes internos de objetos no texto
- Julgar o feed só pela taxa de abertura
Como ter uma camada de notificações sem construir uma
Um sistema de notificações completo (modelo de eventos, estado de leitura, agrupamento, preferências, deep links) é um projeto de engenharia de verdade, e é o investimento certo quando as notificações são geradas pelos fluxos do seu próprio produto. Mas boa parte do que os times querem do sino nem é fluxo de trabalho: é contar aos usuários o que mudou, dentro do produto, em um lugar onde eles possam encontrar depois.
Essa parte não precisa de um projeto de engenharia. Um widget de anúncios in-app oferece uma lista persistente de atualizações, consultada pelo usuário, segmentada para o público a que cada atualização interessa e publicada sem release. Isso cobre direito a categoria de novidades do produto e a mantém longe do badge de fluxo de trabalho, onde ela causa estrago. Combine com um walkthrough curto para tudo o que os usuários precisam aprender, e o anúncio deixa de ser só um anúncio e vira adoção.
Conte aos usuários certos o que mudou, onde eles vão ver
O Kompassify oferece um widget de anúncios in-app, tooltips segmentados e walkthroughs guiados sobre o seu produto atual, para que as novidades cheguem ao segmento para o qual elas importam, sem competir com as notificações de que as pessoas dependem. Grátis até 100 usuários ativos mensais, planos a partir de US$ 129/mês, em conformidade com o GDPR e hospedado na UE.
Comece grátis →A versão em um parágrafo
Notificações in-app são endereçadas, persistentes e consultadas pelo usuário, o que torna o feed uma superfície realmente valiosa e, ao mesmo tempo, frágil. Restrinja-o ao que um usuário específico precisa ter registrado, agrupe sem dó, deixe só o trabalho de verdade acender um badge numérico, escreva na ordem autor, ação, objeto com um deep link, ofereça preferências por categoria e observe a taxa de silenciamento em vez da taxa de abertura. Novidades em massa merecem uma superfície de anúncios própria, ao lado do sino e não dentro dele.
Perguntas frequentes
O que são notificações in-app?
Notificações in-app são mensagens entregues dentro de um produto a um usuário específico sobre algo que aconteceu ou que precisa da atenção dele: o comentário de um colega, uma exportação concluída, uma aprovação pendente, um novo recurso na área em que ele trabalha. Normalmente ficam em uma central de notificações permanente, acessada por um ícone de sino, têm estado de lida ou não lida e continuam disponíveis até que o usuário cuide delas. É essa persistência que as separa de uma mensagem in-app em massa, como um modal ou banner, que aparece uma vez, interrompe e some.
Qual é a diferença entre notificações in-app e notificações push?
Notificações push são entregues pelo sistema operacional a um usuário que não está usando o seu produto naquele momento, e exigem uma permissão explícita que muita gente recusa. Notificações in-app são entregues dentro da sua interface a um usuário que já está ali, então não precisam de permissão, não podem ser bloqueadas pelo sistema operacional e podem ser muito mais ricas, mas só alcançam quem volta ao produto. Na prática, elas se complementam: o push serve para trazer alguém de volta, e o feed in-app guarda tudo o que a pessoa perdeu enquanto estava fora.
Qual é a diferença entre notificações in-app e mensagens in-app?
Uma mensagem in-app é enviada em massa e interrompe: um modal, banner, tooltip ou slideout exibido a um segmento de usuários em um momento escolhido, geralmente para anunciar, orientar ou pedir uma ação. Uma notificação in-app é endereçada e persistente: diz respeito a um único usuário, espera em um feed com estado de leitura e o usuário decide quando abri-la. A regra prática é que tudo o que o usuário precisa resolver mais tarde vai para o feed, e tudo o que precisa ser visto agora para a tela atual fazer sentido vai em uma mensagem.
O que deve ir para uma central de notificações?
Quatro categorias cobrem quase tudo: notificações pessoais, sobre alguém agindo no seu trabalho; notificações de fluxo de trabalho, sobre algo que está esperando por você; notificações de sistema, sobre tarefas e mudanças de status; e novidades do produto, sobre recursos relevantes para o que você faz. Todo o resto é marketing fantasiado de sininho. O teste é saber se o item é endereçado a este usuário específico e se ele, razoavelmente, gostaria de ter um registro disso. Se a resposta para qualquer uma das perguntas for não, o item pertence a uma mensagem, a um e-mail ou a lugar nenhum.
Como escrever uma notificação?
Comece pelo autor e pela ação, cite o objeto específico e transforme o item inteiro em um link para o lugar exato aonde o usuário precisa ir. 'Sam aprovou sua solicitação de orçamento do 3º trimestre' é melhor que 'Você tem uma nova aprovação'. Mantenha uma linha só sempre que possível, coloque um horário relativo ao lado e evite jargões que só fazem sentido para quem está dentro da empresa. Toda notificação deve responder a três perguntas na hora: quem fez o quê, em qual coisa, e o que acontece se eu clicar.
Quantas notificações in-app são demais?
O volume que importa não é por dia, e sim por unidade de valor. Um feed em que a maioria dos itens vale a pena abrir aguenta um volume alto; um feed em que três de cada quatro itens são ruído acaba silenciado em praticamente qualquer volume. Agrupe eventos relacionados em um único item em vez de enviar cinco, agrupe por objeto ou por dia e seja rigoroso sobre quais categorias podem acender o badge. Se a taxa de silenciamento de uma categoria está subindo, essa categoria é a resposta para a pergunta.
O badge de notificação deve mostrar um número?
Mostre um número apenas para itens que realmente precisam de atenção individual e use um simples ponto para todo o resto. Um badge numérico é uma promessa de que existem exatamente tantas coisas distintas para resolver; quando o número é inflado por itens de pouco valor, os usuários aprendem que zerá-lo não vale o esforço e passam a ignorá-lo para sempre. Um badge que nunca chega a zero deixou de ser um sinal e virou decoração.
Quais métricas acompanhar nas notificações in-app?
Acompanhe quatro coisas por categoria, e não no agregado: a taxa de abertura do próprio feed, a taxa de clique ou de ação nos itens individuais, o tempo entre a entrega e a ação, e a taxa de silenciamento ou de descadastro. Esta última é a medida honesta de que uma categoria é bem-vinda. A taxa de clique pode continuar respeitável até o momento em que as pessoas desligam tudo. Compare as categorias entre si, e não com benchmarks externos, porque o desempenho de um feed depende quase inteiramente do que você decide colocar nele.