Du byggde din lista med prenumeranter på push-notiser en hårt vunnen opt-in i taget, och varje opt-in kostade riktiga pengar för förvärv. Så när det är dags att byta leverantör av push-notiser är rädslan specifik: säg upp det gamla kontraktet och listan försvinner med det. Din nuvarande leverantör kanske till och med säger exakt det.
Det stämmer inte, och den här guiden visar dig varför på webbläsar-nivå. En prenumeration på webb-push är bunden till din domän, inte till din leverantör. När du väl ser mekaniken löser sig varje byte till ett av två tydliga scenarier, en kort lista med skriftliga frågor till din nuvarande leverantör och en checklista för en vecka som ditt team kan köra utan drama.
En ärlig notering direkt. Varje leverantörs säljteam, inklusive vårt, kommer att säga att migrering är enkelt. De flesta stannar där. Det här inlägget visar dig mekanismen istället, så att din utvecklare kan verifiera varje påstående, inklusive de vi gör i slutet.
Vad en prenumeration på webb-push faktiskt är
När en besökare klickar på "Tillåt" på din webbplats skapar webbläsaren en prenumeration på webb-push som bygger på tre delar:
- Din ursprungskälla. Den exakta domänen som tillståndet beviljades på (
https://yoursite.com). Tillståndet finns i webbläsaren, kopplat till ursprungskällan. Det nämner ingen leverantör. - En service worker. En liten JavaScript-fil som finns på din domän och som tar emot och visar notiser. Vilken service worker som är registrerad styr leveransen.
- En applikationsservernyckel. Den publika halvan av ett VAPID-nyckelpar. Webbläsarens push-tjänst accepterar endast sändningar signerade med den matchande privata nyckeln. Den som har den privata nyckeln kan skicka meddelanden till prenumerationen. (web.dev:s översikt över push-notiser täcker hela protokollet.)
Själva prenumerationsposten består av tre strängar: en slutpunkts-URL plus två korta nycklar, p256dh och auth. Det är hela tillgången. Hela din lista är en tabell med dessa poster.
En regel avgör allt nedströms: webbläsare accepterar endast sändningar från innehavaren av den matchande privata VAPID-nyckeln. Vilket innebär att varje leverantörsbyte löser sig i exakt två scenarier, beroende på var dessa nycklar finns.
Scenario A: dina VAPID-nycklar följer med, så du importerar push-prenumeranter från dag ett
Scenario A gäller när nycklarna är dina att ta med: du konfigurerade dina egna VAPID-nycklar eller ditt eget Firebase-projekt vid installationen, eller din utgående leverantör går med på att lämna över nyckelparet. Vissa team konfigurerar detta medvetet från dag ett; metoden täcks i vår guide för att implementera webb-push utan leverantörslåsning.
Med den privata nyckeln i handen kan din nya leverantör importera push-prenumeranter direkt: varje slutpunkt, p256dh och auth-post flyttas över, och du kan skicka meddelanden till hela din befintliga lista från dag ett. Det inkluderar inaktiva prenumeranter som inte har besökt på månader. Ingen behöver anmäla sig igen. Ingen märker något.
En nyans som är värd att tydligt ange. Även i Scenario A slutförs den hållbara migreringen genom återbesök, eftersom varje prenumerant så småningom behöver landa på den nya service worker. De importerade nycklarna ger dig räckvidd från dag ett medan den här övergången sker tyst i bakgrunden.
Scenario B: nycklar stannar kvar, och den tysta återprenumerationen tar över
Scenario B är standardinställningen: leverantören genererade VAPID-nycklarna och behåller dem. Utan den privata nyckeln är exporterade poster kryptografiskt oanvändbara. Räckvidden från dag ett är noll, och din gamla leverantörs varning låter sann i ungefär ett stycke till.
Här är vad som faktiskt händer. Nästa gång varje prenumerant besöker din webbplats tar den nya leverantörens service worker över: den avregistrerar den gamla registreringen, avregistrerar den gamla prenumerationen och återregistrerar besökaren under de nya nycklarna. Tyst, under ett enda besök, utan en andra behörighetsfråga.
Varför den nya service worker inte behöver en andra fråga
Auktorisation för aviseringar ges till din domän, inte till en leverantör. Webbläsaren litar redan på din domän. Att byta service worker och nycklar under en redan beviljad auktorisation är osynligt för besökaren, eftersom webbläsaren behandlar det som att din webbplats organiserar om sin egen infrastruktur. Det är precis vad det är.
Två fallgropar din utvecklare bör känna till
En domän, en prenumeration. En webbläsare kan inte ha två push-prenumerationer för samma domän. Att prenumerera med en annan nyckel misslyckas tills den gamla prenumerationen släpps. Så "kör båda leverantörerna parallellt" fungerar på listnivå, aldrig inuti en enskild webbläsare: varje prenumerant är antingen hos den gamla leverantören eller den nya, och varje återbesök flyttar över ytterligare en.
Opt-ins för leverantörs-subdomäner flyttas aldrig. Prenumerationer som samlas in på yoursite.vendor.com tillhör leverantörens domän, och ingen leverantör kan migrera dem. Den basen byggs om från grunden. Det är den största fallgropen i alla push-meddelandemigreringar och det starkaste argumentet för att förankra prenumerationer till en domän du kontrollerar den här gången. Om du driver flera varumärken eller regionala domäner, formar samma domänlogik hela din arkitektur; vi täcker det i webbpush över flera domäner.
Här är de två scenarierna sida vid sida:
| Scenario A: nycklar reser | Scenario B: nycklar stannar kvar | |
|---|---|---|
| När det gäller | Egna VAPID-nycklar / eget Firebase-projekt, eller leverantören släpper paret | Leverantören genererade och behåller nycklarna (standardinställningen) |
| Räckvidd från dag 1 | Hela din lista, inklusive inaktiva prenumeranter | Noll, tills besökare återkommer |
| Vid varje återbesök | Prenumeranten flyttas tyst till de nya nycklarna | Tyst återprenumeration under de nya nycklarna, ingen andra fråga |
| Vem du återfår | Alla | Alla som besöker igen |
| Vem du förlorar | Ingen | Prenumeranter som aldrig återvänder (som ändå inte längre var nåbar intäkt) |
Varför publik som besöker dagligen slutför en push-notifikationsmigrering snabbast
I Scenario B är klockan för övertagande din publiks returfrekvens. Inget annat. En e-handelsprenumerant kan besöka månadsvis, så övertagandet sträcker sig över månader. En spelare kontrollerar odds, linjer och resultat dagligen. En nyhetsläsare återkommer för varje nyhetscykel.
Denna returytm är anledningen till att betting- och nyhetssajter är de bäst positionerade vertikalerna på internet för att byta leverantör av push-notifikationer: samma besöksfrekvens som gör push-notifikationer för bettingsajter till en kvarhållningsmotor, komprimerar också en migrering som tar andra sajter ett kvartal till en eller två veckor. Betting- och spelsajter på PushEngage har skickat över 3,5 miljarder notifikationer, så dessa övertagandemekanismer är en daglig produktionsverklighet för oss, inte teori.
| Publikens returmönster | Typiskt övertagande av aktiv bas |
|---|---|
| Dagliga besökare (liveodds, aktuella nyheter, dagliga kampanjer) | Dagar till ungefär en vecka |
| Flera besök per vecka (helgspelare, stamgäster) | 1–2 veckor |
| Veckovis eller mer sällan (säsongsbundna besökare, inaktiva användare) | Veckor, accelererat av gamla leverantörers sändningar och stora evenemang |
| Inaktiv (inget besök på månader) | Endast återställningsbar under Scenario A |
Detta är typiska mönster för publik som besöker dagligen, inte garantier; din kurva beror på din trafikrytm, och du kommer att se den live i instrumentpanelen. Du kan också böja kurvan: schemalägg övergången veckan före en stor matchhelg och evenemangstrafiken sköter övertagandet åt dig. Spelbolag som planerar en matchdagspushsekvens vet redan vilka helger det är.
App-push är enklare: dina tokens var alltid dina
Om du också skickar app-push, ta ett djupt andetag. Denna halva är strukturellt enkel, eftersom ingen leverantör kan hålla den som gisslan.
APN-certifikat och nycklar utfärdas till ditt Apple Developer-konto. Ditt FCM-projekt finns i din Google-konsol. En push-leverantör är ett lager ovanpå behörigheter du äger, så att byta innebär att peka ett nytt lager mot samma behörigheter. Enhetstokens exporteras och importeras rent, utan ominstallationer och utan en andra behörighetsfråga.
Två praktiska anmärkningar. För det första, filtrera tokenexporter till ungefär 270 dagar aktiva enheter innan du importerar, eftersom FCM behandlar tokens som är inaktiva längre än cirka 270 dagar som föråldrade. En token-dump på fem år blåser upp ditt prenumerantantal, och på prissättning som bara räknar aktiva prenumeranter, gynnar det ingen. För det andra, full SDK-täckning sker i den takt användare uppdaterar din app, vanligtvis en vecka eller två för en daglig app med automatiska uppdateringar.
Om din iOS-app för närvarande skickar via Firebase, är steg-för-steg-flödet ett eget ämne; se vår guide till migrering från Firebase Cloud Messaging på iOS istället för att improvisera den från det här inlägget.
Innan du byter leverantör av push-notifikationer, ställ dessa sex frågor skriftligen
Leverantörsexporter och nyckelprinciper varierar och de ändras. Istället för att lita på någon tabell med leverantörsbedömningar (inklusive en som vi skulle kunna publicera), skaffa dina egna leverantörers svar officiellt. E-post fungerar; en supportbiljett fungerar bättre. Om du utvärderar destinationer samtidigt, fungerar samma frågor som en användbar granskning när du jämför OneSignal-alternativ.
- Kan ni exportera mina fullständiga webb push-prenumerationsregister – slutpunkts-URL plus
p256dh- ochauth-nycklarna för varje prenumerant – eller bara interna ID:n? Interna ID:n är meningslösa utanför leverantörens system. - Kommer ni att släppa VAPID-nyckelpar som mina prenumerationer skapades under? Detta enda svar avgör Scenario A kontra Scenario B.
- Vilket FCM- eller Firebase-projekt kör min webb push på, mitt eller ert? Om det är ert, kan nycklarna redan finnas i er egen konsol.
- Kan jag exportera segment, taggar, prenumerantattribut och undertryckningslistor separat? De följer inte med prenumerationsregistren automatiskt.
- Kan jag exportera mina app push-enhetstokens, och i vilket format?
- Vad händer med mina data om jag nedgraderar eller avbryter – finns det en automatisk radering eller en kvarhållningsperiod? Vissa leverantörer rensar inaktiva prenumerantdata på lägre nivåer. Exportera först, alltid.
Checklistan för migrationsveckan
Skriv ut den här sektionen. Åtta steg, i ordning.
- Exportera allt innan du avbryter eller nedgraderar något. Prenumerationsregister, apptokens, segment, taggar, attribut, undertryckningslistor. Exportåtkomst upphör med ditt kontrakt.
- Få svaret om VAPID-nycklar skriftligt. Det avgör ditt scenario och om du kan importera push-prenumeranter från dag ett.
- Flytta undertryckningslistor först, inte sist. För speloperatörer är detta icke-förhandlingsbart: självuteslutna spelare måste undertryckas på den nya plattformen innan en enda kampanj återupptas, inte avstämmas efteråt.
- Filtrera apptokens till ~270 dagars aktivitet före import.
- Installera det nya SDK:t och service worker, och slå samman med befintlig service worker (en PWA-skal, den gamla leverantörens worker) snarare än att skriva över den.
- Ta inte bort den gamla leverantörens service worker-fil från dag ett. Återkommande besökare har fortfarande registreringar som pekar på den; övertagandet avregistrerar dem smidigt. Ta bort filen tidigt och du genererar konsolfel istället för migreringar. Ta bort den vid slutlig nedmontering.
- Låt den gamla leverantören fortsätta skicka under parallellperioden. Kontraintuitivt men kritiskt: varje avisering som den gamla leverantören skickar driver ett återbesök, och varje återbesök slutför migreringen av ytterligare en prenumerant. Din utgående leverantör blir ditt bästa migreringsverktyg.
- Mät övertagandet dagligen och byt över vid platån. Spåra ny aktiv bas mot gammal aktiv bas. När kurvan planar ut, slutför nedmonteringen, avbryt det gamla kontraktet och arkivera exporten.
Vad byte kostar när PushEngage gör det åt dig
På PushEngage är migrering en förstklassig tjänst som ingår gratis i betalda planer. Du får en migreringstekniker, inte en hjälpcenterartikel: de hanterar exportmappning, nyckelhantering, sammanslagning av service workers och övertagandeplanen. Det spelar roll eftersom felen är tysta – en rå import med felaktiga payloadformat kan leverera tekniskt lyckade men tomma aviseringar, vilket är precis den typ av tysta fel som en specialist fångar innan dina prenumeranter gör det.
Samordningssamtalet tar cirka femton minuter: antal prenumeranter per kanal, nuvarande leverantör och nyckelfrågorna ovan. I slutet av det vet du om du är Scenario A eller B, och du har en daterad plan.
Om du är redo att byta leverantör av push-aviseringar, börja med de sex skrivna frågorna i det här inlägget och se hur din nuvarande leverantör svarar. Titta sedan på vad en webb push-aviseringplattform byggd kring segmentering och intäktsattribuering skulle göra med listan du redan äger, och jämför PushEngage prissättning med din nuvarande faktura. Varje betald plan har en 14-dagars pengarna-tillbaka-garanti, så själva push-aviseringmigreringen är den minst riskfyllda delen av beslutet.
