Du har opbygget din liste over push-abonnenter én hårdt tilkæmpet tilmelding ad gangen, og hver tilmelding kostede rigtige anskaffelsespenge. Så når det er tid til at skifte push-notifikationsudbydere, er frygten specifik: opsig den gamle kontrakt, og listen forsvinder med den. Din nuværende leverandør vil måske endda fortælle dig præcis det.
Det er ikke sandt, og denne guide viser dig hvorfor på browserens niveau. Et web push-abonnement er bundet til dit domæne, ikke til din leverandør. Når du først ser mekanikken, bliver hvert skift til et af to rene scenarier, en kort liste over skrevne spørgsmål til din nuværende leverandør og en uges tjekliste, som dit team kan køre uden drama.
En ærlig bemærkning på forhånd. Hvert leverandørs salgsteam, inklusive vores, vil fortælle dig, at migrering er let. De fleste stopper der. Dette indlæg viser dig mekanismen i stedet, så din udvikler kan verificere ethvert krav, inklusive dem, vi fremsætter til sidst.
Hvad et web push-abonnement faktisk er
Når en besøgende klikker på "Tillad" på dit websted, opretter browseren et web push-abonnement bygget på tre dele:
- Din oprindelse. Det præcise domæne, tilladelsen blev givet på (
https://yoursite.com). Tilladelsen lever i browseren, knyttet til oprindelsen. Den nævner ingen leverandør. - En service worker. En lille JavaScript-fil hostet på dit domæne, der modtager og viser notifikationer. Uanset hvilken service worker der er registreret, styrer den leveringen.
- En applikationsservernøgle. Den offentlige halvdel af et VAPID-nøglepar. Browserens push-tjeneste accepterer kun afsendelser signeret med den matchende private nøgle. Enhver, der besidder den private nøgle, kan sende beskeder til abonnementet. (web.devs oversigt over push-notifikationer dækker hele protokollen.)
Selve abonnementsoptegnelsen består af tre strenge: en slutpunkt-URL plus to korte nøgler, p256dh og auth. Det er hele aktivet. Hele din liste er en tabel over disse optegnelser.
Én regel bestemmer alt efterfølgende: browsere accepterer kun afsendelser fra indehaveren af den matchende VAPID private nøgle. Hvilket betyder, at hver leverandørskift løser sig i præcis to scenarier, afhængigt af hvor disse nøgler bor.
Scenarie A: dine VAPID-nøgler følger med, så du importerer push-abonnenter fra dag ét
Scenarie A gælder, når nøglerne er dine til at tage: du konfigurerede dine egne VAPID-nøgler eller dit eget Firebase-projekt ved opsætningen, eller din udgående leverandør accepterer at udlevere nøgleparret. Nogle teams opsætter dette bevidst fra dag ét; tilgangen er dækket i vores guide til implementering af web push uden leverandørlåsning.
Med den private nøgle i hånden kan din nye udbyder importere push-abonnenter direkte: hver endpoint, p256dh og auth-post flyttes over, og du kan sende beskeder til hele din eksisterende liste fra dag ét. Det inkluderer inaktive abonnenter, der ikke har besøgt i månedsvis. Ingen gen-tilmelder sig. Ingen bemærker det.
En nuance, der er værd at sige ligeud. Selv i scenarie A fuldføres den holdbare migrering stadig gennem genbesøg, fordi hver abonnent i sidste ende skal lande på den nye service worker. De importerede nøgler giver dig dag-et-rækkevidde, mens den udrulning sker stille i baggrunden.
Scenarie B: nøgler bliver tilbage, og den stille gen-tilmelding overtager
Scenarie B er standardindstillingen: leverandøren genererede VAPID-nøglerne og beholder dem. Uden den private nøgle er eksporterede poster kryptografisk ubrugelige. Dag-et-rækkevidde er nul, og din gamle leverandørs advarsel lyder sand i cirka endnu et afsnit.
Her er, hvad der faktisk sker. Næste gang hver abonnent besøger dit websted, overtager den nye udbyders service worker: den afregistrerer den gamle registrering, afmelder det gamle abonnement og gen-abonnerer den besøgende under de nye nøgler. Stille, på et enkelt besøg, uden en anden tilladelsesprompt.
Hvorfor den nye service worker ikke behøver en anden prompt
Notifikationstilladelse gives til din oprindelse, ikke til en leverandør. Browseren stoler allerede på dit domæne. At udskifte service worker og nøgler under en allerede givet tilladelse er usynligt for den besøgende, fordi browseren behandler det som dit websted, der omorganiserer sin egen infrastruktur. Det er præcis, hvad det er.
To fælder din udvikler bør kende til
Én oprindelse, ét abonnement. En browser kan ikke have to push-abonnementer for den samme oprindelse. Tilmelding med en anden nøgle mislykkes, indtil det gamle abonnement er frigivet. Så "kør begge leverandører parallelt" virker på listeniveau, aldrig inde i en enkelt browser: hver abonnent er på den gamle leverandør eller den nye, og hvert genbesøg flytter én mere over.
Leverandør-underdomæne tilmeldinger flytter aldrig. Abonnementer indsamlet på yoursite.vendor.com tilhører leverandørens oprindelse, og ingen udbyder kan migrere dem. Den base genopbygges fra bunden. Det er den største fælde i enhver push-notifikationsmigrering og det stærkeste argument for at forankre abonnementer til et domæne, du kontrollerer denne gang. Hvis du driver flere brands eller regionale domæner, former den samme oprindelseslogik hele din arkitektur; vi dækker det i web push på tværs af flere domæner.
Her er de to scenarier side om side:
| Scenarie A: nøgler rejser | Scenarie B: nøgler bliver tilbage | |
|---|---|---|
| Hvornår det gælder | Egne VAPID-nøgler / eget Firebase-projekt, eller leverandøren frigiver parret | Leverandøren genererede og beholder nøglerne (standardindstillingen) |
| Dag-1 rækkevidde | Hele din liste, inklusive inaktive abonnenter | Nul, indtil besøgende vender tilbage |
| Ved hvert genbesøg | Abonnenten flytter stille over på de nye nøgler | Stille gen-tilmelding under de nye nøgler, ingen anden prompt |
| Hvem du genvinder | Alle | Alle, der besøger igen |
| Hvem du mister | Ingen | Abonnenter, der aldrig vender tilbage (som alligevel ikke længere var en indtægtskilde) |
Hvorfor daglige publikummer afslutter en push-notifikationsmigrering hurtigst
I scenarie B er overtagelsestimeren dit publikums returfrekvens. Intet andet. En e-handelsabonnent besøger måske månedligt, så overtagelsen strækker sig over måneder. En spiller tjekker odds, linjer og resultater dagligt. En nyhedslæser vender tilbage for hver overskriftscyklus.
Den returrytme er grunden til, at betting- og nyhedssider er de bedst positionerede vertikaler på internettet til at skifte push-notifikationsudbydere: den samme besøgsfrekvens, der gør push-notifikationer til betting-sider til en fastholdelsesmotor, komprimerer også en migrering, der tager andre sider et kvartal, til en uge eller to. Betting- og spilsider på PushEngage har sendt over 3,5 milliarder notifikationer, så disse overtagelsesmekanikker er en daglig produktionsvirkelighed for os, ikke teori.
| Publikums returmønster | Typisk aktiv baseovertagelse |
|---|---|
| Daglige besøgende (live odds, breaking news, daglige kampagner) | Dage til cirka en uge |
| Flere besøg om ugen (weekendspillere, stamgæster) | 1–2 uger |
| Ugentligt eller mindre (sæsonbestemte besøgende, inaktive brugere) | Uger, accelereret af gamle leverandør-sends og store begivenheder |
| Dvalende (ingen besøg i måneder) | Kun genoprettelig under scenarie A |
Dette er typiske mønstre for daglige besøgende, ikke garantier; din kurve afhænger af din trafikrytme, og du vil se den live i dashboardet. Du kan også bøje kurven: planlæg overgangen ugen før en stor kampagne-weekend, og begivenhedstrafikken klarer overtagelsen for dig. Sportsbooks, der planlægger en kampagnedags push-sekvens, ved allerede, hvilke weekender det er.
App push er enklere: dine tokens var altid dine
Hvis du også sender app push, tag en dyb indånding. Denne halvdel er strukturelt let, fordi ingen leverandør kan holde den som gidsel.
APNs-certifikater og nøgler udstedes til din Apple Developer-konto. Dit FCM-projekt lever i din Google-konsol. En push-leverandør er et lag oven på legitimationsoplysninger, du ejer, så skift betyder at pege et nyt lag på de samme legitimationsoplysninger. Enhedstokens eksporteres og importeres rent, uden geninstallationer og uden en anden tilladelsesprompt.
To praktiske bemærkninger. For det første, filtrer token-eksport til cirka 270 dage aktive enheder, før du importerer, fordi FCM behandler tokens, der er inaktive ud over ca. 270 dage, som forældede. En dump af tokens fra fem år oppuster dit abonnentantal, og på priser, der kun tæller aktive abonnenter, er der ingen, der drager fordel af det. For det andet, fuld SDK-dækning ankommer med den hastighed, brugerne opdaterer din app, typisk en uge eller to for en daglig brugsapp med automatiske opdateringer.
Hvis din iOS-app i øjeblikket sender via Firebase, er trin-for-trin-flowet et emne for sig; se vores guide til migrering fra Firebase Cloud Messaging på iOS i stedet for at improvisere det ud fra dette indlæg.
Før du skifter push-notifikationsudbydere, stil disse seks spørgsmål skriftligt
Leverandøreksport og nøglepolitikker varierer og ændrer sig. I stedet for at stole på en tabel med leverandørdomme (inklusive en, vi kunne udgive), skal du få din egen leverandørs svar på rekord. E-mail fungerer; en supportbillet fungerer bedre. Hvis du evaluerer destinationer på samme tid, giver de samme spørgsmål en nyttig screening, mens du sammenligner OneSignal-alternativer.
- Kan du eksportere mine komplette web push-abonnementsregistre — slutpunkt-URL plus
p256dh- ogauth-nøglerne for hver abonnent — eller kun interne ID'er? Interne ID'er er meningsløse uden for leverandørens system. - Vil du frigive VAPID-nøgleparret, som mine abonnementer blev oprettet under? Dette ene svar afgør Scenarie A versus Scenarie B.
- Hvilket FCM- eller Firebase-projekt kører min web push på, mit eller dit? Hvis det er dit, er nøglerne muligvis allerede i din egen konsol.
- Kan jeg eksportere segmenter, tags, abonnentattributter og undertrykkelseslister separat? De følger ikke automatisk med abonnementsregistrene.
- Kan jeg eksportere mine app push-enhedstokens og i hvilket format?
- Hvad sker der med mine data, hvis jeg nedgraderer eller annullerer — er der en automatisk sletning eller et opbevaringsvindue? Nogle leverandører sletter inaktive abonnentdata på lavere niveauer. Eksporter først, altid.
Tjeklisten for migrationsugen
Udskriv denne sektion. Otte trin, i rækkefølge.
- Eksporter alt, før du annullerer eller nedgraderer noget. Abonnementsregistre, app-tokens, segmenter, tags, attributter, undertrykkelseslister. Eksportadgang dør med din kontrakt.
- Få VAPID-nøglesvaret skriftligt. Det afgør dit scenarie og om du kan importere push-abonnenter fra dag ét.
- Flyt undertrykkelseslister først, ikke sidst. For betting- og spiloperatører er dette ikke til forhandling: selvudelukkede spillere skal undertrykkes på den nye platform, før en enkelt kampagne genoptages, ikke afstemmes bagefter.
- Filtrer app-tokens til ~270 dages aktivitet før import.
- Installer det nye SDK og service worker, og flet med enhver eksisterende service worker (en PWA-skal, den gamle leverandørs worker) snarere end at overskrive den.
- Slet ikke den gamle leverandørs service worker-fil på dag ét. Tilbagevendende besøgende har stadig registreringer, der peger på den; overtagelsen afmelder dem yndefuldt. Fjern filen tidligt, og du genererer console-fejl i stedet for migrationer. Fjern den ved den endelige nedlukning.
- Lad den gamle leverandør sende gennem det parallelle vindue. Kontraintuitivt, men kritisk: hver notifikation, den gamle leverandør sender, driver et genbesøg, og hvert genbesøg fuldfører migrationen af endnu en abonnent. Din udgående leverandør bliver dit bedste migrationsværktøj.
- Mål overtagelsen dagligt og skift over ved plateauet. Spor ny aktiv base mod gammel aktiv base. Når kurven flader ud, afslut nedlukningen, annuller den gamle kontrakt, og arkiver eksportene.
Hvad skifteomkostninger koster, når PushEngage gør det for dig
Hos PushEngage er migrering en "white-glove"-service, der er inkluderet gratis på betalte planer. Du får en migrationsingeniør, ikke en hjælpcenterartikel: de håndterer eksportmapping, nøglehåndtering, serviceworker-fletning og overtagelsesplanen. Det betyder noget, fordi fejltilstandene er stille – en rå import med forkerte payload-formater kan levere teknisk succesfulde, men tomme notifikationer, hvilket er præcis den type stille fejl, en specialist fanger, før dine abonnenter gør.
Scoping-opkaldet tager cirka femten minutter: abonnentantal pr. kanal, nuværende leverandør og ovenstående nøglespørgsmål. Ved slutningen af det ved du, om du er i Scenarie A eller B, og du har en dateret plan.
Hvis du er klar til at skifte udbyder af push-notifikationer, skal du starte med de seks skrevne spørgsmål i dette indlæg og se, hvordan din nuværende leverandør svarer. Se derefter på, hvad en web push-notifikationsplatform bygget omkring segmentering og indtægtsattribution ville gøre med listen, du allerede ejer, og tjek PushEngage-priser mod din nuværende faktura. Hver betalt plan har en 14-dages pengene-tilbage-garanti, så selve push-notifikationsmigreringen er den laveste risiko-del af beslutningen.
