Web push: o que é e por que o Chrome silencia o pedido de permissão

Quase todo mundo já viu a cena: a página mal carregou e aparece, no canto do navegador, a caixinha perguntando se o site pode enviar notificações. A maioria clica em bloquear sem ler, ou fecha a caixa e segue. Para quem está do outro lado, isso parece só uma taxa de conversão ruim. Não é só isso: o navegador está tomando nota.

Este guia explica o que é web push, como ele funciona por dentro e onde ele cabe numa régua de automação. E trata do ponto que os guias de ferramenta não tratam: o pedido de permissão é o único portão do canal, e pedir no momento errado faz o próprio navegador esconder o portão. No fim, há um roteiro para escolher o momento certo na jornada.

O que é web push?

Web push é uma notificação enviada por um site ao navegador de quem autorizou recebê-la. Ela aparece na área de notificações do computador ou do celular, como as de um aplicativo, e pode chegar mesmo que a pessoa não esteja com o site aberto. Um clique na notificação leva de volta à página que o site escolheu.

A diferença para e-mail e WhatsApp está no que o canal pede em troca. Não há cadastro, não há telefone, não há endereço: a pessoa só precisa clicar em “permitir”. Isso torna a inscrição muito mais leve, mas também deixa o canal mais frágil. Quem se inscreveu é um navegador num aparelho, não uma pessoa identificada, e basta um clique nas configurações para a inscrição deixar de existir.

Na prática, o web push serve bem a mensagens curtas, com prazo e com destino claro: o pedido que saiu para entrega, o preço que baixou no produto que a pessoa olhou, o artigo novo de um assunto que ela acompanha, o lembrete de uma consulta marcada. Serve mal a conteúdo longo, a anúncio genérico e a qualquer coisa que a pessoa não esperava receber.

Como funcionam as notificações web push por dentro?

O mecanismo tem três peças. A primeira é um pequeno programa que o site instala no navegador, chamado service worker, que continua disponível mesmo com a aba fechada. A segunda é o serviço de push do próprio navegador, que recebe as mensagens e as entrega ao aparelho certo. A terceira é o servidor do site, ou da ferramenta de push contratada, que decide o que mandar e para quem.

1. A pessoa visita o site e, em algum momento, o site chama o pedido de permissão do navegador.
2. Se ela aceitar, o navegador gera uma inscrição única para aquele site naquele aparelho e o site guarda essa inscrição.
3. Quando há algo a avisar, o servidor do site envia a mensagem ao serviço de push do navegador, usando a inscrição.
4. O serviço entrega a mensagem ao aparelho; o service worker a recebe e exibe a notificação.
5. Se a pessoa clicar, o navegador abre o endereço definido na mensagem — e é aí que entra a medição.

Repare que nada disso acontece sem o passo 1. Não existe forma de inscrever alguém sem a caixa de permissão do navegador, e o site não controla a aparência dessa caixa. Ele controla apenas quando ela é chamada. Todo o resto do canal, da segmentação ao relatório, depende dessa única decisão.

Qual a diferença entre web push, push de aplicativo e outros canais?

Web push e push de aplicativo parecem iguais na tela, mas a origem é outra. O push de aplicativo exige que a pessoa tenha baixado o app da loja; o web push exige só um navegador compatível e um clique. Por isso o web push costuma ser a porta de entrada de empresas que não têm app ou que têm um app com pouca instalação.

Comparativo elaborado pela Alliance Comunicação com base na prática dos canais.

A comparação mostra por que web push não substitui e-mail nem WhatsApp. Ele é o canal mais barato de entrar e o mais fácil de sair, e não carrega identidade. Funciona melhor como uma camada a mais na régua, ligada a gatilhos de comportamento, do que como canal principal de relacionamento.

O que é a interface silenciosa do Chrome?

Em janeiro de 2020, o Chrome anunciou uma mudança que quase nenhum guia de fornecedor menciona: a partir da versão 80, o navegador passou a exibir, em certas condições, uma versão mais discreta do pedido de permissão de notificações. Em vez da caixa que se abre sobre a página, aparece um pequeno aviso na barra de endereço, que a pessoa pode simplesmente nunca notar.

São dois gatilhos diferentes, e vale separá-los. O primeiro é da pessoa: quem costuma negar notificações em vários sites passa a ver a versão silenciosa em todos eles, e isso o site não controla. O segundo é do site: se quase ninguém aceita o pedido daquele domínio, todos os visitantes passam a ver a versão silenciosa, inclusive os que aceitariam. É esse segundo gatilho que transforma um pedido mal posicionado num problema do canal inteiro.

Por que pedir permissão na primeira visita custa a base inteira?

Porque a primeira visita é o momento em que a pessoa menos sabe o que vai receber. Ela chegou por um link, ainda não leu nada, não comprou nada e não tem motivo para querer ser interrompida por aquele site no futuro. O pedido, nesse instante, é uma pergunta sem contexto, e a resposta mais comum a pergunta sem contexto é “não”.

O efeito é cumulativo. Cada recusa piora a taxa de aceitação do domínio. Quando ela cai o suficiente, o Chrome passa a mostrar o pedido silencioso a todos. Com o pedido silencioso, menos gente aceita, porque menos gente vê. O site entra num ciclo em que o canal encolhe sozinho, e a equipe de marketing só percebe pelo número de inscritos parado.

Há um segundo custo, menos visível: a recusa costuma ser definitiva. Quem clicou em bloquear não verá o pedido de novo naquele navegador, a menos que vá às configurações do site e mude a permissão à mão. Pedir cedo demais não só perde a inscrição de hoje: queima a chance de pedir na hora certa, depois.

O pedido de permissão não é um formulário que se otimiza depois. É um voto que o navegador conta.

O que os dados dos navegadores mostram sobre a aceitação?

O Chrome não publicou uma taxa média de aceitação no anúncio de 2020. Quem publicou números foi a Mozilla, ao explicar por que o Firefox também passaria a restringir esses pedidos. Os dados vêm da telemetria do próprio navegador e mostram o tamanho do problema.

A conclusão prática dos dois navegadores é a mesma: o pedido funciona quando responde a uma ação da pessoa, e não quando aparece sozinho. A partir da versão 72, o Firefox passou a exigir um clique, toque ou tecla antes de mostrar o pedido; sem essa interação, só um ícone aparece na barra de endereço. No iPhone e no iPad, a Apple impõe regra parecida para web apps adicionados à Tela de Início: o pedido só pode acontecer em resposta a uma interação direta, como tocar num botão de inscrição, conforme o anúncio do WebKit sobre o iOS 16.4.

Em outras palavras: os três principais motores de navegador chegaram, cada um por um caminho, à mesma regra. Quem ainda dispara o pedido no carregamento da página está fazendo exatamente o que eles decidiram desencorajar.

Quando é o momento certo de pedir a permissão?

O momento certo é logo depois de a pessoa fazer algo que só faz sentido se ela quiser ser avisada depois. A notificação deixa de ser uma interrupção e passa a ser a continuação do que ela acabou de pedir. Alguns exemplos de gatilho, por tipo de site:

• Loja virtual: depois do pedido fechado (“quer ser avisado quando sair para entrega?”) ou na página de um produto esgotado (“avise-me quando voltar”).
• Portal de conteúdo: depois de a pessoa ler um segundo artigo do mesmo assunto, com o convite para acompanhar aquele tema específico.
• Serviço com agendamento: logo após a marcação, oferecendo o lembrete do dia anterior.
• Comparador ou classificados: depois de salvar uma busca, oferecendo o aviso quando aparecer algo novo nela.
• Evento ou lançamento: no botão de “quero saber quando abrir”, que é por si só um pedido de aviso.

Um detalhe faz diferença: o convite deve dizer o que será enviado e com que frequência. “Avisaremos só quando o pedido mudar de status” é uma promessa que a pessoa consegue avaliar. “Receba nossas novidades” não é.

Pré-prompt resolve o problema?

Muitas ferramentas oferecem o chamado pré-prompt: uma caixa desenhada pelo próprio site, que pergunta antes se a pessoa quer receber notificações e só chama o pedido do navegador se ela disser sim. A ideia é boa, porque protege a taxa de aceitação do pedido oficial: quem diria não, diz não para a caixa do site, e o navegador não registra recusa.

O próprio anúncio do Chrome, porém, faz uma ressalva: o pré-prompt também não é recomendado se interromper a jornada. Trocar um pop-up do navegador por um pop-up do site, no mesmo segundo da chegada, só muda quem interrompe. O pré-prompt funciona quando é ele mesmo contextual: um botão “avise-me” na página certa, e não uma janela sobre a página inteira.

Como configurar web push na prática?

A parte técnica é a mais simples do projeto. A maioria das ferramentas de push e de automação entrega um script e um arquivo de service worker para instalar no site. O trabalho que exige decisão vem antes e depois da instalação.

1. Decida para que o canal existe

Escreva em uma frase o tipo de aviso que o site vai mandar. Se a frase for “promoções”, repense. Se for “status do pedido e volta ao estoque”, você já sabe onde o pedido deve aparecer.

2. Escolha o gatilho do pedido

Configure a ferramenta para não pedir no carregamento. Ligue o pedido a um clique num botão contextual, como mostrado acima. Quase todas as ferramentas permitem desativar o pedido automático; muitas vêm com ele ligado por padrão.

3. Teste com o modo silencioso ligado

O Chrome permite ativar manualmente a versão silenciosa nas configurações de notificações. Veja como o seu fluxo se comporta assim: se o botão do site some ou trava quando o pedido oficial não abre, a experiência quebra para uma parte dos visitantes.

4. Ligue o push à régua de automação

O valor aparece quando a notificação nasce de um comportamento: carrinho parado, preço que mudou, conteúdo novo de um tema seguido. Disparo manual para toda a base é o uso que mais gera cancelamento. Se você já tem uma régua de e-mail, como a de recuperação de carrinho abandonado, o push entra como mais um passo dela, não como campanha paralela.

5. Combine frequência e horário

Defina um teto de mensagens por semana e respeite o fuso e o horário comercial do público. A notificação chega sem pedir licença ao momento da pessoa, e o excesso leva ao bloqueio nas configurações, que o site nem chega a ver.

Quais os erros mais comuns com web push?

• Pedir no carregamento da página, antes de qualquer interação, que é o padrão que derruba a aceitação e alimenta o silenciamento.
• Pré-prompt em janela cheia na chegada, que só troca quem interrompe.
• Prometer “novidades” sem dizer o que nem com que frequência.
• Usar push como canal de anúncio para a base inteira, em vez de aviso ligado a comportamento.
• Medir só inscritos e não acompanhar quantos deixam de receber com o tempo.
• Esquecer o iPhone: no iOS e iPadOS, o push só funciona para web apps adicionados à Tela de Início, assunto que tratamos no artigo sobre o que o iPhone exige de um PWA antes de notificar.

Como medir se o web push está funcionando?

O painel das ferramentas costuma destacar o total de inscritos, que é o número menos útil. As métricas que dizem se o canal está saudável são outras:

1. Taxa de aceitação do pedido: inscrições divididas pelo número de vezes que o pedido foi exibido. É ela que o navegador observa.
2. Taxa de exibição do pedido: quantos visitantes chegam ao gatilho. Se é baixa, o botão está escondido ou no lugar errado.
3. Taxa de clique por notificação: cliques divididos por entregas, separada por tipo de aviso.
4. Perda de inscritos: quantos deixam de receber por mês, que mostra se a frequência está pesada.
5. Conversão atribuída: marque os links das notificações com parâmetros de campanha para ver o que acontece depois do clique no seu analytics.

Se a taxa de aceitação está muito baixa e não sobe, olhe primeiro para o momento do pedido, não para o texto da notificação. A ordem dos fatores importa: nenhum texto bom compensa um pedido que o navegador já não mostra.

O que muda por tipo de negócio?

Elaborado pela Alliance Comunicação com base em projetos de automação.

Para B2B, vale uma ressalva honesta: o web push raramente é o canal que gera negócio novo. Ele tem mais valor dentro do produto, para quem já é cliente, do que no site institucional. Para empresa com ciclo de venda longo, a nutrição por e-mail continua fazendo o trabalho pesado.

Por onde começar hoje?

Se o seu site já tem web push, comece pelo teste da janela anônima e pela taxa de aceitação do pedido. Se o pedido aparece na chegada, mova-o para um gatilho contextual antes de investir em qualquer outra coisa. Se o site ainda não tem o canal, defina primeiro qual aviso ele vai entregar; o gatilho do pedido sai dessa definição.

Web push é uma peça de uma régua de automação, e a régua só funciona se cada canal souber o seu papel. Quando a Alliance desenha automação de marketing com IA, o push entra ligado a gatilhos de comportamento, com teto de frequência e medição do pedido desde o primeiro dia. Para saber onde a sua empresa está em relação a canais, dados e automação, o diagnóstico de marketing gratuito leva cerca de 30 minutos e aponta as prioridades por etapa do funil.