MarketingArtigo
Notificação push no site da loja virtual: como funciona e quando vale ativar
Em resumo
Notificação push é o aviso curto que um site envia para o celular ou o computador de quem autorizou o envio, mesmo com o site fechado. O texto explica como esse aviso sai da loja virtual e chega ao aparelho, o que muda no iPhone, em que momento pedir a autorização do visitante e em que casos o canal faz sentido para a loja.
Notificação push é o aviso curto que um site envia para o celular ou o computador de quem autorizou o envio. O aviso chega mesmo quando a pessoa não está com o site aberto. Na loja virtual, ele serve para dizer que o pedido saiu para entrega ou que um produto esgotado voltou ao estoque.
Este texto explica como a notificação push do navegador funciona, o que muda no iPhone, em que momento pedir a autorização do visitante e em que casos o canal faz sentido para uma loja pequena ou média. A parte técnica vem do web.dev, o site de documentação do Google para quem desenvolve sites, e do blog do WebKit, o motor do navegador Safari, da Apple. As páginas foram lidas em 9 de outubro de 2026.
O que é notificação push do navegador?
O nome junta duas tecnologias. Segundo a visão geral do web.dev, a mensagem push é o que permite ao servidor do site mandar uma informação ao usuário mesmo quando ele não está usando o site. A notificação é o que mostra essa informação na tela do aparelho. Na prática, diz a página, as duas costumam ser usadas juntas.
A mesma página resume para que o canal serve. Para o usuário, é um jeito de receber informação oportuna, relevante e precisa. Para o dono do site, é um jeito de aumentar o engajamento, isto é, de fazer o visitante voltar e interagir. A página traz também um aviso: usar o push para conteúdo que o usuário não considera oportuno, relevante e preciso tende a irritar e a reduzir o engajamento.
A diferença para o e-mail está no cadastro. Na descrição do web.dev, o visitante autoriza o envio no próprio navegador, e o navegador devolve ao site um registro técnico da inscrição. Esse registro traz o endereço do serviço que fará a entrega e as chaves usadas para proteger a mensagem. A página não inclui e-mail nem telefone entre as etapas. Quem quer comparar com o canal de e-mail encontra os fluxos básicos no artigo sobre e-mail marketing para e-commerce.
Como o aviso sai da loja e chega ao aparelho?
O caminho descrito pelo web.dev pode ser resumido em quatro passos:
- Permissão. O site pede autorização para enviar notificações. Segundo a página, o pedido precisa partir de um gesto do usuário, como o clique em um botão de aceite. Depois disso, o navegador ou o sistema do aparelho costuma mostrar a própria janela de confirmação.
- Inscrição. Com a permissão dada, o site inscreve o navegador daquele visitante e recebe o registro da inscrição. O site guarda esse registro em um servidor que ele controla.
- Envio. O servidor da loja não fala direto com o aparelho. Ele manda a mensagem a um serviço de push, controlado pelo fornecedor do navegador do visitante. O serviço confere quem enviou e encaminha a mensagem ao aparelho certo.
- Exibição. O navegador recebe a mensagem e aciona um pequeno programa do site que roda em segundo plano, chamado service worker. É esse programa que mostra a notificação, mesmo com o site fechado.
Três detalhes dessa página interessam ao lojista. O primeiro: se o aparelho estiver sem conexão, o serviço de push guarda a mensagem na fila até o navegador voltar a ficar on-line ou até a mensagem expirar. O segundo: quem envia pode definir por quanto tempo o serviço deve tentar a entrega. A página dá o exemplo de uma mensagem que deixa de ser tentada depois de 10 minutos. O terceiro: os dados enviados precisam ser criptografados, de modo que o serviço de push não consiga ler o conteúdo.
Esse tempo de tentativa importa para a loja porque um aviso de oferta que termina hoje não deve chegar amanhã. Na avaliação do ConnectWeek, vale perguntar ao fornecedor da ferramenta de push como esse tempo é configurado.
A página do web.dev descreve o caminho para quem programa o próprio site. A loja montada em plataforma pronta depende de a plataforma, ou de um aplicativo ligado a ela, oferecer o recurso. Este texto não compara fornecedores.
A notificação push de site funciona no iPhone?
Funciona, com uma condição. O blog do WebKit informa que, a partir das versões 16.4 do iOS e do iPadOS, os sistemas do iPhone e do iPad, a notificação push de sites passou a valer para os sites que o usuário adicionou à Tela de Início, a tela principal do aparelho, onde ficam os ícones dos aplicativos. O site adicionado ganha um ícone. Segundo o texto, que é de fevereiro de 2023, ele abre como um aplicativo, fora do navegador, quando o site traz o arquivo de configuração que pede esse comportamento, chamado manifesto. É para esse caso que o texto anuncia a notificação push. Essa exigência do manifesto mudou depois. Segundo outro texto do blog do WebKit, de setembro de 2025, no iOS 26 e no iPadOS 26 todo site adicionado à Tela de Início passa a abrir como aplicativo por padrão, mesmo sem o manifesto.
Segundo o texto de fevereiro de 2023, o site adicionado só pode pedir a permissão em resposta a uma ação direta do usuário, como o toque em um botão de inscrição. Depois de autorizadas, as notificações aparecem na tela bloqueada e na central de notificações do aparelho. O usuário controla a permissão nos ajustes de notificações, como faz com qualquer aplicativo.
O texto de 2023 acrescenta que se trata do mesmo padrão de push da web que chegou antes ao Safari 16.1 no macOS Ventura, o sistema dos computadores da Apple. Diz também que o site não precisa ser membro do programa de desenvolvedores da Apple para usar o recurso.
Na leitura do ConnectWeek, a consequência para a loja é esta: no iPhone, o visitante que só navega pelo Safari, sem adicionar o site à Tela de Início, fica fora do alcance das notificações push do site. A loja que tem muitos clientes com iPhone deve levar isso em conta antes de contar com o canal.
Qual é o momento certo de pedir a permissão?
O artigo do web.dev sobre a experiência do pedido de permissão descreve quatro padrões. O quadro resume cada um. A coluna “na loja” é sugestão do ConnectWeek, exceto onde o próprio artigo traz o exemplo.
| Padrão | Como funciona, segundo o web.dev | Na loja |
|---|---|---|
| Oferta com benefício claro (no artigo, “proposta de valor”) | O convite aparece em um momento em que a vantagem é evidente para o usuário. | Exemplos do próprio artigo: depois de concluída a compra, oferecer avisos sobre a entrega; em produto esgotado, oferecer o aviso de quando ele voltar. |
| Permissão em duas etapas (no artigo, “permissão dupla”) | Primeiro o site mostra uma caixa própria, que explica para que servem os avisos e tem botões de aceitar e de dispensar. Só depois do aceite aparece a janela oficial do navegador. | Caixa da loja com o texto do convite e dois botões, exibida antes da janela do navegador. |
| Painel de configurações | A opção de ligar e desligar os avisos fica em uma área de ajustes do site, fora do caminho principal. | Chave de liga e desliga na área “Minha conta”. |
| Abordagem passiva | Um botão fixo, no mesmo lugar em todas as páginas, liga e desliga os avisos. O artigo cita um botão no rodapé. | Botão “Receber avisos da loja” no rodapé. |
O mesmo artigo aponta a pior prática: mostrar o pedido de permissão assim que a pessoa entra no site. Nesse momento, diz o texto, o visitante não sabe por que a permissão está sendo pedida e pode nem saber o que o site oferece. O pedido ainda atrapalha o que ele tinha ido fazer.
O convite de aviso é só uma parte da página do produto em falta. O restante está no artigo sobre o que fazer com a página do produto esgotado.
O que acontece se o visitante bloquear?
O bloqueio é difícil de desfazer. De acordo com o artigo do web.dev, se o usuário bloquear o pedido de permissão, o site não pode pedir de novo. Para voltar atrás, a pessoa precisa mudar a permissão nas configurações do navegador, o que o texto descreve como um caminho nada fácil nem óbvio.
É por isso que o artigo descreve o padrão em que a caixa da própria loja aparece antes da janela oficial do navegador. Se o visitante dispensa a caixa da loja, o site não corre o risco de ser bloqueado, e o artigo pede que a escolha seja respeitada. Na leitura do ConnectWeek, isso deixa aberta a possibilidade de um novo convite em outro contexto. Se ele bloqueia na janela do navegador, a loja perde a chance.
O artigo pede ainda que o site ofereça uma saída: explicar como desativar os avisos e ter um lugar para isso. Sem essa saída, afirma o texto, o usuário pode recorrer ao bloqueio definitivo.
Quando vale ativar na loja?
A resposta abaixo é avaliação do ConnectWeek, construída sobre o critério do web.dev de que o aviso precisa ser oportuno, relevante e preciso. Não há número de resultado nela, porque as páginas consultadas não trazem nenhum.
O canal tende a servir quando a loja tem avisos que o cliente quer receber na hora:
- mudança no andamento do pedido, como “saiu para entrega”;
- volta de um produto que o cliente pediu para acompanhar;
- queda de preço de um item que o cliente marcou;
- começo de uma promoção com hora marcada, para quem pediu o lembrete.
O canal tende a não servir quando a loja só teria o mesmo anúncio genérico para mandar a todos, várias vezes por semana. Na leitura do ConnectWeek, esse uso cai no aviso do web.dev sobre o conteúdo que o usuário não considera oportuno, relevante e preciso.
Antes de contratar uma ferramenta, o ConnectWeek sugere três perguntas:
- Que aviso a loja enviaria nesta semana que o cliente agradeceria por receber?
- Quem na equipe vai escrever os avisos e decidir a frequência?
- A plataforma da loja permite escolher em que página e em que momento o convite aparece?
Se a primeira pergunta ficar sem resposta, é melhor adiar. A notificação push também não substitui as mensagens que a loja já envia depois da compra. O artigo sobre as mensagens de pós-venda mostra essa sequência, e o artigo sobre carrinho abandonado mostra a recuperação por e-mail.
Textos prontos para a caixa de convite
Os modelos abaixo são sugestões do ConnectWeek para a caixa própria da loja, a que aparece antes da janela do navegador. Cada um diz qual aviso a pessoa vai receber e tem um botão para recusar.
- Depois da compra: “Quer receber um aviso neste aparelho quando o seu pedido sair para entrega?” Botões: “Quero receber” e “Agora não”.
- Produto esgotado: “Este produto está em falta. Quer ser avisado neste aparelho quando ele voltar?” Botões: “Avisar quando voltar” e “Não, obrigado”.
- Lembrete de promoção: “A promoção começa na sexta-feira, às 8h. Quer um lembrete neste aparelho na hora da abertura?” Botões: “Quero o lembrete” e “Agora não”.
Em qualquer dos três, a loja deve ter um lugar para desligar os avisos e explicar como fazer isso, como pede o artigo do web.dev sobre o pedido de permissão. O ConnectWeek sugere o rodapé ou a área “Minha conta”.
Comece por aqui Novo no assunto? Leia primeiro o que é e-commerce, o texto-base desta cobertura.
Fonte: web.dev (Google): Visão geral das notificações push
Perguntas frequentes
Vale ativar notificação push no site da loja?
Na avaliação do ConnectWeek, vale quando a loja tem avisos que o cliente quer receber na hora, como a saída do pedido para entrega ou a volta de um produto esgotado. O web.dev, site de documentação do Google para quem desenvolve sites, alerta que usar a notificação push para conteúdo que o usuário não considera oportuno, relevante e preciso tende a irritar e a reduzir o engajamento, isto é, a volta e a interação do visitante com o site.
A loja precisa do e-mail do cliente para enviar notificação push?
A descrição que o web.dev, site de documentação do Google, faz do envio de uma notificação push não inclui e-mail nem telefone em nenhuma etapa. O visitante autoriza o envio no próprio navegador. O navegador devolve ao site um registro técnico da inscrição, com o endereço do serviço que fará a entrega e as chaves que protegem a mensagem. É esse registro que a loja guarda para enviar os avisos.
Notificação push de site funciona no iPhone?
A notificação push de site funciona no iPhone, com uma condição. Segundo o blog do WebKit, o motor do Safari, navegador da Apple, o recurso existe desde a versão 16.4 do iOS, o sistema do iPhone. Ele vale só para os sites que o usuário adicionou à Tela de Início, a tela principal do aparelho, e que abrem como aplicativo. O pedido de permissão só pode aparecer em resposta a uma ação direta do usuário, como o toque em um botão de inscrição.
O que acontece se o visitante bloquear as notificações do site?
Segundo o web.dev, site de documentação do Google, se o usuário bloquear o pedido de permissão de notificações, o site não pode pedir de novo. Para voltar atrás, a pessoa precisa mudar a permissão nas configurações do navegador. Por isso o web.dev descreve a alternativa de mostrar primeiro uma caixa do próprio site, que explica para que servem os avisos, e só depois a janela oficial do navegador.