Notificações push nem sempre chegam ao dispositivo. Usuários somem sem aviso. E uma parcela grande do seu público está no Telegram — especialmente em apps de delivery, fintech e e-commerce que atendem comunidades específicas no Brasil. A atualização de abril ataca esses três pontos de uma vez.
E é o seguinte que muda 👇
Novo canal disponível: Telegram 💬
Agora você pode configurar um bot do Telegram no Pushwoosh e mandar mensagens 1:1 para os usuários direto do Customer Journey Builder, no mesmo fluxo dos seus passos de push, in-app, email, SMS e WhatsApp.
O que muda: Para muitos apps mobile no Brasil, o Telegram é onde acontecem as conversas reais — em comunidades de apostas, delivery, ofertas e suporte ao cliente. Para alcançar esse público, antes era preciso rodar uma ferramenta separada do lado da sua stack principal de marketing. Com o Telegram dentro do Customer Journey, você orquestra esse canal como qualquer outro: mesma segmentação, mesmos triggers, mesmo reporting. Push, WhatsApp e Telegram convivendo no mesmo journey, decidindo entre si com base em comportamento.
Não perca os usuários que não receberam o seu push 🔁
O passo de push notification no Customer Journey Builder já dividia o fluxo pelo abrir. Agora ele também divide pelo delivery — ou seja, se a mensagem chegou de fato no aparelho.
- 🟢 Entregue → segue pelo caminho principal.
- 🟠 Não entregue (token expirado, aparelho offline, opt-out etc.) → reroteia esses usuários pra outro canal: email, SMS, in-app ou Telegram.
Por que isso importa: A taxa de abertura te diz quem se engajou. A taxa de entrega te diz quem chegou a receber a mensagem. No Brasil, com base de Android dominante (~85%) e dispositivos de entrada com modos de economia de bateria agressivos, parte considerável dos pushes simplesmente não chega na primeira tentativa. Os usuários que não receberam costumam ser exatamente os que você mais precisa alcançar — confirmação de PIX no fintech, status de pedido no delivery, push de Black Friday faltando minutos pra acabar. O journey agora roteia esses usuários automaticamente pro canal de fallback, com contagem de entregue vs. não entregue visível no canvas.
Pegue os usuários ociosos antes que eles deem churn 😴
Um novo evento padrão do SDK, PW_UserIdle, dispara quando um usuário fica inativo no seu app mobile. O SDK já entrega esse evento — você não precisa definir manualmente.
Usuários ociosos são difíceis de tratar: ainda não deram churn, mas também não tem nenhum sinal nos seus dados que os identifique. Com o PW_UserIdle, dá pra:
- segmentar usuários dormentes pra campanhas de reengajamento,
- disparar journeys direto pelo evento, ou
- alimentar o sinal no ManyMoney AI, pra que ele leve a inatividade em conta nas campanhas que monta sozinho.
Saiba mais sobre PW_UserIdle (e seus atributos) →
Cloud Pages chegando em todos os planos 📄
Cloud Pages, landing pages com a sua marca hospedadas pelo Pushwoosh, agora estão disponíveis pra qualquer conta sob solicitação.
O que muda: A maioria das campanhas precisa de uma página de destino: pesquisa, formulário de cadastro, promo de Dia das Mães em formato longo, página de click-through depois de uma in-app. Antes isso vivia num page builder separado. Agora você constrói e hospeda esse destino dentro do Pushwoosh, com os dados de audiência e segmentação já conectados — uma ferramenta a menos na stack.
Pra ativar Cloud Pages na sua conta, fala com o Customer Success Manager ou com o Suporte.
Teste as atualizações você mesmo
Toda feature acima já tá no ar e pronta pra uso na sua conta.
A lista completa tá nas nossas release notes.
