Hai costruito la tua lista di iscritti alle notifiche push un opt-in alla volta, guadagnato con fatica, e ogni opt-in è costato denaro reale per l'acquisizione. Quindi, quando è il momento di cambiare provider di notifiche push, la paura è specifica: annulla il vecchio contratto e la lista scompare con esso. Il tuo attuale fornitore potrebbe persino dirti esattamente questo.
Non è vero, e questa guida ti mostra perché a livello di browser. Un'iscrizione alle notifiche push web è legata al tuo dominio, non al tuo provider. Una volta compresi i meccanismi, ogni cambio si risolve in uno dei due scenari chiari, una breve lista di domande scritte per il tuo attuale fornitore e una checklist di una settimana che il tuo team può eseguire senza problemi.
Una nota onesta in anticipo. Il team di vendita di ogni fornitore, inclusa la nostra, ti dirà che la migrazione è facile. La maggior parte si ferma lì. Questo post ti mostra invece il meccanismo, in modo che il tuo sviluppatore possa verificare ogni affermazione, comprese quelle che facciamo alla fine.
Cos'è effettivamente un'iscrizione alle notifiche push web
Quando un visitatore fa clic su "Consenti" sul tuo sito, il browser crea un'iscrizione alle notifiche push web basata su tre parti:
- La tua origine. Il dominio esatto su cui è stata concessa l'autorizzazione (
https://tuosito.com). L'autorizzazione risiede nel browser, associata all'origine. Non menziona alcun fornitore. - Un service worker. Un piccolo file JavaScript ospitato sul tuo dominio che riceve e visualizza le notifiche. Qualsiasi service worker registrato controlla la consegna.
- Una chiave del server dell'applicazione. La metà pubblica di una coppia di chiavi VAPID. Il servizio push del browser accetta solo invii firmati con la chiave privata corrispondente. Chiunque detenga quella chiave privata può inviare messaggi all'iscrizione. (La panoramica delle notifiche push di web.dev copre il protocollo completo.)
Il record di iscrizione stesso è composto da tre stringhe: un URL di endpoint più due brevi chiavi, p256dh e auth. Questo è l'intero asset. La tua intera lista è una tabella di quei record.
Una regola decide tutto a valle: i browser accettano invii solo dal detentore della chiave privata VAPID corrispondente. Il che significa che ogni cambio di fornitore si risolve in esattamente due scenari, a seconda di dove risiedono quelle chiavi.
Scenario A: le tue chiavi VAPID viaggiano, quindi importi gli iscritti push il primo giorno
Lo scenario A si applica quando le chiavi sono tue da prendere: hai configurato le tue chiavi VAPID o il tuo progetto Firebase al momento dell'impostazione, o il tuo fornitore uscente accetta di cedere la coppia di chiavi. Alcuni team lo impostano deliberatamente fin dal primo giorno; l'approccio è trattato nella nostra guida all' implementazione delle notifiche push web senza vendor lock-in.
Con la chiave privata in mano, il tuo nuovo provider può importare direttamente gli iscritti push: ogni endpoint, p256dh e record auth vengono trasferiti, e puoi inviare messaggi all'intera lista esistente fin dal primo giorno. Ciò include gli iscritti dormienti che non visitano da mesi. Nessuno si riiscrive. Nessuno se ne accorge.
Una sfumatura che vale la pena dichiarare chiaramente. Anche nello Scenario A, la migrazione duratura si completa comunque tramite le rivisite, perché ogni iscritto alla fine deve atterrare sul nuovo service worker. Le chiavi importate ti garantiscono la copertura dal primo giorno mentre quel passaggio avviene silenziosamente in background.
Scenario B: le chiavi rimangono indietro e la riiscrizione silenziosa prende il sopravvento
Lo Scenario B è l'impostazione predefinita comune: il fornitore ha generato le chiavi VAPID e le conserva. Senza la chiave privata, i record esportati sono crittograficamente inutili. La copertura dal primo giorno è zero, e l'avvertimento del tuo vecchio fornitore suona vero per circa un altro paragrafo.
Ecco cosa succede realmente. La prossima volta che ogni iscritto visita il tuo sito, il service worker del nuovo provider prende il sopravvento: annulla la registrazione della vecchia registrazione, annulla l'iscrizione alla vecchia sottoscrizione e riiscrive il visitatore con le nuove chiavi. Silenziosamente, in una singola visita, senza una seconda richiesta di autorizzazione.
Perché il nuovo service worker non necessita di una seconda richiesta
L'autorizzazione alle notifiche viene concessa alla tua origine, non a un fornitore. Il browser si fida già del tuo dominio. Sostituire il service worker e le chiavi sotto un'autorizzazione già concessa è invisibile al visitatore, perché il browser lo tratta come se il tuo sito stesse riorganizzando la propria infrastruttura. Che è esattamente ciò che sta accadendo.
Due trappole che il tuo sviluppatore dovrebbe conoscere
Un'origine, una sottoscrizione. Un browser non può mantenere due sottoscrizioni push per la stessa origine. L'iscrizione con una chiave diversa fallisce finché la vecchia sottoscrizione non viene rilasciata. Quindi "eseguire entrambi i fornitori in parallelo" funziona a livello di lista, mai all'interno di un singolo browser: ogni iscritto è sul vecchio o sul nuovo fornitore, e ogni rivisita ne sposta un altro.
Le iscrizioni ai sottodomini dei fornitori non vengono mai trasferite. Le sottoscrizioni raccolte su yoursite.vendor.com appartengono all'origine del fornitore e nessun provider può migrarle. Quella base viene ricostruita da zero. È la trappola più grande in qualsiasi migrazione di notifiche push e l'argomento più forte per ancorare le sottoscrizioni a un dominio che controlli questa volta. Se gestisci diversi marchi o domini regionali, la stessa logica di origine modella la tua intera architettura; ne parliamo in web push su più domini.
Ecco i due scenari a confronto:
| Scenario A: le chiavi viaggiano | Scenario B: le chiavi rimangono indietro | |
|---|---|---|
| Quando si applica | Chiavi VAPID proprie / progetto Firebase proprio, o il fornitore rilascia la coppia | Il fornitore ha generato e conserva le chiavi (l'impostazione predefinita comune) |
| Copertura dal giorno 1 | La tua intera lista, inclusi gli iscritti dormienti | Zero, finché i visitatori non ritornano |
| Ad ogni rivisita | L'iscritto passa silenziosamente alle nuove chiavi | Riiscrizione silenziosa con le nuove chiavi, nessuna seconda richiesta |
| Chi recuperi | Tutti | Tutti coloro che visitano di nuovo |
| Chi perdi | Nessuno | Iscrizioni che non ritornano mai (che comunque non erano più entrate raggiungibili) |
Perché il pubblico che visita quotidianamente completa una migrazione delle notifiche push più velocemente
Nello Scenario B, l'orologio di acquisizione è la frequenza di ritorno del tuo pubblico. Nient'altro. Un utente registrato di eCommerce potrebbe visitare mensilmente, quindi l'acquisizione si estende per mesi. Un giocatore d'azzardo controlla quote, linee e risultati quotidianamente. Un lettore di notizie torna per ogni ciclo di notizie.
Quel ritmo di ritorno è il motivo per cui i siti di scommesse e notizie sono i verticali meglio posizionati su Internet per cambiare fornitori di notifiche push: la stessa frequenza di visita che rende le notifiche push per siti di scommesse un motore di fidelizzazione comprime anche una migrazione che richiede un trimestre ad altri siti in una o due settimane. I siti di scommesse e giochi su PushEngage hanno inviato oltre 3,5 miliardi di notifiche, quindi queste meccaniche di acquisizione sono una realtà produttiva quotidiana per noi, non una teoria.
| Modello di ritorno del pubblico | Acquisizione tipica della base attiva |
|---|---|
| Visitatori giornalieri (quote live, breaking news, promozioni giornaliere) | Giorni fino a circa una settimana |
| Diverse visite a settimana (giocatori del fine settimana, assidui) | 1–2 settimane |
| Settimanale o meno (visitatori stagionali, utenti inattivi) | Settimane, accelerate dagli invii del vecchio fornitore e dai grandi eventi |
| Dormiente (nessuna visita da mesi) | Recuperabile solo nello Scenario A |
Questi sono modelli tipici per il pubblico che visita quotidianamente, non garanzie; la tua curva dipende dal ritmo del tuo traffico e la osserverai in tempo reale nella dashboard. Puoi anche piegare la curva: pianifica la transizione la settimana prima di un evento importante e il traffico dell'evento farà l'acquisizione per te. I bookmaker che pianificano una sequenza di push per il giorno della partita sanno già quali fine settimana sono.
Il push dell'app è più semplice: i tuoi token erano sempre tuoi
Se invii anche push dell'app, fai un respiro. Questa parte è strutturalmente facile, perché nessun fornitore può tenerla in ostaggio.
I certificati e le chiavi APN sono emessi al tuo account Apple Developer. Il tuo progetto FCM risiede nella tua console Google. Un fornitore di push è uno strato sopra le credenziali che possiedi, quindi cambiare significa puntare un nuovo strato alle stesse credenziali. I token dei dispositivi vengono esportati e importati in modo pulito, senza reinstallazioni e senza una seconda richiesta di autorizzazione.
Due note pratiche. Primo, filtra le esportazioni di token per dispositivi attivi da circa 270 giorni prima di importarli, perché FCM tratta i token inattivi oltre circa 270 giorni come obsoleti. Un dump di token di cinque anni gonfia il tuo numero di iscritti e sui prezzi che contano solo gli iscritti attivi, nessuno ne trae beneficio. Secondo, la copertura SDK completa arriva alla velocità con cui gli utenti aggiornano la tua app, tipicamente una o due settimane per un'app di uso quotidiano con aggiornamenti automatici.
Se la tua app iOS attualmente invia tramite Firebase, il flusso passo-passo è un argomento a sé stante; consulta la nostra guida alla migrazione da Firebase Cloud Messaging su iOS piuttosto che improvvisarla da questo post.
Prima di cambiare fornitori di notifiche push, poni queste sei domande per iscritto
Le policy di esportazione e chiave dei fornitori variano e cambiano. Invece di fidarti di qualsiasi tabella di giudizi dei fornitori (inclusa una che potremmo pubblicare), ottieni le risposte del tuo fornitore registrate. Le email vanno bene; un ticket di supporto funziona meglio. Se stai valutando destinazioni contemporaneamente, le stesse domande costituiscono un utile filtro mentre confronti le alternative a OneSignal.
- Puoi esportare i miei record completi di iscrizione ai push web — URL dell'endpoint più le chiavi
p256dheauthper ogni iscritto — o solo ID interni? Gli ID interni non hanno significato al di fuori del sistema del fornitore. - Rilascerai la coppia di chiavi VAPID sotto cui sono state create le mie iscrizioni? Questa singola risposta decide tra Scenario A e Scenario B.
- Su quale progetto FCM o Firebase di chi vengono eseguiti i miei push web, il mio o il tuo? Se è il tuo, le chiavi potrebbero essere già nella tua console.
- Posso esportare segmenti, tag, attributi degli iscritti ed elenchi di esclusione separatamente? Non vengono inclusi automaticamente nei record di iscrizione.
- Posso esportare i token dei dispositivi push della mia app e in quale formato?
- Cosa succede ai miei dati se effettuo il downgrade o cancello — c'è una finestra di eliminazione automatica o di conservazione? Alcuni fornitori eliminano i dati degli iscritti inattivi nei livelli inferiori. Esporta prima, sempre.
La checklist della settimana di migrazione
Stampa questa sezione. Otto passaggi, in ordine.
- Esporta tutto prima di cancellare o effettuare il downgrade di qualsiasi cosa. Record di iscrizione, token dell'app, segmenti, tag, attributi, elenchi di esclusione. L'accesso all'esportazione muore con il tuo contratto.
- Ottieni la risposta sulle chiavi VAPID per iscritto. Decide il tuo scenario e se puoi importare gli iscritti push dal primo giorno.
- Sposta prima gli elenchi di esclusione, non per ultimi. Per gli operatori di scommesse e giochi questo è non negoziabile: i giocatori auto-esclusi devono essere esclusi sulla nuova piattaforma prima che riprenda una singola campagna, non riconciliati in seguito.
- Filtra i token dell'app a circa 270 giorni di attività prima dell'importazione.
- Installa il nuovo SDK e service worker, e uniscilo a qualsiasi service worker esistente (un guscio PWA, il worker del vecchio fornitore) piuttosto che sovrascriverlo.
- Non eliminare il file service worker del vecchio fornitore dal primo giorno. I visitatori di ritorno hanno ancora registrazioni che puntano ad esso; il passaggio li annulla con grazia. Rimuovi il file troppo presto e genererai errori nella console invece di migrazioni. Rimuovilo allo smantellamento finale.
- Mantieni il vecchio fornitore che invia durante la finestra parallela. Controintuitivo ma critico: ogni notifica inviata dal vecchio fornitore guida una rivisitazione, e ogni rivisitazione completa la migrazione di un altro iscritto. Il tuo fornitore uscente diventa il tuo miglior strumento di migrazione.
- Misura il takeover giornalmente e passa al plateau. Tieni traccia della nuova base attiva rispetto alla vecchia base attiva. Quando la curva si appiattisce, termina lo smantellamento, cancella il vecchio contratto e archivia le esportazioni.
Quanto costa il passaggio quando PushEngage lo fa per te
In PushEngage, la migrazione è un servizio di lusso incluso gratuitamente nei piani a pagamento. Ricevi un ingegnere di migrazione, non un articolo del centro assistenza: si occupano del mapping dell'esportazione, della gestione delle chiavi, della fusione del service worker e del piano di takeover. Questo è importante perché le modalità di fallimento sono silenziose: un'importazione grezza con formati di payload non corrispondenti può fornire notifiche tecnicamente riuscite ma vuote, che è esattamente la classe di fallimento silenzioso che uno specialista individua prima dei tuoi iscritti.
La chiamata di scoping dura circa quindici minuti: numero di iscritti per canale, fornitore attuale e la domanda sulle chiavi sopra. Alla fine saprai se sei nello Scenario A o B e avrai un piano datato.
Se sei pronto a cambiare fornitore di notifiche push, inizia con le sei domande scritte in questo post e vedi come risponde il tuo attuale fornitore. Quindi guarda cosa farebbe una piattaforma di notifiche push web costruita attorno alla segmentazione e all'attribuzione dei ricavi con l'elenco che già possiedi, e confronta i prezzi di PushEngage con la tua fattura attuale. Ogni piano a pagamento include una garanzia di rimborso di 14 giorni, quindi la migrazione delle notifiche push è la parte meno rischiosa della decisione.
