Imagine só: você lançou uma campanha de push para seus usuários de Android. O painel diz “enviado”. Mas as aberturas são metade do que você esperava — e você não consegue saber se o problema é um criativo ruim ou uma falha na entrega.
No Android, a resposta muitas vezes não é nenhuma das duas. Canais de notificação, configurações de prioridade e políticas agressivas de bateria dos OEMs podem matar silenciosamente suas mensagens antes que os usuários as vejam. O painel não vai sinalizar isso. Suas análises não vão explicar. As mensagens simplesmente desaparecem.
Este é um manual de diagnóstico: onde o funil de entrega do Android realmente quebra e o que você pode fazer a respeito — sem semanas de investigação dos desenvolvedores.
Onde suas notificações push realmente se perdem?
A maioria das equipes de aplicativos móveis acompanha 2 números: enviados e abertos. Mas no Android, existem 4 estágios — e as maiores perdas acontecem no meio, onde ninguém está olhando.
Cada transição tem seu próprio modo de falha:
Enviado → Entregue. A mensagem saiu do seu servidor, mas nunca chegou ao dispositivo. Causas comuns: tokens FCM expirados, dispositivo offline por longos períodos, aplicativo desinstalado com tokens antigos ainda em seu banco de dados.
Entregue → Exibido. A mensagem chegou ao dispositivo, mas nunca foi mostrada ao usuário. É aqui que residem os problemas específicos do Android: a otimização de bateria do OEM mata a notificação, o canal de notificação está silenciado ou desativado, as configurações de prioridade causam uma entrega silenciosa.
Exibido → Aberto. O usuário viu a notificação, mas não tocou. É aqui que o criativo, o tempo e a relevância realmente importam — mas somente depois que você confirmou que os 2 primeiros estágios estão funcionando.
A principal conclusão: se sua taxa de entrega para exibição for baixa, nenhum teste A/B no texto ajudará. Você está otimizando uma mensagem que ninguém vê. Veja como encontrar e corrigir o problema real em 3 etapas.
Os 3 principais assassinos silenciosos da entrega de push no Android
Canais de notificação: 1 canal padrão ≠ estratégia
Desde o Android 8.0, toda notificação deve ser atribuída a um canal. Os usuários podem controlar cada canal de forma independente — silenciá-lo, alterar seu comportamento ou desativá-lo completamente.
O problema: quando todas as mensagens — promoções, alertas transacionais, lembretes — passam por 1 canal padrão, um único usuário irritado silencia tudo. Ele queria menos promoções; em vez disso, perdeu confirmações de pedidos, recibos de pagamento e alertas de segurança também.
O que fazer: Estruture os canais por caso de uso. No mínimo, separe mensagens transacionais (status do pedido, confirmações de pagamento) das promocionais (ofertas, reengajamento). Cada canal recebe seu próprio nível de importância.
Sinal de diagnóstico: se as taxas de abandono são idênticas em todos os tipos de mensagem — promocionais e transacionais — a estrutura do seu canal é provavelmente o problema. Os usuários estão silenciando o único canal que carrega tudo.
Prioridade e importância: por que sua mensagem chega silenciosamente
Existem 2 camadas que controlam como uma notificação se comporta, e confundi-las é um dos erros mais comuns.
Prioridade do FCM determina com que urgência o sistema entrega a mensagem ao dispositivo. A prioridade ALTA acorda o dispositivo imediatamente; a NORMAL pode ser agrupada e atrasada.
Importância do canal determina como a notificação aparece para o usuário assim que está no dispositivo. A importância ALTA aciona um banner de notificação e som. A PADRÃO aparece silenciosamente na área de notificações.
A armadilha: Prioridade ALTA do FCM + importância PADRÃO do canal = a mensagem chega ao dispositivo imediatamente, depois fica invisível na bandeja de notificações. As análises dizem “entregue”. O usuário nunca percebeu.
Políticas de bateria do OEM
O Android puro é apenas parte da história. Samsung, Xiaomi, Huawei, Oppo e Vivo aplicam, cada um, sua própria otimização agressiva de bateria sobre os padrões do Android. Essas políticas podem impedir que seu aplicativo receba notificações push completamente — mesmo quando o token FCM é válido e a entrega “é bem-sucedida”.
Veja como isso se divide por fabricante:
- Xiaomi (MIUI): O início automático é desativado por padrão. Após uma reinicialização do dispositivo, seu aplicativo não pode receber notificações push até que o usuário o abra manualmente — a menos que tenha concedido a permissão de início automático.
- Huawei (EMUI/HarmonyOS): O encerramento agressivo de aplicativos termina os processos em segundo plano. Os pushes param de chegar após um período de inatividade, mesmo que o aplicativo tenha sido usado recentemente.
- Samsung (One UI): As listas de “Aplicativos em suspensão” e “Aplicativos em suspensão profunda” atrasam ou bloqueiam notificações para aplicativos que o usuário não abriu recentemente.
- Oppo/Vivo (ColorOS/Funtouch): Restrições de atividade em segundo plano suprimem silenciosamente as notificações. O aplicativo parece funcionar normalmente quando aberto, mas a entrega em segundo plano falha.
O ponto em comum: em todos esses OEMs, o usuário deve permitir explicitamente que seu aplicativo seja executado em segundo plano. Sem essa permissão, a entrega “é bem-sucedida” no papel, mas a notificação nunca aparece.
Sinal de diagnóstico: se as taxas de entrega ou abertura variarem drasticamente por fabricante de dispositivo na mesma campanha, as restrições de OEM são quase certamente a causa.
Encontre onde quebra e corrija
Você entende o que pode dar errado. Veja como encontrar seu problema específico e resolvê-lo.
1. Configure seus instrumentos de diagnóstico
Segmente por dispositivo. Crie segmentos específicos para Android por versão do SO e fabricante do dispositivo. Esta é a sua ferramenta de diagnóstico mais importante. Ela permite que você veja se os problemas de entrega são universais ou isolados a um OEM específico.
Acompanhe o funil completo. Certifique-se de que seu SDK esteja configurado para relatar não apenas “enviado”, mas “entregue” e “aberto” como eventos distintos. Sem isso, você está cego para o meio do funil.
Estruture os canais de notificação por caso de uso. No mínimo, divida transacionais (status do pedido, alertas de segurança) e promocionais (ofertas, reengajamento). Cada canal deve ter seu próprio nível de importância.
Pedidos para os desenvolvedores (configuração única):
- Passe o fabricante do dispositivo, a versão do SO e o modelo como atributos de usuário para segmentação
- Verifique se o rastreamento de entrega está configurado corretamente no SDK
- Defina canais de notificação no código com os níveis de importância apropriados
2. Execute uma jornada de diagnóstico
Envie a mesma campanha para seus segmentos Android (divididos por fabricante) e seu público iOS. Compare as quedas e aberturas da jornada passo a passo.
Para este propósito, recomendamos usar um Construtor de Jornada do Cliente da Pushwoosh amigável para profissionais de marketing (você pode se inscrever gratuitamente e testá-lo):
- ⚠️ Segmentos Android caem na etapa de entrega, iOS se mantém estável → o problema é de infraestrutura: restrições de OEM, problemas de token ou má configuração do canal.
- ⚠️ Ambas as plataformas caem igualmente na etapa de abertura → o problema é sua mensagem: criativo, tempo ou relevância.
- ⚠️ Um fabricante cai desproporcionalmente → você encontrou um problema específico do OEM.
- ⚠️ A entrega está boa, mas as aberturas são baixas em todos os dispositivos → verifique suas configurações de prioridade/importância. Você pode estar enviando mensagens de ALTA prioridade em um canal de importância PADRÃO, o que significa que elas chegam rapidamente, mas aparecem silenciosamente.
3. Evite perdas futuras
Combine prioridade com importância. Mensagens sensíveis ao tempo (vendas relâmpago, alertas de segurança) → ALTA prioridade, ALTA importância. Conteúdo não urgente (resumos, dicas) → NORMAL/PADRÃO.
Não defina tudo como ALTO — isso é um atalho para os usuários silenciarem seus canais completamente.
Aplique limites de frequência e horários de silêncio. O excesso de mensagens é o caminho mais rápido para um canal silenciado. Defina limites de frequência por canal e respeite os fusos horários locais com horários de silêncio. Isso não corrige a entrega — a protege.
Use o push silencioso com sabedoria. As notificações push silenciosas permitem que você atualize o conteúdo do aplicativo e sincronize dados em segundo plano sem alertas visíveis ao usuário. Esta é uma ferramenta poderosa para manter seu aplicativo atualizado — mas também tem suas próprias restrições de entrega em OEMs com otimização de bateria.
Construa uma jornada de fallback. Esta é sua rede de segurança. Se uma notificação push não for aberta em N horas, acione um acompanhamento por um canal diferente — mensagem no aplicativo, e-mail ou SMS. Isso o protege contra falhas de entrega de OEM, canais silenciados e segmentos de baixo engajamento.
Corrija sua entrega de push no Android com a Pushwoosh
O objetivo é um ciclo repetível: segmentar → medir → identificar o ponto de falha → corrigir a camada certa. Não o criativo quando o problema é a entrega. Não a entrega quando o problema é o criativo.
Pronto para começar? Crie seu primeiro segmento na Pushwoosh para testar onde seu funil realmente quebra.
