Construiu a sua lista de subscritores push, uma adesão árdua de cada vez, e cada adesão custou dinheiro real de aquisição. Por isso, quando chega a altura de mudar de fornecedores de notificações push, o receio é específico: cancelar o contrato antigo e a lista desaparece com ele. O seu fornecedor atual pode até dizer-lhe exatamente isso.
Não é verdade, e este guia mostra-lhe porquê ao nível do navegador. Uma subscrição de push web está ligada ao seu domínio, não ao seu fornecedor. Assim que vir a mecânica, cada mudança resolve-se num de dois cenários claros, uma curta lista de perguntas escritas para o seu fornecedor atual e um checklist de uma semana que a sua equipa pode executar sem drama.
Uma nota honesta desde o início. A equipa de vendas de todos os fornecedores, incluindo a nossa, dir-lhe-á que a migração é fácil. A maioria para por aí. Este post mostra-lhe o mecanismo em vez disso, para que o seu programador possa verificar todas as afirmações, incluindo as que fazemos no final.
O que é realmente uma subscrição de push web
Quando um visitante clica em “Permitir” no seu site, o navegador cria uma subscrição de push web construída em três partes:
- A sua origem. O domínio exato em que a permissão foi concedida (
https://oseusite.com). A permissão vive no navegador, ligada à origem. Não menciona nenhum fornecedor. - Um service worker. Um pequeno ficheiro JavaScript alojado no seu domínio que recebe e exibe notificações. Qualquer service worker que esteja registado controla a entrega.
- Uma chave de servidor de aplicação. 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 subscrição. (A visão geral das notificações push de web.dev cobre o protocolo completo.)
O registo da subscrição em si é de três strings: um URL de endpoint mais duas chaves curtas, p256dh e auth. Esse é o ativo completo. A sua lista inteira é uma tabela desses registos.
Uma regra decide tudo o que se segue: os navegadores aceitam envios apenas do detentor da chave privada VAPID correspondente. O que significa que cada mudança de fornecedor resolve-se em exatamente dois cenários, dependendo de onde essas chaves residem.
Cenário A: as suas chaves VAPID viajam, pelo que importa subscritores push no dia um
O Cenário A aplica-se quando as chaves são suas para levar: configurou as suas próprias chaves VAPID ou o seu próprio projeto Firebase na configuração, ou o seu fornecedor de saída concorda em entregar o par de chaves. Algumas equipas configuram isto deliberadamente desde o dia um; a abordagem é coberta no nosso guia para implementar push web sem dependência de fornecedor.
Com a chave privada em mãos, o seu novo fornecedor pode importar subscritores de push diretamente: cada endpoint, p256dh e registo auth são transferidos, e pode enviar mensagens para toda a sua lista existente desde o primeiro dia. Isto inclui subscritores inativos que não visitam há meses. Ninguém se reinscribe. Ninguém repara.
Uma nuance que vale a pena afirmar claramente. Mesmo no Cenário A, a migração duradoura ainda se completa através de revisitas, porque cada subscritor precisa eventualmente de aterrar no novo service worker. As chaves importadas garantem-lhe alcance no primeiro dia enquanto essa transição acontece silenciosamente em segundo plano.
Cenário B: as chaves ficam para trás e a reinscrição silenciosa assume o controlo
O Cenário B é o padrão comum: o fornecedor gerou as chaves VAPID e mantém-nas. Sem a chave privada, os registos 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.
É isto que realmente acontece. Na próxima vez que cada subscritor visitar o seu site, o service worker do novo fornecedor assume o controlo: desregistra o registo antigo, cancela a subscrição antiga e reinscreve o visitante com as novas chaves. Silenciosamente, numa única visita, sem um segundo pedido de permissão.
Por que o novo service worker não precisa de um segundo pedido
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 por baixo de uma permissão já concedida é invisível para o visitante, porque o navegador trata-o como se o seu site estivesse a reorganizar a sua própria canalização. É exatamente isso que é.
Duas armadilhas que o seu programador deve conhecer
Uma origem, uma subscrição. Um navegador não pode manter duas subscrições de push para a mesma origem. Subscrever com uma chave diferente falha até que a subscrição antiga seja libertada. Portanto, “executar ambos os fornecedores em paralelo” funciona a nível de lista, nunca dentro de um único navegador: cada subscritor está no fornecedor antigo ou no novo, e cada revisita move mais um.
As opt-ins de subdomínio do fornecedor nunca se movem. As subscrições recolhidas em yoursite.vendor.com pertencem à origem do fornecedor, e nenhum fornecedor as pode migrar. Essa base é reconstruída do zero. É a maior armadilha em qualquer migração de notificações push, e o argumento mais forte para ancorar subscrições a um domínio que controla desta vez. Se opera várias marcas ou domínios regionais, a mesma lógica de origem molda toda a sua arquitetura; cobrimo-la em push web em múltiplos 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 liberta o par | Fornecedor gerou e retém as chaves (o padrão comum) |
| Alcance no Dia 1 | Toda a sua lista, incluindo subscritores inativos | Zero, até os visitantes regressarem |
| Em cada revisita | O subscritor move-se silenciosamente para as novas chaves | Re-subscrição silenciosa com as novas chaves, sem segundo pedido |
| Quem recupera | Todos | Todos os que visitam novamente |
| Quem perde | Ninguém | Subscritores que nunca regressam (que de qualquer forma já não eram receita alcançável) |
Porquê as audiências de visita diária concluem 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. Mais nada. Um subscritor de eCommerce pode visitar mensalmente, pelo que a transição estende-se por meses. Um apostador verifica probabilidades, linhas e resultados diariamente. Um leitor de notícias regressa para cada ciclo de manchetes.
Esse ritmo de retorno é a razão pela qual os sites de apostas e notícias são os setores mais bem posicionados na internet para mudar de fornecedores de notificações push: a mesma frequência de visita que torna as 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 mil milhões de notificações, pelo que estes mecanismos de transição são uma 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, utilizadores inativos) | Semanas, aceleradas por envios do antigo fornecedor e grandes eventos |
| Inativo (sem visita há 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; a sua curva depende do ritmo do seu tráfego, e irá observá-la ao vivo no painel de controlo. Também pode dobrar a curva: agende a transição na semana anterior a um grande evento desportivo e o tráfego do evento fará a transição por si. As casas de apostas desportivas que planeiam uma sequência de push para o dia do jogo já sabem quais os fins de semana em que estes ocorrem.
O push de aplicações é mais simples: os seus tokens sempre foram seus
Se também envia push de aplicações, respire fundo. Esta parte é estruturalmente fácil, porque nenhum fornecedor a pode manter refém.
Os certificados e chaves APNs são emitidos para a sua conta de Desenvolvedor Apple. O seu projeto FCM vive na sua consola Google. Um fornecedor de push é uma camada por cima das credenciais que possui, pelo que mudar significa apontar uma nova camada para as mesmas credenciais. Os tokens de dispositivo exportam e importam de forma limpa, sem reinstalações e sem um segundo pedido de permissão.
Duas notas práticas. Primeiro, filtre as exportações de tokens para dispositivos ativos há aproximadamente 270 dias antes de importar, porque o FCM trata tokens inativos há mais de ~270 dias como obsoletos. Uma exportação de tokens de cinco anos inflaciona a sua contagem de subscritores e, em preços que contam apenas subscritores ativos, ninguém beneficia disso. Segundo, a cobertura completa do SDK chega à velocidade com que os utilizadores atualizam a sua aplicação, tipicamente uma ou duas semanas para uma aplicação de uso diário com atualizações automáticas.
Se a sua aplicação iOS atualmente envia através do Firebase, o fluxo passo a passo é um tópico próprio; consulte o nosso guia para migrar do Firebase Cloud Messaging no iOS em vez de o improvisar a partir desta publicação.
Antes de mudar de fornecedor 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 veredictos de fornecedores (incluindo uma que possamos publicar), obtenha as respostas do seu próprio fornecedor registadas. O e-mail funciona; um ticket de suporte funciona melhor. Se estiver a avaliar destinos ao mesmo tempo, as mesmas perguntas servem como um filtro útil ao comparar alternativas ao OneSignal.
- Consegue exportar os meus registos completos de subscrição de push web — URL do endpoint mais as chaves
p256dheauthpara cada subscritor — ou apenas IDs internos? IDs internos são inúteis fora do sistema do fornecedor. - Irá divulgar o par de chaves VAPID sob o qual as minhas subscrições foram criadas? Esta única resposta decide o Cenário A versus o Cenário B.
- O meu push web corre no projeto FCM ou Firebase de quem, no meu ou no seu? Se for no seu, as chaves já podem estar na sua própria consola.
- Posso exportar segmentos, tags, atributos de subscritores e listas de supressão separadamente? Eles não acompanham os registos de subscrição automaticamente.
- Posso exportar os tokens dos dispositivos push da minha aplicação e em que formato?
- O que acontece aos meus dados se eu fizer downgrade ou cancelar — existe alguma auto-eliminação ou janela de retenção? Alguns fornecedores eliminam dados de subscritores inativos em níveis inferiores. Exporte primeiro, sempre.
O checklist da semana de migração
Imprima esta secção. Oito passos, por ordem.
- Exporte tudo antes de cancelar ou fazer downgrade de qualquer coisa. Registos de subscrição, tokens de aplicação, segmentos, tags, atributos, listas de supressão. O acesso à exportação morre com o seu contrato.
- Obtenha a resposta das chaves VAPID por escrito. Decide o seu cenário e se pode importar subscritores push no primeiro dia.
- Mova as listas de supressão primeiro, não por último. Para operadores de apostas e jogos, isto é inegociável: jogadores autoexcluídos devem ser suprimidos na nova plataforma antes que qualquer campanha seja retomada, não reconciliados depois.
- Filtre os tokens da aplicação para ~270 dias de atividade antes da importação.
- Instale o novo SDK e service worker, e mescle com qualquer service worker existente (uma shell PWA, o worker do fornecedor antigo) em vez de o sobrescrever.
- Não elimine o ficheiro service worker do fornecedor antigo no primeiro dia. Visitantes que retornam ainda carregam registos apontando para ele; a transição desregistra-os graciosamente. Remova o ficheiro cedo e gerará erros na consola em vez de migrações. Remova-o na desmontagem final.
- Mantenha o fornecedor antigo a enviar durante a janela paralela. Contra-intuitivo mas crítico: cada notificação que o fornecedor antigo envia impulsiona uma revisita, e cada revisita completa a migração de mais um subscritor. O seu fornecedor de saída torna-se a sua melhor ferramenta de migração.
- Meça a transição diariamente e mude quando atingir o platô. Acompanhe a nova base ativa em relação à base ativa antiga. Quando a curva achatar, finalize a desmontagem, cancele o contrato antigo e arquive as exportações.
O custo da mudança quando o PushEngage o faz por si
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 centro de ajuda: eles cuidam do mapeamento de exportação, do manuseio de chaves, da fusão do service-worker e do 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 a questão das 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 verifique os preços da PushEngage em comparação com sua fatura atual. Cada plano pago carrega uma garantia de devolução do dinheiro em 14 dias, então a migração da notificação push em si é a parte de menor risco da decisão.
