Você construiu sua lista de assinantes push um opt-in conquistado a duras penas por vez, e cada opt-in custou dinheiro real de aquisição. Portanto, quando chega a hora de trocar de provedores de notificações push, o medo é específico: cancelar o contrato antigo e a lista desaparece com ele. Seu fornecedor atual pode até dizer exatamente isso.
Não é verdade, e este guia mostra por quê no nível do navegador. Uma assinatura de push da web está vinculada ao seu domínio, não ao seu fornecedor. Assim que você entender a mecânica, cada troca se resolve em um de dois cenários claros, uma curta lista de perguntas por escrito para seu fornecedor atual e um checklist de uma semana que sua equipe pode executar sem problemas.
Uma nota honesta para começar. A equipe de vendas de todos os fornecedores, incluindo a nossa, dirá que a migração é fácil. A maioria para por aí. Este post mostra o mecanismo em vez disso, para que seu desenvolvedor possa verificar todas as alegações, incluindo as que fazemos no final.
O que é realmente uma assinatura de push da web
Quando um visitante clica em “Permitir” em seu site, o navegador cria uma assinatura de push da web construída em três partes:
- Sua origem. O domínio exato em que a permissão foi concedida (
https://seusite.com). A permissão vive no navegador, anexada à origem. Ela não menciona nenhum fornecedor. - Um service worker. Um pequeno arquivo JavaScript hospedado em seu domínio que recebe e exibe notificações. Qualquer service worker que esteja registrado controla a entrega.
- Uma chave de servidor de aplicativo. A metade pública de um par de chaves VAPID. O serviço de push do navegador só aceita envios assinados com a chave privada correspondente. Quem detiver essa chave privada pode enviar mensagens para a assinatura. (A visão geral de notificações push do web.dev cobre o protocolo completo.)
O registro da assinatura em si são três strings: um URL de endpoint mais duas chaves curtas, p256dh e auth. Esse é o ativo inteiro. Sua lista completa é uma tabela desses registros.
Uma regra decide tudo o que vem depois: os navegadores aceitam envios apenas do detentor da chave privada VAPID correspondente. O que significa que cada troca de fornecedor se resolve em exatamente dois cenários, dependendo de onde essas chaves residem.
Cenário A: suas chaves VAPID viajam, então você importa assinantes push no primeiro dia
O Cenário A se aplica quando as chaves são suas para levar: você configurou suas próprias chaves VAPID ou seu próprio projeto Firebase na configuração, ou seu fornecedor de saída concorda em entregar o par de chaves. Algumas equipes configuram isso deliberadamente desde o primeiro dia; a abordagem é coberta em nosso guia para implementar push da web sem vendor lock-in.
Com a chave privada em mãos, seu novo provedor pode importar assinantes de push diretamente: cada endpoint, registro p256dh e auth é transferido, e você pode enviar mensagens para toda a sua lista existente desde o primeiro dia. Isso inclui assinantes inativos que não visitam há meses. Ninguém se reinscreve. Ninguém percebe.
Uma nuance que vale a pena declarar claramente. Mesmo no Cenário A, a migração durável ainda é concluída por meio de revisitas, pois cada assinante eventualmente precisa pousar no novo service worker. As chaves importadas garantem alcance no primeiro dia enquanto essa transição ocorre silenciosamente em segundo plano.
Cenário B: as chaves ficam para trás e a reinscrição silenciosa assume o controle
O Cenário B é o padrão comum: o fornecedor gerou as chaves VAPID e as mantém. Sem a chave privada, os registros exportados são criptograficamente inúteis. O alcance no primeiro dia é zero, e o aviso do seu antigo fornecedor soa verdadeiro por mais um parágrafo.
É o que realmente acontece. Na próxima vez que cada assinante visitar seu site, o service worker do novo provedor assume: ele desregistra o registro antigo, cancela a inscrição da assinatura antiga e reinscreve o visitante sob as novas chaves. Silenciosamente, em uma única visita, sem um segundo prompt de permissão.
Por que o novo service worker não precisa de um segundo prompt
A permissão de notificação é concedida à sua origem, não a um fornecedor. O navegador já confia no seu domínio. Trocar o service worker e as chaves sob uma permissão já concedida é invisível para o visitante, porque o navegador o trata como se seu site estivesse reorganizando sua própria infraestrutura. É exatamente isso que é.
Duas armadilhas que seu desenvolvedor deve conhecer
Uma origem, uma assinatura. Um navegador não pode manter duas assinaturas de push para a mesma origem. Inscrever-se com uma chave diferente falha até que a assinatura antiga seja liberada. Portanto, "executar ambos os fornecedores em paralelo" funciona no nível da lista, nunca dentro de um único navegador: cada assinante está no fornecedor antigo ou no novo, e cada revisita move mais um.
Opt-ins de subdomínio do fornecedor nunca se movem. Assinaturas coletadas em yoursite.vendor.com pertencem à origem do fornecedor, e nenhum provedor pode migrá-las. Essa base é reconstruída do zero. É a maior armadilha em qualquer migração de notificação push e o argumento mais forte para ancorar assinaturas a um domínio que você controla desta vez. Se você opera várias marcas ou domínios regionais, a mesma lógica de origem molda toda a sua arquitetura; cobrimos isso em push da web em vários domínios.
Aqui estão os dois cenários lado a lado:
| Cenário A: as chaves viajam | Cenário B: as chaves ficam para trás | |
|---|---|---|
| Quando se aplica | Chaves VAPID próprias / projeto Firebase próprio, ou o fornecedor libera o par | Fornecedor gerou e retém as chaves (o padrão comum) |
| Alcance no Dia 1 | Sua lista inteira, incluindo assinantes inativos | Zero, até que os visitantes retornem |
| Em cada revisita | O assinante se move silenciosamente para as novas chaves | Reinscrição silenciosa sob as novas chaves, sem segundo prompt |
| Quem você recupera | Todos | Todos que visitam novamente |
| Quem você perde | Ninguém | Assinantes que nunca retornam (que de qualquer forma não eram mais receita alcançável) |
Por que audiências de visita diária finalizam uma migração de notificações push mais rapidamente
No Cenário B, o relógio de transição é a frequência de retorno da sua audiência. Nada mais. Um assinante de eCommerce pode visitar mensalmente, então a transição se estende por meses. Um apostador verifica odds, linhas e resultados diariamente. Um leitor de notícias volta para cada ciclo de manchetes.
Esse ritmo de retorno é o motivo pelo qual sites de apostas e notícias são os verticais mais bem posicionados na internet para trocar de provedores de notificações push: a mesma frequência de visita que torna notificações push para sites de apostas um motor de retenção também comprime uma migração que leva outros sites um trimestre para uma ou duas semanas. Sites de apostas e jogos no PushEngage enviaram mais de 3,5 bilhões de notificações, então essas mecânicas de transição são realidade de produção diária para nós, não teoria.
| Padrão de retorno da audiência | Transição típica da base ativa |
|---|---|
| Visitantes diários (odds ao vivo, notícias de última hora, promoções diárias) | Dias para cerca de uma semana |
| Várias visitas por semana (apostadores de fim de semana, regulares) | 1–2 semanas |
| Semanalmente ou menos (visitantes sazonais, usuários inativos) | Semanas, acelerado por envios do antigo fornecedor e grandes eventos |
| Inativo (sem visita em meses) | Recuperável apenas sob o Cenário A |
Estes são padrões típicos para audiências de visita diária, não garantias; sua curva depende do ritmo do seu tráfego, e você a observará ao vivo no painel. Você também pode dobrar a curva: agende a transição na semana anterior a um grande evento e o tráfego do evento fará a transição por você. Casas de apostas planejando uma sequência de push para o dia da partida já sabem quais fins de semana são esses.
Push de app é mais simples: seus tokens sempre foram seus
Se você também envia push de app, respire fundo. Essa metade é estruturalmente fácil, porque nenhum fornecedor pode mantê-la como refém.
Certificados e chaves APNs são emitidos para sua conta de Desenvolvedor Apple. Seu projeto FCM vive no seu console Google. Um fornecedor de push é uma camada sobre credenciais que você possui, então trocar significa apontar uma nova camada para as mesmas credenciais. Tokens de dispositivo exportam e importam de forma limpa, sem reinstalações e sem segunda solicitação de permissão.
Duas notas práticas. Primeiro, filtre as exportações de tokens para dispositivos ativos em aproximadamente 270 dias antes de importar, porque o FCM trata tokens inativos além de ~270 dias como obsoletos. Um despejo de tokens de cinco anos infla sua contagem de assinantes e, em precificações que contam apenas assinantes ativos, ninguém se beneficia disso. Segundo, a cobertura completa do SDK chega na velocidade com que os usuários atualizam seu aplicativo, geralmente uma ou duas semanas para um aplicativo de uso diário com atualizações automáticas.
Se seu aplicativo iOS atualmente envia através do Firebase, o fluxo passo a passo é um tópico próprio; veja nosso guia para migrar do Firebase Cloud Messaging no iOS em vez de improvisar a partir deste post.
Antes de trocar de provedores de notificações push, faça estas seis perguntas por escrito
As políticas de exportação e chaves de fornecedores variam e mudam. Em vez de confiar em qualquer tabela de vereditos de fornecedores (incluindo uma que possamos publicar), obtenha as respostas do seu próprio fornecedor registradas. E-mail funciona; um ticket de suporte funciona melhor. Se você estiver avaliando destinos ao mesmo tempo, as mesmas perguntas servem como um filtro útil ao comparar alternativas ao OneSignal.
- Vocês podem exportar meus registros completos de assinatura de push da web — URL do endpoint mais as chaves
p256dheauthpara cada assinante — ou apenas IDs internos? IDs internos não têm significado fora do sistema do fornecedor. - Vocês liberarão o par de chaves VAPID sob o qual minhas assinaturas foram criadas? Esta única resposta decide o Cenário A versus o Cenário B.
- O projeto FCM ou Firebase de quem o meu push da web executa, o meu ou o seu? Se for o seu, as chaves já podem estar no seu próprio console.
- Posso exportar segmentos, tags, atributos de assinantes e listas de supressão separadamente? Eles não acompanham os registros de assinatura automaticamente.
- Posso exportar os tokens de dispositivo do meu aplicativo push e em qual formato?
- O que acontece com meus dados se eu fizer downgrade ou cancelar — há exclusão automática ou janela de retenção? Alguns fornecedores excluem dados de assinantes inativos em níveis inferiores. Exporte primeiro, sempre.
A lista de verificação da semana de migração
Imprima esta seção. Oito passos, em ordem.
- Exporte tudo antes de cancelar ou fazer downgrade de qualquer coisa. Registros de assinatura, tokens de aplicativo, segmentos, tags, atributos, listas de supressão. O acesso à exportação morre com seu contrato.
- Obtenha a resposta das chaves VAPID por escrito. Isso decide seu cenário e se você pode importar assinantes de push no primeiro dia.
- Mova as listas de supressão primeiro, não por último. Para operadores de apostas e jogos, isso é inegociável: jogadores autoexcluídos devem ser suprimidos na nova plataforma antes que qualquer campanha seja retomada, não reconciliados depois.
- Filtre os tokens do aplicativo para ~270 dias de atividade antes da importação.
- Instale o novo SDK e service worker, e mescle com qualquer service worker existente (um shell PWA, o worker do antigo fornecedor) em vez de sobrescrevê-lo.
- Não exclua o arquivo de service worker do antigo fornecedor no primeiro dia. Visitantes que retornam ainda carregam registros apontando para ele; a transição os desregistra graciosamente. Remova o arquivo cedo e você gerará erros no console em vez de migrações. Remova-o no desmonte final.
- Mantenha o antigo fornecedor enviando durante a janela paralela. Contraintuitivo, mas crítico: cada notificação que o antigo fornecedor envia gera uma nova visita, e cada nova visita completa a migração de mais um assinante. Seu fornecedor de saída se torna sua melhor ferramenta de migração.
- Meça a transição diariamente e mude no platô. Acompanhe a nova base ativa em relação à antiga base ativa. Quando a curva se achatar, finalize o desmonte, cancele o antigo contrato e arquive as exportações.
Quanto custa a troca quando o PushEngage faz isso por você
Na PushEngage, a migração é um serviço de luvas brancas incluído gratuitamente nos planos pagos. Você recebe um engenheiro de migração, não um artigo de central de ajuda: eles cuidam do mapeamento de exportação, gerenciamento de chaves, mesclagem do service worker e plano de transição. Isso é importante porque os modos de falha são silenciosos — uma importação bruta com formatos de payload incompatíveis pode entregar notificações tecnicamente bem-sucedidas, mas em branco, que é exatamente a classe de falha silenciosa que um especialista detecta antes dos seus assinantes.
A chamada de escopo leva cerca de quinze minutos: contagem de assinantes por canal, fornecedor atual e as questões de chaves acima. Ao final dela, você saberá se está no Cenário A ou B e terá um plano com data definida.
Se você está pronto para trocar de provedor de notificações push, comece com as seis perguntas escritas neste post e veja como seu fornecedor atual responde. Em seguida, veja o que uma plataforma de notificações push web construída em torno de segmentação e atribuição de receita faria com a lista que você já possui e compare os preços da PushEngage com sua fatura atual. Cada plano pago oferece uma garantia de devolução do dinheiro em 14 dias, portanto, a migração da notificação push em si é a parte de menor risco da decisão.
