Em resumo
Os dois canais se parecem porque ambos exibem mensagens curtas a partir do seu produto, mas ficam em lados opostos de duas linhas: alcance e consentimento. O web push sai do seu site e chega ao dispositivo depois que o usuário concede uma permissão no navegador. A mensagem in-app fica dentro de uma sessão ativa e não precisa de permissão separada. Trate-os como duas ferramentas, não uma.
Como o web push funciona
O web push depende de três peças do navegador trabalhando juntas: um service worker (um script em segundo plano que o navegador mantém rodando), a Push API (que inscreve o navegador em um serviço de push e recebe as mensagens) e a Notifications API (que exibe a notificação do sistema). O usuário precisa clicar explicitamente em Permitir no pedido de permissão do navegador; até lá, você não pode enviar nada. Depois do opt-in, você recebe um endpoint de inscrição e chaves de criptografia, e seu servidor envia pelo serviço de push do navegador mesmo com a aba fechada. Como a mensagem chega fora do site, o web push é o canal de reengajamento do grupo — mais próximo, na função, do SMS ou do e-mail do que de qualquer coisa que vive dentro do seu app. O porém: ele depende do suporte do navegador e do sistema operacional, e o usuário pode revogar a permissão a qualquer momento.
A ressalva do iOS
No iPhone e no iPad, o web push não funciona em uma aba comum do Safari. A Apple adicionou o web push só para web apps que o usuário adicionou à Tela de Início, a partir do Safari 16.4 (março de 2023). O pedido de permissão precisa vir em resposta a um toque direto — por exemplo, um botão Inscrever-se —, não ao carregar a página. Então, no iOS, o público que você alcança é o subconjunto de usuários que instalaram seu site como web app e depois concederam a permissão. Planeje-se para essa lacuna em vez de supor paridade com o desktop.
Como as mensagens in-app funcionam
As mensagens in-app aparecem dentro de uma sessão ativa — um banner, um modal, um slideout ou um tooltip desenhado pelo seu produto enquanto o usuário o utiliza. Não há opt-in separado, porque o usuário já está no seu produto; a mensagem faz parte da experiência. A contrapartida é o alcance: o in-app só alcança quem está presente agora. Ele não traz de volta um usuário afastado, e um usuário que cancelou nunca vai vê-lo.
Quando usar cada um
| Objetivo | Use |
|---|---|
| Trazer de volta um usuário afastado | Web push (ou e-mail / SMS) |
| Anunciar um recurso para usuários ativos | Banner ou modal in-app |
| Guiar um novo usuário na configuração | Tooltip ou slideout in-app |
| Alertar sobre um evento urgente fora do site | Web push |
| Sugerir um upgrade no meio de uma tarefa | Modal in-app |
A divisão honesta: o in-app cuida das pessoas que já estão na sala, o web push vai atrás das que saíram. A maioria dos produtos usa os dois, coordenados dentro de uma jornada do cliente, para que a mesma pessoa não receba um lembrete in-app e um push sobre a mesma coisa com minutos de diferença. Decidir qual canal leva qual mensagem, em que ordem e sem sobreposição é a passagem de rodar vários canais para rodá-los como um só — o tema de multicanal vs. omnichannel. Ferramentas independentes como o OneSignal ou o Novu são especializadas na entrega de push e notificações; uma plataforma de engajamento incorpora o push e o in-app à mesma lógica de jornadas que o resto dos seus canais.