A maioria dos guias de push foca nas mensagens que o usuário vê. As notificações push silenciosas são as que ele nunca vê — e fazem um trabalho completamente diferente.
Um push silencioso acorda seu app em background, executa uma tarefa e o coloca de volta para dormir. Sem alerta, sem som, sem badge. O usuário abre o app e encontra conteúdo novo já carregado. Ele nem percebe que houve um push. E é exatamente esse o objetivo.
Este guia mostra como as notificações push silenciosas funcionam no Android e no iOS, como fica a implementação no código e como usá-las de forma estratégica dentro da automação da jornada do cliente. No caminho, você vê como o Pushwoosh lida com a entrega de push silencioso entre plataformas e integra tudo em fluxos automatizados.
Leitura relacionada: Notificações push para mobile: como funcionam | O que são notificações push?
O que são notificações push silenciosas?
Notificações push silenciosas são mensagens iniciadas pelo servidor que acordam um app em background sem exibir nada para o usuário. Sem alerta, sem som, sem badge. O sistema operacional recebe o push, ativa o app brevemente, o app executa sua tarefa em background e volta a dormir.
O contraste com um push padrão é simples: um push visível é uma mensagem para o usuário; um push silencioso é uma instrução para o app.
O que um app consegue fazer nesses segundos em background?
- Buscar conteúdo novo. Puxar os últimos artigos, o catálogo de produtos atualizado ou o feed renovado para que tudo esteja pronto quando o usuário abrir o app.
- Sincronizar dados. Atualizar o estado local com mudanças que aconteceram no servidor ou em outros canais — uma compra feita no site, uma mudança de status num sistema de backend.
- Avaliar localização. Verificar se o usuário entrou ou saiu de uma geofence sem precisar de uma notificação visível como gatilho.
- Atualizar tags ou dados de segmento. Enviar os últimos sinais comportamentais de volta para o CDP, mantendo a segmentação precisa.
- Pré-carregar conteúdo para uma futura notificação visível. Preparar uma mensagem in-app ou um payload de rich push para que ele renderize instantaneamente quando disparado.
O valor prático: o usuário abre um app que já está atualizado. Sem spinner de carregamento, sem dados velhos. Essa percepção de velocidade e frescor tem efeito mensurável na retenção — mesmo quando o usuário não consegue explicar por que o app parece bom de usar. Num mercado dominado por Android com aparelhos de entrada (Samsung Galaxy A, Motorola Moto G) e conexões instáveis, ter o conteúdo já carregado faz ainda mais diferença.
Como funcionam as notificações push silenciosas
A cadeia de entrega é a mesma de uma notificação push normal: seu servidor envia um payload para o APNs (iOS) ou FCM (Android), o serviço entrega ao dispositivo, o sistema operacional age sobre ele. O que muda é a estrutura do payload e o que o SO faz quando ele chega.
O fluxo de entrega
- Servidor envia o payload. Seu backend ou o Pushwoosh envia uma mensagem especialmente construída para o APNs ou FCM.
- Serviço entrega ao dispositivo. APNs ou FCM roteia o payload para o dispositivo correto usando o device token armazenado.
- O SO acorda o app. Ao reconhecer as flags de push silencioso no payload, o SO ativa o app brevemente em background.
- O app executa a tarefa em background. Seu código roda: busca dados, sincroniza estado, checa localização, atualiza uma tag.
- O app sinaliza a conclusão. No iOS, o app chama um completion handler. No Android,
onMessageReceived()retorna. O SO coloca o app de volta para dormir.
A janela de execução em background é limitada. O iOS dá aproximadamente 30 segundos. No Android, varia conforme o dispositivo e o estado de energia. Tarefas em background precisam ser rápidas ou desenhadas para funcionar dentro dessas restrições.
Diferenças de payload: iOS vs. Android
| Parâmetro | iOS (APNs) | Android (FCM) |
|---|---|---|
| Como marcar como silencioso | content-available: 1 no dicionário aps; sem chaves alert/sound/badge | Mensagem data-only: payload data presente, sem objeto notification |
| Headers APNs/FCM | apns-push-type: background; apns-priority: 5 | priority: normal (padrão) ou high para tarefas sensíveis ao tempo |
| Limite de tempo em background | ~30 segundos; precisa chamar completionHandler | onMessageReceived roda na main thread; descarregue trabalho pesado |
| Throttling do SO | Limitado se enviado mais de ~3/hora ou muito próximos entre si | Doze mode e App Standby restringem a entrega em background |
| Handler principal | application(_:didReceiveRemoteNotification:fetchCompletionHandler:) | onMessageReceived() no FirebaseMessagingService |
| Visibilidade ao usuário | Nenhuma — sem alerta, som ou badge | Nenhuma — nenhuma notificação exibida |
O erro mais comum no iOS é esquecer de definir apns-priority: 5 junto com apns-push-type: background. Se a prioridade for 10 (o padrão de pushes visíveis), a Apple pode rejeitar a mensagem ou exibi-la visualmente, mesmo sem corpo de alerta. A prioridade baixa é o que sinaliza ao APNs que isso é uma tarefa em background, e não uma notificação urgente.
No Android, a regra crítica é mais simples: nada de objeto notification no payload do FCM. Se houver um objeto notification, o Android trata como notificação push normal e a exibe. Push silencioso = só data.
Implementação no Android
Como o Brasil é um mercado majoritariamente Android (mais de 85% dos dispositivos), faz sentido começar por aqui — é onde está a maior parte da sua base de usuários.
Configuração do FCM e manifest
Adicione o FirebaseMessagingService ao seu AndroidManifest.xml:
<service android:name=".MyFirebaseMessagingService" android:exported="false"> <intent-filter> <action android:name="com.google.firebase.MESSAGING_EVENT" /> </intent-filter></service>Tratando mensagens data em Kotlin
Estenda FirebaseMessagingService e implemente onMessageReceived:
class MyFirebaseMessagingService : FirebaseMessagingService() {
override fun onNewToken(token: String) { // O SDK Android do Pushwoosh cuida do envio do token automaticamente }
override fun onMessageReceived(remoteMessage: RemoteMessage) { // Push silencioso = só payload data, sem objeto notification if (remoteMessage.data.isNotEmpty() && remoteMessage.notification == null) { handleSilentPush(remoteMessage.data) } }
private fun handleSilentPush(data: Map<String, String>) { when (data["update_type"]) { "content_refresh" -> { // Busca conteúdo novo do seu servidor refreshContentFeed(data["content_id"]) } "segment_update" -> { // Envia tags atualizadas para o Pushwoosh syncUserSegmentData() } "location_check" -> { // Avalia o status atual da geofence evaluateGeofences() } } }}Payload FCM para push silencioso
O payload deve conter um objeto data e nenhum objeto notification:
{ "to": "DEVICE_TOKEN", "data": { "update_type": "content_refresh", "content_id": "latest_news_feed" }}Defina a prioridade como ‘high’ apenas para tarefas em background sensíveis ao tempo. A prioridade padrão é suficiente para a maioria dos casos de atualização de conteúdo e evita impacto desnecessário na bateria.
Implementação no iOS
Configuração no Xcode
Habilite Background Modes no Xcode antes de escrever qualquer código:
- Abra seu projeto e selecione o target do seu app.
- Vá em ‘Signing & Capabilities’ e clique em ’+ Capability’.
- Adicione ‘Background Modes’ e marque ‘Remote Notifications’.
Seu App ID no Apple Developer Portal precisa ter Push Notifications habilitado. Regenere seus provisioning profiles depois de fazer essa mudança.
Registrando para notificações remotas
Pushes silenciosos ainda exigem o registro do dispositivo no APNs. Trate isso no AppDelegate:
import UIKitimport UserNotifications
@UIApplicationMainclass AppDelegate: UIResponder, UIApplicationDelegate {
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
UNUserNotificationCenter.current().delegate = self UNUserNotificationCenter.current().requestAuthorization( options: [.badge, .sound, .alert] ) { granted, _ in if granted { DispatchQueue.main.async { application.registerForRemoteNotifications() } } } return true }
func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) { let token = deviceToken.map { String(format: "%02.2hhx", $0) }.joined() // O SDK iOS do Pushwoosh cuida do envio do token automaticamente }}Tratando o push silencioso
Este é o método que o iOS chama quando um push silencioso chega:
extension AppDelegate {
func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable: Any], fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) {
guard let aps = userInfo["aps"] as? [String: AnyObject], aps["content-available"] as? Int == 1 else { completionHandler(.noData) return }
// Execute sua tarefa em background aqui fetchLatestContent { success in completionHandler(success ? .newData : .noData) } }}Sempre chame completionHandler antes que a janela de 30 segundos se feche. Se não fizer isso, o iOS pode encerrar o app e aplicar throttling em pushes silenciosos futuros. Passe .newData se buscou algo, .noData se nada mudou, .failed se a tarefa deu erro.
Payload APNs para push silencioso
{ "aps": { "content-available": 1 }, "update_type": "content_refresh", "content_id": "latest_feed"}Headers APNs obrigatórios junto com esse payload:
- apns-push-type: background
- apns-priority: 5
Push silencioso multiplataforma com o Pushwoosh
Gerenciar push silencioso manualmente entre iOS e Android significa manter dois formatos de payload separados, dois conjuntos de headers de entrega e duas integrações de SDK. O Pushwoosh abstrai tudo isso.
Quando você dispara um push silencioso pelo Pushwoosh — pela interface ou pela API — a plataforma gera o payload correto para cada plataforma de destino automaticamente. O APNs recebe content-available: 1 com os headers certos. O FCM recebe uma mensagem data-only. Você configura a campanha uma única vez.
O gerenciamento de device tokens é centralizado. Tokens iOS, tokens Android e assinaturas de web push ficam todos armazenados e atualizados num só lugar. Quando um token muda (reinstalação, upgrade de SO), o Pushwoosh cuida da renovação.
Para os membros não técnicos do time, o Pushwoosh oferece uma interface para agendar e disparar pushes silenciosos sem escrever payload. Isso torna prático integrar pushes silenciosos a fluxos do Customer Journey Builder junto com notificações visíveis e mensagens in-app.
Casos de uso estratégicos
As notificações push silenciosas são mais valiosas quando a visibilidade jogaria contra você. Estes são os cenários em que elas se encaixam melhor do que um push padrão.
| Caso de uso | O que o push silencioso dispara | Por que é melhor que um push visível |
|---|---|---|
| Pré-busca de conteúdo | O app busca novos artigos, produtos ou itens do feed | Usuário abre o app com conteúdo fresco; sem tela de carregamento |
| Avaliação de geofence | O app checa a localização do usuário vs. geofences salvas | A checagem de localização acontece sem notificação visível; mensagem in-app ou push local dispara só se as condições baterem |
| Atualização de segmento | O app envia tags ou eventos atualizados ao Pushwoosh | Os dados de segmentação seguem precisos após atividade fora do app (ex.: compra no site) |
| Preparo de pré-entrega | O app pré-carrega mensagem in-app ou tela de oferta | Notificação visível ou mensagem in-app aparece instantaneamente, sem lag |
| Recálculo de RFM | O app envia os últimos dados de compra/atividade ao CDP | Usuário entra no segmento RFM correto em tempo real; campanhas de follow-up disparam com precisão |
Pré-busca de conteúdo para apps de notícias e mídia
Um app de notícias que envia um alerta de última hora ganha muito com um push silencioso enviado 30 segundos antes. O push silencioso acorda o app, que busca a matéria e a guarda em cache localmente. Quando o alerta visível dispara, tocar nele abre a matéria instantaneamente. Sem espera para a notícia carregar.
Para apps com feeds personalizados, um push silencioso nos horários típicos de despertar pré-busca o conteúdo da manhã antes de o usuário abrir o app. O app parece rápido porque ele é rápido — os dados já estão lá.
Avaliação de geofence sem gatilho visível
Um usuário passa perto de uma loja. A abordagem padrão: enviar uma notificação push baseada em localização. O problema: o usuário precisa estar opt-in, o timing pode estar errado, e ele pode se sentir rastreado.
A abordagem com push silencioso: o servidor envia um push silencioso quando o usuário está dentro de uma região. O app checa a geofence precisa no lado do cliente. Se as condições baterem, o app ativa uma mensagem in-app ou uma notificação local no momento certo. A comunicação visível só acontece se a lógica passar — e não como o gatilho em si.
Mantendo os dados de segmento precisos após atividade fora do app
No Brasil, o PIX é o método de pagamento número um, e boa parte das compras acontece fora do app — no site ou via Mercado Pago. Quando um usuário faz uma compra pelo site, o segmento RFM dele deveria atualizar na hora. Mas o app não sabe disso até ele abrir.
Um push silencioso enviado após a compra na web acorda o app em background, que sincroniza o último evento de compra com o Pushwoosh. O usuário entra no segmento RFM correto em tempo real. Uma campanha de follow-up — recompensa de fidelidade, cross-sell, sequência de agradecimento, ou um upsell pós-PIX — dispara com base em dados precisos.
Leitura relacionada: Guia de segmentação RFM | Notificações push enriquecidas
Pré-carregando conteúdo para mensagens in-app
Mensagens in-app que dependem de uma busca no servidor para renderizar podem ter lag perceptível. Um push silencioso enviado antes do momento em que se espera disparar a mensagem in-app pré-busca o conteúdo e o guarda localmente. Quando a mensagem dispara, ela aparece imediatamente.
Esse padrão funciona bem para fluxos de onboarding, anúncios de funcionalidades e overlays promocionais em que o conteúdo é personalizado e não pode ser embutido no binário do app.
Boas práticas
Respeite os limites de throttling do SO
O iOS limita pushes silenciosos que chegam com frequência demais. A orientação da Apple é de aproximadamente 2 a 3 por hora, ou no máximo um a cada 21 minutos. Apps que excedem isso podem ter seus pushes silenciosos atrasados ou descartados sem nenhum erro.
O Doze mode e o App Standby do Android restringem a execução em background quando o dispositivo está ocioso. Mensagens FCM de alta prioridade conseguem acordar o app durante o Doze, mas devem ser usadas com critério. Mensagens de prioridade padrão são adiadas até o dispositivo sair do Doze.
A regra prática: envie pushes silenciosos só quando a tarefa em background for realmente sensível ao tempo. Pré-buscar conteúdo uma vez numa cadência natural (de manhã, ou após uma atualização do servidor) está ótimo. Enviar a cada 10 minutos para manter os dados frescos não está.
Mantenha os payloads pequenos e as tarefas rápidas
O payload do push silencioso deve ser um sinal, não uma transferência de dados. Envie o mínimo necessário para dizer ao app o que buscar e onde. A busca de fato dos dados acontece dentro do app depois que o push chega.
Tarefas em background devem terminar bem dentro do limite de tempo. Se uma tarefa exige mais do que alguns segundos, projete-a para ser interrompível: salve o progresso, chame o completion handler e retome na próxima oportunidade. Tarefas longas em background arriscam o encerramento pelo SO e podem afetar a bateria a ponto de o usuário perceber.
Teste em diferentes estados de energia e variantes de OEM
O comportamento do push silencioso varia bastante entre os OEMs Android — e isso é especialmente relevante no Brasil, onde aparelhos Samsung, Xiaomi e Motorola dominam as prateleiras. Samsung, Xiaomi, Huawei e OnePlus têm otimização de bateria agressiva que pode impedir totalmente a execução em background de apps que não estão na whitelist. Teste em dispositivos reais desses fabricantes, e não só em emuladores de Android puro.
No iOS, teste em modo de baixo consumo e com o app forçado a fechar. A entrega de push silencioso nesses estados é menos confiável, e sua lógica de background deve lidar com o caso em que a tarefa não rodou antes de o usuário abrir o app.
Acompanhe a efetividade pelos eventos subsequentes
Pushes silenciosos não geram métricas de clique. Acompanhe a efetividade deles pelos eventos que deveriam disparar: content_refreshed, segment_updated, geofence_evaluated. Se esses eventos pararem de disparar na taxa esperada após uma campanha de push silencioso, ou a entrega está sofrendo throttling, ou o handler de background está falhando.
O Pushwoosh Analytics mostra os eventos do app junto com os dados de campanha. Mapeie os eventos de conclusão da sua tarefa em background com os envios de push silencioso para confirmar que o pipeline está funcionando.
Integre à automação de jornada, não a envios avulsos
Um push silencioso enviado isoladamente é uma operação técnica. Um push silencioso embutido numa Customer Journey é uma operação estratégica. Os padrões mais úteis usam pushes silenciosos como um passo que viabiliza uma interação visível melhor lá na frente: atualize o segmento antes do push promocional, pré-busque o conteúdo antes da mensagem in-app, avalie a geofence antes do alerta baseado em localização.
O Customer Journey Builder do Pushwoosh suporta pushes silenciosos como passos da jornada, junto com notificações visíveis e mensagens in-app.
Melhore o frescor do app e a precisão das campanhas com o Pushwoosh
As notificações push silenciosas são a camada de infraestrutura por baixo de experiências de usuário melhores. Conteúdo fresco na abertura, dados de segmento precisos, interações disparadas por geofence sem fricção — nada disso funciona de forma confiável sem atualizações do app em background.
O Pushwoosh cuida da entrega de push silencioso entre plataformas, da formatação do payload, do gerenciamento de tokens e da integração com a Customer Journey. Os devs ganham abstrações de SDK limpas; os times de marketing ganham o push silencioso como um passo de primeira classe em fluxos automatizados. E com certificação SOC 2 Type I e ISO 27001:2022, conformidade com GDPR e HIPAA e data centers na UE e nos EUA, sua infraestrutura de mensageria vem com segurança enterprise embutida — um diferencial importante para times de FinTech que lidam com dados sensíveis.
Artigos relacionados
Ver todos