Um único pedido no iFood pode disparar de 5 a 7 notificações push entre o “pedido confirmado” e o “entregue”. Multiplique isso por três ou quatro pedidos na semana, e o app começa a parecer spam. O usuário brasileiro médio já recebe 46 notificações push por dia, e 43% desativam os alertas quando os apps mandam só 2 a 5 por semana.
O usuário quer saber o que está acontecendo em cada momento, não ser interrompido cinco vezes no caminho. A diferença entre engajamento e desinstalação está em saber quais momentos pedem push e quais só precisam ficar visíveis.
Este guia mostra a diferença entre alerta e estado em tempo real, apresenta a regra de 3 mensagens, traz exemplos práticos de delivery e e-commerce no Brasil, e um plano de 3 passos para implementar sem refazer sua stack. No caminho, você verá como a Pushwoosh orquestra push e Live Activities no mesmo canvas de jornada.
Alertas vs. estado em tempo real: a única distinção que importa
A maioria dos times trata push como canal padrão para tudo que é tempo real. Pedido confirmado, push. Entregador atribuído, push. Entregador a caminho, push. Entregador chegando, push. Entregue, push. Cinco interrupções para um evento que o próprio usuário iniciou e já está esperando.
Cada uma dessas atualizações é importante, mas nem toda precisa ser um push. Existem 2 trabalhos de comunicação fundamentalmente diferentes em cenários de tempo real:
Alertas dizem “Aconteceu algo! Olhe agora.” Eles interrompem e exigem atenção. Pertencem a momentos que realmente pedem uma decisão ou uma mudança de comportamento: o portão do seu voo mudou, seu pagamento falhou, seu motorista chegou.
Estado em tempo real diz “Olha o que está rolando agora, dá uma olhada quando quiser.” É ambiente e atualiza continuamente. Estado cobre o que o usuário quer acompanhar sem precisar reagir: localização do entregador, tempo de preparo, ETA da entrega, placar do jogo, distância do treino.
Push foi criado para alertas. Live Activities foi criada para estado em tempo real. Usar push para rastreamento de estado significa interromper o usuário para contar algo que ele não pediu para ser interrompido.
A regra das 3 mensagens
Para qualquer cenário em tempo real, você precisa de no máximo 3 notificações push.
Início. Confirma que o processo começou. “Seu pedido foi confirmado.” “Pagamento iniciado.” “Seu motorista está a caminho.” Isso alinha expectativas, dá confiança ao usuário e ativa a Live Activity que vai carregar o resto.
Exceção. Algo deu errado ou precisa de atenção. “Item indisponível.” “Seu entregador não encontra a portaria.” “PIX recusado, atualize seu cartão.” “Voo atrasado em 2 horas.” Essas são interrupções legítimas porque exigem ação.
Conclusão. O processo terminou. “Seu pedido foi entregue.” “Pagamento recebido.” “Você chegou ao destino.” Isso fecha o ciclo e encerra a Live Activity.
Tudo entre Início e Conclusão vive na tela de bloqueio como uma Live Activity: o tempo de preparo descendo, o entregador se movendo no mapa, o placar atualizando, o ETA recalculando. Atualizado automaticamente, com zero interrupções.
Como isso fica na prática: um pedido no iFood
Pegue um fluxo padrão de delivery, antes e depois.
Antes (abordagem só com push), 5 notificações em ~45 minutos:
- 🔔 “Seu pedido foi confirmado”
- 🔔 “Seu pedido está sendo preparado”
- 🔔 “Seu entregador pegou o pedido”
- 🔔 “Seu entregador está próximo”
- 🔔 “Seu pedido foi entregue”
Cinco interrupções para um almoço. Multiplique por dois ou três pedidos na semana, e um único app já dispara de 10 a 15 notificações. É o ponto em que o usuário começa a desativar tudo.
Depois (regra de 3 push + Live Activity):
- 🔔 Push: “Seu pedido foi confirmado” -> Live Activity começa
- 📱 Live Activity atualiza em silêncio: preparando -> retirado -> localização do entregador -> contagem de ETA
- 🔔 Push (só se necessário): “O entregador não consegue acessar o prédio, verifique o celular”
- 📱 Live Activity: contagem de ETA continua
- 🔔 Push: “Seu pedido foi entregue” -> Live Activity encerra
O usuário passa de 5 interrupções para 2, ou 3 se der algum pepino. A tela de bloqueio fica limpa e a visibilidade em tempo real fica até melhor. Em vez de cinco pings desconectados, o usuário vê um rastreador contínuo com localização do entregador e ETA atualizando a cada segundos.
Resultado: menos opt-outs, menos tickets de “cadê meu pedido” no suporte, e o app fica visível na tela de bloqueio por 30 a 45 minutos seguidos em vez de piscar cinco vezes e sumir.
Adapte a regra para o seu app
A mesma regra funciona em qualquer app em que o usuário acompanha algo em tempo real.
| App | Push: Início | Live Activity | Push: Exceção | Push: Conclusão |
|---|---|---|---|---|
| Mobilidade (Uber, 99) | Motorista atribuído | Localização, ETA, dados do veículo | Motorista cancelou / redirecionado | Viagem concluída + valor |
| E-commerce (Mercado Livre, Shopee) | Pedido enviado | Separação -> em trânsito -> saiu para entrega -> próximo | Atraso ou tentativa falhada | Entregue |
| FinTech (Nubank, Inter, PIX) | PIX iniciado / TED enviada | Status do processamento (validação, antifraude) | Pagamento falhou / atividade suspeita | PIX concluído |
| Games | Torneio começa / energia cheia | Posição no ranking, timer do chefe, progresso | Adversário encontrado / sequência em risco | Resultado da partida |
| Notícias e mídia (GloboPlay, UOL) | Notícia de última hora / evento ao vivo | Placar ao vivo, apuração, manchete | Virada importante | Evento encerrado |
Em todos os casos, o push marca as transições que importam. A Live Activity carrega o estado entre elas.
Como começar sem refazer sua stack
O contra-argumento clássico: “Precisaríamos de um refactor grande para adicionar Live Activities.” Na prática, uma abordagem em três passos cabe em um único sprint.
-
Audite seu fluxo de push atual
Escolha uma jornada em tempo real (rastreamento de pedido, uma corrida, uma partida) e liste todas as push notifications que ela dispara. Marque cada uma: ela exige que o usuário faça algo ou saiba algo novo, ou é só um status que ele poderia consultar sozinho? Normalmente, 2 ou 3 de 5 a 7 pushes sobrevivem a esse filtro.
-
Suprima e substitua
Desligue os pushes de status. Dispare uma Live Activity no push de Início, encerre no push de Conclusão. Atualize via API em cada ponto onde você antes mandava push.
-
Meça
Acompanhe três coisas por 2 a 4 semanas. Taxa de opt-out deve cair. Volume de ticket de suporte do tipo 'cadê meu pedido' diminui porque a Live Activity dá autoatendimento. E frequência de sessão costuma subir em vez de cair: usuários com Live Activity ativa tendem a abrir mais o app, porque a tela de bloqueio vira um ponto de re-entrada.
