Use notificações push para mensagens curtas e urgentes que precisam chegar a alguém que não está no seu app, mensagens in-app para tudo o que está ligado ao que o usuário está fazendo naquele momento, e e-mail para detalhes, registros e pessoas que pararam de abrir o app. Os três canais não competem entre si: o push traz as pessoas de volta, o in-app as orienta quando já estão lá, e o e-mail leva tudo o que precisa ser guardado ou lido com atenção.
Push vs e-mail vs in-app: como os três canais se comparam?
Cada canal é definido por onde a mensagem aparece e por quem consegue recebê-la. Todo o resto decorre desses dois fatos.
| Notificação push | Mensagem in-app | ||
|---|---|---|---|
| Onde aparece | Tela de bloqueio, banner e central de notificações, fora do app | Dentro do app, durante uma sessão | A caixa de entrada do usuário, fora do app |
| Quem pode receber | Usuários que têm o app instalado e permitiram notificações | Usuários que abrem o app | Qualquer pessoa cujo endereço de e-mail você tenha e que não tenha cancelado a inscrição |
| O app precisa estar aberto? | Não | Sim | Não |
| O usuário precisa permitir antes? | Sim, por meio de um aviso do sistema | Não | Ele precisa fornecer um endereço e pode cancelar a inscrição |
| Quanto consegue dizer | Um título e uma ou duas linhas | De uma frase a uma tela inteira, com botões e imagens | O quanto você precisar |
| Quanto tempo dura | Até ser dispensada ou empurrada para baixo por notificações mais novas | Até o usuário fechá-la, a menos que você crie uma caixa de entrada | Até o usuário excluir ou arquivar |
| Quanto interrompe | Muito | Médio, o usuário já está engajado | Pouco, é lido quando o usuário quiser |
| Melhor função | Trazer o usuário de volta para algo que está acontecendo agora | Orientar, anunciar ou estimular dentro do contexto | Explicar, confirmar, resumir, reconquistar |
| Principal risco | Os usuários desativam as notificações | Nunca é vista por usuários que não voltam | Não é lido ou cai na pasta errada |
Qual é a diferença entre notificações push e notificações in-app?
Uma notificação push é entregue pelo sistema operacional do celular e aparece fora do seu app. Uma notificação in-app é desenhada pelo seu próprio app e aparece apenas enquanto alguém o está usando. Essa única diferença decide quem vê a mensagem, quando, e se a pessoa precisou concordar com isso antes.
Onde cada uma aparece
As notificações push são enviadas pelos serviços de entrega da Apple e do Google até o aparelho, onde o sistema as exibe na tela de bloqueio, como banner ou na central de notificações. O seu app não precisa estar em execução.
As notificações in-app fazem parte da sua interface. O Firebase In-App Messaging, a ferramenta do Google para isso, descreve a função como o envio de mensagens segmentadas e contextuais aos usuários ativos do seu app, e as oferece como cartões, banners, modais ou imagens. Tooltips, telas cheias e uma caixa de entrada de notificações dentro do app são variações comuns da mesma ideia.
Quem pode receber cada uma
O push só alcança quem disse sim. No iOS, a documentação para desenvolvedores da Apple diz que você precisa obter permissão para usar notificações, e que o sistema exibe o aviso à pessoa na primeira vez em que o seu app pede e não volta a exibi-lo em pedidos posteriores. No Android, a documentação do Google diz que, no Android 13 ou superior, as notificações de um app ficam desativadas por padrão até que o usuário conceda a permissão.
As mensagens in-app não precisam de nenhuma permissão do sistema, porque são simplesmente parte do app. O limite é outro: um usuário que nunca abre o app nunca as vê.
Portanto, os dois públicos se sobrepõem, mas não são iguais. O push alcança usuários com o app instalado que permitiram notificações, estejam ativos ou não. O in-app alcança usuários ativos, tenham permitido notificações ou não.
O que acontece depois que a mensagem é vista
Uma notificação push é fácil de perder. Um deslize a apaga, e uma central de notificações cheia a enterra. Uma mensagem in-app pode ser igualmente breve (um banner que desaparece) ou pode ficar guardada, se você criar uma caixa de entrada ou um feed de notificações em que as mensagens anteriores continuam disponíveis. Se o usuário pode precisar da informação na semana que vem, nem um push nem um banner passageiro bastam sozinhos.
Notificações push vs in-app: quando usar cada uma?
Use push quando o usuário está fora do app e a mensagem não pode esperar. Use in-app quando a mensagem só faz sentido no contexto do que o usuário está fazendo, ou quando ela pode esperar até a próxima visita.
Quando o push é a escolha certa
- Algo está acontecendo agora ou muito em breve: uma sessão ao vivo começando, uma entrega chegando, um lance sendo superado.
- Outra pessoa fez algo que importa para o usuário: uma resposta, uma menção, um amigo que entrou.
- Um lembrete que o usuário pediu: um treino, uma aula, o horário de um medicamento.
- Um alerta curto sobre a conta, como uma renovação que falhou, com os detalhes enviados também por e-mail.
O push é a escolha errada para qualquer coisa longa, qualquer coisa que não seja oportuna e para promoção em geral. A orientação da Apple sobre gerenciamento de notificações diz para não usar notificações para conteúdo de marketing ou promocional, a menos que as pessoas tenham concordado explicitamente em recebê-lo, e para reservar o nível Time Sensitive para eventos que estão acontecendo agora ou dentro de uma hora.
Quando o in-app é a escolha certa
- Etapas de onboarding e dicas relacionadas à tela em que o usuário está.
- Anunciar uma funcionalidade no ponto em que ela é útil.
- Estímulos de upgrade e paywalls, exibidos quando o usuário atinge um limite.
- Pesquisas e pedidos de feedback, logo após a experiência sobre a qual você está perguntando.
- Convites de indicação, em um momento em que o usuário está satisfeito com o app.
O in-app é a escolha errada para alcançar pessoas que se afastaram e para qualquer coisa em que o usuário precise agir fora do app.
Notificação push vs e-mail: qual você deve enviar?
Envie um push quando o valor da mensagem está no momento em que ela chega. Envie um e-mail quando o valor está no conteúdo. Se uma mensagem seria inútil amanhã, é um push. Se o usuário pode querer encontrá-la de novo daqui a um mês, é um e-mail.
O que o e-mail faz e o push não consegue
- Ele dura. Recibos, avisos de renovação, redefinições de senha e alterações nos seus termos pertencem a um lugar em que o usuário possa pesquisar depois.
- Ele carrega detalhes. Um changelog, um resumo semanal de progresso ou um guia passo a passo não cabem em uma notificação.
- Ele alcança pessoas sem o app. Quem desinstalou, trocou de celular ou nunca permitiu notificações ainda pode ser alcançado por e-mail.
- Ele funciona em qualquer dispositivo. O usuário pode ler no computador e agir ali mesmo.
O que o push faz e o e-mail não consegue
- Ele chega à tela de bloqueio em instantes, sem que o usuário abra nada.
- Ele abre o app na tela certa com um toque.
- Ele combina com um único estímulo curto, em que um e-mail pareceria pesado.
O que o e-mail exige de você
O e-mail tem seus próprios requisitos de entrada. Os provedores de e-mail esperam que os remetentes autentiquem o domínio de envio: as diretrizes do Google para remetentes de e-mail pedem que todos os remetentes configurem SPF ou DKIM, e que as mensagens de marketing ofereçam cancelamento de inscrição com um clique. Um e-mail que não está configurado corretamente pode nem chegar à caixa de entrada, o que é o equivalente, no e-mail, a um usuário desativar as notificações.
Mensagens que merecem os dois
Algumas mensagens são ao mesmo tempo urgentes e detalhadas. Um pagamento que falhou é o exemplo clássico: envie um push curto para que o usuário saiba hoje, e um e-mail com o valor, a data e o link para resolver. O push faz o alerta, o e-mail faz a explicação. Evite enviar o mesmo texto nos dois, porque o usuário vai ler duas vezes e aprender a ignorar um deles.
Como escolher um canal para uma mensagem específica?
Faça três perguntas, nesta ordem, e pare na primeira que der uma resposta.
- Ela só faz sentido dentro do app, em um momento específico? Use in-app.
- Ela perde o valor em questão de horas? Use push, com o in-app como alternativa para usuários que estão com as notificações desativadas.
- Ela precisa de detalhes, ou o usuário vai querer guardá-la? Use e-mail.
Se uma mensagem não passa em nenhuma das três, talvez ela não precise ser enviada.
Veja como isso funciona para as mensagens que a maioria dos apps envia:
| Mensagem | Primeira escolha | Adicione um segundo canal quando |
|---|---|---|
| Alguém respondeu a você | Push | Mostre no app se o usuário estiver em uma sessão |
| O teste termina amanhã | Push | E-mail no mesmo dia com o que acontece em seguida |
| Recibo de compra | Confirme na tela logo após a compra | |
| Redefinição de senha | Nunca, mantenha em um só lugar | |
| Nova funcionalidade | In-app | E-mail para usuários que não abriram o app recentemente |
| Estímulo de upgrade | In-app | Raramente, uma oferta por e-mail para usuários cujo teste expirou |
| Resumo semanal ou mensal | Um push somente se o usuário tiver pedido | |
| Pesquisa de feedback | In-app | E-mail para pesquisas mais longas |
| Reconquistar um usuário inativo | Push se ele ainda estiver com as notificações ativadas | |
| Convite para indicar um amigo | In-app | E-mail como acompanhamento, com o link dele |
Como usar e-mail, push e in-app juntos sem irritar os usuários?
Decida a ordem dos canais para cada mensagem, envie primeiro pelo menos intrusivo e só escale para as pessoas que ainda não a viram. Enviar tudo, em todos os canais, ao mesmo tempo é o caminho mais rápido para perder a permissão de push.
Cascata em vez de disparo em massa
Tome o lançamento de uma funcionalidade como exemplo prático. Você pode:
- Mostrar um anúncio in-app a todos que abrirem o app na primeira semana.
- Enviar um e-mail aos usuários que não abriram o app naquela semana, com a explicação completa.
- Enviar um push apenas aos usuários que não viram nenhum dos dois, e somente se a funcionalidade for algo pelo qual eles agradeceriam.
Cada etapa pula as pessoas que a etapa anterior já alcançou. O mesmo padrão funciona no sentido inverso para mensagens urgentes: primeiro o push, depois o in-app na sessão seguinte, depois o e-mail se o assunto ainda estiver em aberto.
Peça a permissão de push em um momento sensato
Como o iOS exibe o aviso de permissão uma única vez, o momento desse primeiro pedido importa mais do que qualquer otimização posterior. A Apple sugere fazer o pedido dentro do contexto, por exemplo depois que alguém agenda a primeira tarefa em um app de tarefas, para que as pessoas vejam para que servem as notificações. O Google dá um conselho parecido para o Android, sugerindo que o aviso venha depois de uma ação do usuário, como tocar em um ícone de sino ou fazer um pedido.
Deixe os usuários escolherem por assunto, não tudo ou nada
Se o único botão que o usuário tem é "desativar todas as notificações", é esse que ele vai usar. Ofereça categorias. No Android isso já vem pronto: os canais de notificação permitem que os usuários alterem as configurações de cada tipo de notificação que o seu app envia, e, depois que um canal é criado, o comportamento dele fica sob o controle do usuário. No iOS, a Apple pede que os apps que enviam notificações informativas ou de marketing ofereçam uma tela de configurações dentro do app em que as pessoas possam mudar a escolha. Faça o mesmo com o e-mail, com opções separadas para novidades do produto, resumos e ofertas.
Qual canal funciona melhor para convites de indicação e atualizações para afiliados?
Convites de indicação funcionam melhor no in-app, e atualizações para afiliados ou parceiros funcionam melhor por e-mail, porque os dois públicos estão em lugares diferentes.
Um usuário tem mais chance de compartilhar o seu app logo depois que ele fez algo por ele: uma sequência concluída, uma meta alcançada, um projeto finalizado. Esse momento só existe dentro do app, então o convite pertence a esse lugar, com um botão de compartilhar que abre o menu de compartilhamento do celular. Temos um post separado sobre como transformar usuários em afiliados com indicações in-app. Se você preferir não construir a tela por conta própria, as indicações in-app do Insert Affiliate incluem uma tela pronta de "Indique um amigo" que dá a cada usuário o próprio código e link, com botões Copiar e Compartilhar. Há uma visão geral na página do programa de indicação para apps móveis.
Afiliados e criadores são diferentes. Eles não vivem no seu app, e o que eles precisam (uma nova oferta, uma mudança de comissão, os resultados do mês) são detalhes que eles vão querer consultar de novo. Esse é o trabalho do e-mail, de preferência apoiado por uma caixa de entrada em que eles possam fazer login. É assim que as mensagens para afiliados funcionam no Insert Affiliate: uma mensagem direta ou um comunicado a todos os afiliados é enviado como notificação por e-mail e também aparece na seção Mensagens do painel do afiliado. Os afiliados podem optar por não receber os e-mails de comunicados e continuar recebendo mensagens diretas, o que é o mesmo princípio de "escolher por assunto" descrito acima. Leitura relacionada: como manter a comunicação com afiliados em um só lugar.
Perguntas frequentes
Notificações in-app são a mesma coisa que notificações push?
Não. Uma notificação push é entregue pelo sistema operacional e aparece fora do app, na tela de bloqueio ou na central de notificações. Uma notificação in-app é exibida pelo próprio app e só pode ser vista enquanto o app está aberto. Muitas vezes as duas são acionadas pelo mesmo evento, e o app escolhe uma ou outra dependendo de o usuário estar ou não em uma sessão naquele momento.
Notificações in-app precisam da permissão do usuário?
Nenhuma permissão do sistema é necessária, porque as mensagens in-app fazem parte da sua própria interface. O push é diferente: o iOS exige que o usuário permita notificações, e no Android 13 ou superior as notificações ficam desativadas por padrão até que o usuário conceda a permissão.
Push é melhor do que e-mail?
Nenhum dos dois é melhor no geral. O push é melhor para mensagens curtas cujo valor depende do momento, e consegue abrir o app com um toque. O e-mail é melhor para detalhes, para tudo o que o usuário precisa guardar e para pessoas que não têm mais o app ou estão com as notificações desativadas.
Qual canal devo usar para reengajar usuários inativos?
Comece pelo e-mail, porque ele não depende de o app estar instalado nem de as notificações estarem permitidas. O push pode funcionar para usuários que ainda estão com as notificações ativadas, desde que a mensagem ofereça um motivo real para voltar. As mensagens in-app não ajudam aqui, já que os usuários inativos não vão vê-las.
O que devo fazer com os usuários que desativaram as notificações push?
Trate o in-app e o e-mail como suas alternativas. Mostre a mensagem no app na próxima sessão deles e envie um e-mail quando ela não puder esperar tanto. Se o push claramente os ajudaria, explique o benefício dentro do app em um momento relevante e indique as configurações do aparelho, já que o iOS não vai exibir o aviso do sistema uma segunda vez.
Seu próximo passo
Liste todas as mensagens que o seu app envia hoje e passe cada uma pelas três perguntas acima. Primeiro, mova os pushes que deveriam ser mensagens in-app e, depois, adicione preferências por categoria para que os usuários possam baixar o volume sem desligar você por completo.