Notificações push na web: como funcionam e como usar bem

As notificações push na web são o único canal de marketing em que uma decisão de design ruim pode trancar você para fora de um cliente para sempre. Peça permissão no momento errado, a pessoa clica em Bloquear, e aquele navegador está fechado para você definitivamente. Sem novo pedido, sem segunda campanha, sem e-mail de reconquista. Essa assimetria é o motivo pelo qual vale entender o mecanismo antes de escrever uma única mensagem.

O que são notificações push na web

Uma notificação push na web é uma mensagem enviada do seu servidor para o navegador de um inscrito, exibida pela central de notificações do sistema operacional e entregue mesmo com o seu site fechado. Essa última parte é o ponto central: diferente de um popup na página, o push na web alcança alguém que não está olhando para o seu site naquele momento.

Ele é construído a partir de três APIs da plataforma web trabalhando juntas, e a divisão entre elas explica quase todo o comportamento do canal: a Service Worker API, a Push API e a Notifications API.

Como o push na web funciona por baixo do capô

O service worker

Um service worker é um worker JavaScript que atua como proxy entre o seu web app, o navegador e a rede. Ele roda na própria thread, não tem acesso ao DOM e continua existindo depois que a página que o registrou é fechada. Essa persistência é o que permite receber uma mensagem push e exibir uma notificação quando ninguém tem a sua aba aberta. Service workers só rodam em contextos seguros, ou seja, HTTPS, com http://localhost tratado como seguro para desenvolvimento.

A inscrição: um endpoint mais duas chaves

Assim que um service worker está ativo, a página chama registration.pushManager.subscribe(). O navegador conversa com o serviço de push do próprio fabricante e devolve um PushSubscription contendo:

• endpoint, uma URL de capacidade única na qual o serviço de push aceita mensagens
• keys.p256dh, uma chave pública Elliptic Curve Diffie-Hellman na curva P-256
• keys.auth, um segredo de autenticação

Seu servidor guarda os três e trata o endpoint como um segredo, porque quem o tiver em mãos consegue enviar para aquele inscrito. As chaves existem porque os payloads são criptografados de ponta a ponta. A RFC 8291 especifica como: uma troca ECDH na P-256 estabelece um segredo compartilhado, o HKDF deriva chaves a partir dele, e o payload é selado com AES-128-GCM sob a codificação de conteúdo aes128gcm. O serviço de push repassa um texto cifrado que ele não consegue ler.

O serviço de push

Você não envia mensagens push diretamente para um aparelho. Você as envia para um serviço de push operado pelo fabricante do navegador: os endpoints do FCM do Google para o Chrome, o autopush da Mozilla para o Firefox, o serviço de push da Apple para o Safari. A RFC 8030, “Generic Event Delivery Using HTTP Push”, define o protocolo. Seu servidor faz um POST para o endpoint da inscrição, e o serviço de push cuida das partes difíceis da entrega em celulares: uma conexão eficiente em bateria com o aparelho, fila enquanto ele está offline, e acordar o navegador quando uma mensagem chega. É também por isso que a entrega não pode ser garantida. Se o aparelho ficar desligado tempo suficiente, as mensagens expiram conforme o TTL e são descartadas.

VAPID: provando quem está enviando

O endpoint ser um segredo é uma segurança frágil. A RFC 8292 acrescenta a Voluntary Application Server Identification, ou VAPID, para que um serviço de push consiga dizer de qual servidor de aplicação a mensagem veio.

Você gera um par de chaves ECDSA na curva NIST P-256 uma vez. A chave pública entra em applicationServerKey quando o navegador se inscreve, amarrando a inscrição ao seu servidor. A cada envio, seu servidor manda um JWT assinado com a chave privada correspondente usando ES256, carregando uma claim aud para a origem do serviço de push, uma claim exp de no máximo 24 horas e, opcionalmente, uma claim sub com dados de contato. O serviço de push verifica a assinatura, então um endpoint roubado sozinho já não basta para enviar spam aos seus inscritos.

O caminho da entrega, de ponta a ponta

1. A página registra um service worker e, depois que a permissão é concedida, chama subscribe() com a sua chave pública VAPID.
2. Seu servidor guarda o endpoint e as chaves devolvidos junto ao registro do inscrito.
3. Para enviar, seu servidor criptografa o payload com p256dh e auth, assina um JWT VAPID e faz POST no endpoint.
4. O serviço de push autentica a requisição e entrega a mensagem criptografada.
5. O navegador acorda o service worker com um evento push, que descriptografa o payload e chama ServiceWorkerRegistration.showNotification().
6. Um clique dispara notificationclick no service worker, onde você abre a URL de destino.

Por que o modelo de permissão é tão rígido

Olhe o que uma inscrição concede: um processo em segundo plano que roda sem o seu site estar aberto, mais a capacidade de desenhar na superfície de notificações do sistema operacional. Por isso os navegadores colocam uma permissão explícita, por origem, concedida pela pessoa, e a maioria exige que o pedido siga um gesto real de quem está usando.

Uma segunda restrição surpreende as pessoas. Chrome e Edge exigem userVisibleOnly: true na inscrição, uma promessa de que todo push vai produzir uma notificação visível, então pushes silenciosos em segundo plano não são um uso suportado da API. O Firefox também aplica uma cota a mensagens push que não geram notificação.

Suporte de navegadores e plataformas

Segundo o MDN, a Push API está em Baseline amplamente disponível desde março de 2023, o que significa que funciona nas versões atuais de Chrome, Edge, Firefox e Safari no desktop, e no Chrome e no Firefox para Android. Duas ressalvas importam mais que a manchete.

Primeiro, a Notifications API não está disponível de forma uniforme. O MDN a marca como de disponibilidade limitada porque o construtor Notification() lança um TypeError na maioria dos navegadores móveis. Para qualquer coisa que precise funcionar em celular, use notificações persistentes por ServiceWorkerRegistration.showNotification(), que é o caminho de service worker no qual você já está de qualquer forma.

Segundo, as opções de notificação são implementadas de forma desigual. Botões de ação, badges, imagens e requireInteraction variam entre navegadores e sistemas operacionais, então desenhe notificações que ainda se leiam corretamente só com título, corpo e ícone.

A exigência do iOS e do iPadOS

Essa ressalva decide se o push na web é viável para um público majoritariamente móvel, e ela é descrita de forma errada em quase todo lugar.

A Apple adicionou o Web Push no iOS e no iPadOS 16.4, e ele funciona apenas para web apps que foram adicionados à tela de início. Como o WebKit colocou, “estamos adicionando suporte a Web Push para web apps na tela de início”, e “um web app que foi adicionado à tela de início pode pedir permissão para receber notificações push”. A pessoa adiciona pelo menu Compartilhar e “Adicionar à Tela de Início”, e a permissão precisa então ser pedida em resposta a uma interação direta, como tocar em um botão de inscrição.

Um site aberto em uma aba comum do Safari no iPhone não consegue criar uma inscrição de push. Isso é uma barreira real: você está pedindo uma etapa de instalação antes de sequer poder pedir permissão. No macOS é mais fácil, porque o Safari 16.1 no macOS Ventura trouxe Web Push baseado em padrões para sites comuns, sem etapa de instalação.

Um exemplo mínimo de inscrição

Este é todo o fluxo do lado do cliente. Ele pertence a um manipulador de clique, não ao carregamento da página.

async function subscribeToPush(vapidPublicKey) {
  // Push e service workers exigem um contexto seguro (HTTPS).
  if (!("serviceWorker" in navigator) || !("PushManager" in window)) return null;

  const registration = await navigator.serviceWorker.register("/sw.js");

  // Deve ser chamado a partir de um gesto do usuário, e apenas uma vez por usuário.
  const permission = await Notification.requestPermission();
  if (permission !== "granted") return null;

  const subscription = await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: vapidPublicKey, // chave pública P-256 em base64url
  });

  // Persista endpoint + chaves no servidor; trate o endpoint como um segredo.
  await fetch("/api/push/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(subscription),
  });

  return subscription;
}

Dentro de sw.js você trata o evento push, chama self.registration.showNotification(title, options) e trata notificationclick para abrir a URL de destino.

UX de permissão: onde a maioria dos programas falha

Nunca peça no carregamento da página

O Lighthouse tem uma auditoria dedicada a isso: “se a sua página pede permissão para enviar notificações no carregamento, essas notificações podem não ser relevantes para os seus usuários ou para as necessidades deles”. A recomendação é oferecer um tipo específico de notificação e pedir permissão apenas depois que a pessoa optar por aquele tipo. O Safari 12.1 e outros navegadores foram além, exigindo interação com a página antes que um pedido possa sequer ser feito.

Use um pré-pedido suave

Mostre primeiro o seu próprio convite dentro da página. Ele nomeia a proposta de valor, pode ser dispensado sem custo permanente, e só um clique nele dispara o pedido real do navegador. Alguém que ignora o seu pedido suave hoje pode ser perguntado de novo no mês que vem. Alguém que clica em Bloquear, não. Duas regras fazem funcionar: descreva o que você vai realmente enviar em vez de “receba novidades”, e nunca provoque um clique acidental, porque um aceite por engano gera um descadastro imediato.

Peça no contexto

A recomendação do próprio Chrome é “deixe os seus usuários tomarem a iniciativa e ativarem as notificações no ritmo deles”, colocando os controles de forma discreta dentro de superfícies de interface já existentes, e evitando “exibir pedidos e/ou sobreposições sem contexto ou logo depois que a pessoa chega ao site”.

Os momentos que funcionam no comércio são específicos: um controle de “avise-me quando voltar ao estoque” em um produto esgotado, uma página de confirmação de pedido oferecendo atualizações de entrega, um alternador de vigia de preço em um produto visto com frequência. A permissão é trocada por um benefício nomeado, em vez de colhida.

Uma negativa é praticamente permanente

Quando alguém bloqueia notificações, o navegador guarda essa decisão para a sua origem. Chamadas posteriores a Notification.requestPermission() resolvem para o valor denied guardado sem exibir nada, e é por isso que o próprio exemplo do MDN verifica Notification.permission antes de sequer chamar requestPermission(). Reverter um bloqueio significa cavar nas configurações do site, o que praticamente ninguém faz.

O que os navegadores fazem quando você erra

As consequências já não são apenas uma taxa de aceitação baixa.

• O Chrome inscreve automaticamente origens com taxas de aceitação muito baixas em uma interface de permissão mais silenciosa, separadamente por tipo de aparelho, suprimindo o pedido para todo mundo.
• O Chrome limita a taxa de sites que combinam alto volume de push com baixo engajamento, devolvendo HTTP 429. A escalada roda por um dia, depois sete, depois catorze, e só reinicia após 42 dias consecutivos sem interrupções.
• O Chrome agora revoga automaticamente a permissão de notificação de sites com os quais a pessoa não interagiu recentemente, onde há “engajamento muito baixo dos usuários e um alto volume de notificações sendo enviadas”. A justificativa do Google é dura: “menos de 1% de todas as notificações recebem qualquer interação dos usuários”.

Você pode perder inscritos que já havia conquistado simplesmente enviando mal.

O push na web comparado com e-mail e SMS

A diferença de propriedade que muda a estratégia

Uma inscrição de push é uma URL de capacidade presa a um perfil de navegador em um aparelho. Ela não é uma pessoa. O mesmo cliente usando Chrome no notebook e Firefox no celular são duas inscrições sem relação entre si, e você não tem como saber que são o mesmo ser humano a menos que ele se identifique.

Ela também não é portátil. Você consegue exportar uma lista de e-mail e carregá-la em outra plataforma amanhã. Você não consegue mover inscrições de push entre fornecedores, porque as chaves e o vínculo VAPID foram criados contra uma chave de servidor de aplicação específica.

Então trate o push na web como um acelerador sobre um canal próprio, nunca como substituto. Use o momento do push para conquistar um endereço de e-mail ou um número de telefone, não o contrário. O guia completo de automação de marketing cobre como ligar vários canais em uma jornada só.

Casos de uso que funcionam de verdade

O canal recompensa mensagens sensíveis ao tempo, pessoalmente relevantes e acionáveis em um toque.

• Abandono de carrinho. Um push dentro de uma hora, reforçado por um e-mail depois. O guia de e-mail de carrinho abandonado cobre o sequenciamento.
• Avisos de volta ao estoque. O caso mais forte, porque a pessoa pediu explicitamente para ser avisada.
• Queda de preço em itens vigiados. Mesma lógica, relevância escolhida pela própria pessoa.
• Status de entrega e de pedido. Alta intenção de abrir, baixo risco de reclamação.
• Atualizações urgentes em um tema assinado. Notícias, resultados, janelas de disponibilidade.

O que falha é igualmente claro: disparos genéricos de “publicamos um post novo”, ofertas diárias indiferenciadas, qualquer coisa que precise de mais que um título e uma linha, disparos de reengajamento para inscritos que ignoraram as últimas vinte notificações, e conteúdo transacional que exige um registro durável.

Frequência, horário e segmentação

Comece conservador: uma a três notificações por inscrito por semana, ampliando só se as taxas de descadastro e de clique se mantiverem. A fadiga aparece mais rápido que no e-mail, porque silenciar custa um toque em uma notificação que o sistema operacional já colocou na frente da pessoa.

O horário é ao mesmo tempo vantagem e perigo. O push chega imediatamente, então uma mensagem enviada às 02:00 chega às 02:00. Guarde ou infira o fuso horário do inscrito no momento da inscrição e segure os envios dentro de uma janela definida.

A segmentação é limitada pelo que você sabe sobre uma inscrição, e não sobre uma pessoa, então as dimensões viáveis são comportamentais: páginas vistas, produtos vigiados, estado do carrinho, recência de compra, plataforma. O guia de segmentação de clientes aprofunda.

Medindo o push na web

Quatro métricas importam, e elas não são todas mensuráveis do mesmo jeito.

• Entrega. Se o serviço de push aceitou a requisição. Um 201 significa aceito, não entregue. Um 404 ou 410 significa que a inscrição morreu.
• Exibição. Se a notificação foi mostrada. Você só sabe isso se o service worker reportar de volta quando showNotification() resolver.
• Taxa de cliques. Cliques divididos por exibições. É o número que vale otimizar.
• Taxa de descadastro. Cancelamentos e revogações de permissão por envio. Acompanhe com mais atenção que a taxa de cliques, porque é o indicador antecedente da morte do canal.

Armadilhas de atribuição

A atribuição de push se elogia sozinha. A notificação chega em um aparelho que a pessoa já está segurando, então ela costuma levar o crédito por uma sessão que ia acontecer de qualquer forma. Rode grupos de controle em vez de assumir incrementalidade. As exibições são subcontadas enquanto todo clique é registrado, então uma taxa de cliques calculada sobre envios superestima o desempenho. E como uma inscrição é um navegador e não uma pessoa, um push clicado no celular que termina em uma compra no desktop parece dois eventos sem relação. O guia de métricas de e-mail marketing cobre a higiene de medição entre canais.

Consentimento, GDPR e descadastro

O pedido de permissão do navegador é uma barreira técnica. Ele não é automaticamente uma base legal completa para marketing.

Onde você faz marketing para pessoas na União Europeia ou no Reino Unido, trate o push como trata o e-mail. Explique o que você vai enviar antes de o pedido aparecer, para que o consentimento seja informado e específico. Registre quando e onde a inscrição foi criada, e nunca embuta o consentimento de push em uma ação sem relação. Se você amarra inscrições a clientes identificados, esses dados entram nas suas obrigações de dados pessoais, incluindo pedidos de exclusão.

A higiene de descadastro importa igualmente. Ofereça um controle de preferências dentro do site para que as pessoas possam reduzir a frequência em vez de bloquear, chame PushSubscription.unsubscribe() e apague o registro no servidor quando elas fizerem isso, e limpe inscrições diante de um 404 ou 410. A orientação do MDN é curta e correta: as pessoas devem receber “uma forma fácil de optar por não receber mais no futuro”.

Onde o push na web se encaixa em uma pilha de canais

O push na web é um bom terceiro canal e um péssimo primeiro: rápido, gratuito na margem e insuperável para alertas urgentes, mas preso ao aparelho, não exportável e a um clique da perda permanente.

Isso faz da orquestração o problema real. Qual mensagem vai para qual canal, como você suprime o e-mail quando o push já converteu, e como você mantém uma visão única do cliente entre superfícies que identificam pessoas de formas diferentes. A Brevo oferece push na web e no celular ao lado de e-mail e SMS, e a Tajo fica em cima da Brevo para coordenar essa lógica multicanal em lojas Shopify. Para o lado do SMS, veja o guia de automação de SMS.

Principais conclusões

• O push na web são três APIs cooperando: um service worker para execução em segundo plano, a Push API para inscrição e transporte, a Notifications API para exibição. Uma inscrição é um endpoint mais uma chave p256dh e um segredo auth, os payloads são criptografados de ponta a ponta, e o VAPID prova quem envia.
• O push está em Baseline amplamente disponível desde março de 2023, mas no iOS e no iPadOS funciona apenas para web apps adicionados à tela de início.
• Nunca peça permissão no carregamento da página. Use um pré-pedido suave, peça no contexto e lembre que um bloqueio é permanente para aquela origem.
• O Chrome agora impõe pedidos silenciosos, limites de taxa e revogação automática de permissão, então enviar mal custa inscritos que você já tem.
• Uma inscrição é um navegador, não uma pessoa, e não pode ser exportada. Construa a lista de e-mail primeiro e use o push para acelerá-la.