Din måndagskontroll av spelarbibehållning öppnas i samma diagram som alltid. Dag 1-bibehållning ligger runt 27%. Dag 7 har sjunkit till 8%. Vid dag 30 är färre än två spelare av hundra fortfarande aktiva i appen. Pushnotiser du skickade förra veckan gav en respektabel öppningsfrekvens, och ändå rörde sig inte kurvan. Den där klyftan, mellan en notis som klickas på och en spelare som faktiskt kommer tillbaka och fortsätter spela, är hela problemet med hur de flesta studior använder pushnotiser för spelarbibehållning.
Siffrorna ovan är inte ovanliga. GameAnalytics 2025 mobila spelriktmärken placerar median Day 7-bibehållning mellan 3,4 % och 3,9 %, med även toppkvartilstitlar runt 7–8 %, och median Day 30-bibehållning under 1 %. Push är en av få egna kanaler som kan ingripa innan en spelare glider nerför den kurvan. Men det fungerar bara när det byggs som en uppsättning utlösta arbetsflöden kopplade till beteende och intäkter i spelet, inte som en kalender med utskick mätta i öppningar.
Den här artikeln beskriver den metoden: varför öppningar är fel poängtavla, de fyra livscykelsögonblicken som avgör om en spelare återvänder, fyra pushnotisarbetsflöden du kan bygga mot dem, app-push-plus-webb-push-spåret som dina konkurrenter ignorerar, och hur du attribuerar varje notis till intäkter i spelet snarare än klick.
- Varför de flesta spel-pushnotiser öppnas och ignoreras
- Spelarbibehållning är en livscykel, inte ett utskick: de fyra ögonblicken som avgör om en spelare kommer tillbaka
- Fyra pushnotisarbetsflöden för spelarbibehållning (utlösare, timing, avslutningskriterier)
- App-push och webb-push tillsammans: kanalen som SERP glömde
- Koppla varje notis till intäkter i spelet, inte öppningar
- Segmentering är bibehållningsarbetet: progression, spenderande och aktualitet
- Vad push inte kan fixa, och vad det faktiskt kostar
Varför de flesta spel-pushnotiser öppnas och ignoreras
En öppning är inte en återkomst. En återkomst är inte en spelsession. En spelsession är inte progression. Och progression är vad som faktiskt förutsäger om en spelare fortfarande är kvar dag 30. När en notis ger ett klick men spelaren studsar från startsidan, eller spelar i fyrtio sekunder och slutar, bryr sig bibehållningskurvan inte om att din öppningsfrekvens var 22 %.
Det här är mätfällan som nästan varje guide om spel-pushnotiser hamnar i. De optimerar rubriken, emojin och sändningstiden för att öka öppningar, och rapporterar sedan öppningsfrekvensen som segern. Öppningar är i bästa fall en ledande indikator och i värsta fall en fåfängamätning. Det beteende du behöver är en återvändande spelare som når nästa meningsfulla milstolpe.
Push-notiser kan styra beteendet. De kan inte fejka det. En notis kan sätta en spelare framför en anledning att spela: en oavhämtad belöning, en väns tur, en fylld energibar, en begränsad händelse som snart avslutas. Vad som händer sedan bestäms av din spel-loop. Så push-notisernas jobb för spelarbehållning är smalt och specifikt: leverera rätt anledning att återvända, till rätt spelare, i det ögonblick då anledningen är verklig, och mät sedan om de fortskred, inte om de klickade.
Spelarbibehållning är en livscykel, inte ett utskick: de fyra ögonblicken som avgör om en spelare kommer tillbaka
Spelarbehållningsstrategierna som faktiskt fungerar utlöses av beteende, inte kalendern. "Tisdag kl. 18 till alla" är en massutskick. "Utlöses i samma ögonblick som en spelare installerar men inte har slutfört handledningen efter 20 minuter" är en trigger. Triggers mappar till livscykelns ögonblick, och fyra ögonblick gör det mesta av arbetet.
Spelarbibehållningsstrategierna som kartläggs till varje ögonblick
| Livscykelns ögonblick | Den beteendemässiga signalen | Vad som står på spel |
|---|---|---|
| Första sessionen | Installerat, men första milstolpen inte nådd | Den brantaste avhoppskurvan i hela kurvan; de flesta spelare som slutar, slutar här |
| Introduktion till vana | Spelat några gånger, ingen rutin har bildats än | Spelaren blir aldrig en regelbunden spelare; Dag 7 kollapsar |
| Vana till lojal | Spelar regelbundet, når en svit eller en progressionsvägg | En frustrerad eller uttråkad regelbunden spelare driver mot inaktivitet |
| Glider mot inaktivitet | Dagar sedan senaste sessionen passerar en tröskel | Spelaren är borta om den inte återaktiveras; full återanskaffningskostnad hotar |
Varje ögonblick är en trigger som väntar på att byggas. Första sessionsögonblicket är det som resten av SERP behandlar som en fotnot, trots att det är där det mesta av kurvan går förlorad. En spelare som inte når en första vinst under de första minuterna återvänder sällan på egen hand. Det är en realtids-trigger, inte ett mejl nästa dag.
Fyra pushnotisarbetsflöden för spelarbibehållning (utlösare, timing, avslutningskriterier)
Här är fyra arbetsflöden som täcker ovanstående livscykel. Varje definieras på det sätt som en behållningsoperatör bör definiera det: en trigger som startar det, tid mellan beröringar, meddelandets jobb och den del som nästan alla konkurrerande artiklar utelämnar, ett avslutningskriterium så att spelaren slutar höra från ett arbetsflöde när det har gjort sitt jobb. Du kan bygga arbetsflödet visuellt utan en ingenjörsbiljett, vilket spelar roll när de som äger behållningen inte är de som äger bygget.
| Arbetsflöde | Utlösare | Timing | Meddelandets jobb | Avslutningskriterium |
|---|---|---|---|---|
| Räddning av första sessionen | Installation utan första milstolpe | +20 min, +24 timmar | Dra tillbaka spelaren till den första vinsten de nästan nådde | Första milstolpen nådd |
| Vanebyggare / svitbevarare | 2+ sessioner, ingen daglig rutin | Dagligen vid spelarens vanliga speltid, max 1/dag | Skydda en svit, visa dagens anledning att öppna | Vana bildad (t.ex. 5 sessioner på 7 dagar) eller spelaren blir inaktiv → överlämnas till återaktivering |
| Progression & belöning återinträde | Okrävd belöning, fylld energi eller nytt innehåll | Händelsebaserad, utlöses när anledningen blir sann | “Din belöning väntar” / “Din tur i matchen” | Belöning krävdes eller innehåll visades |
| Spelaren tappar fart – återaktivering | 7–14 dagar sedan senaste sessionen | +7 dagar, +14 dagar, sluta sedan | Erbjud en specifik anledning att återvända, inte skuld | Spelaren återvänder, eller arbetsflödet avslutas (ingen evig tjatande) |
Några anteckningar som en verklig byggnad skulle respektera. Sparandet av första sessionen är det mest effektiva arbetsflödet du äger, eftersom det ingriper vid den brantaste delen av kurvan; dess första kontakt bör referera till exakt det spelaren höll på att få, hämtat från dina egna mallar för push-meddelanden vid introduktion. Ett sparande av första sessionen är egentligen ett välkomstmeddelande med en tidsgräns.
Svitbevararen måste respektera tysta timmar och en frekvensbegränsning, annars blir den anledningen till att en spelare stänger av dig. Återaktiveringsflödet finns för att återengagera inaktiva spelare innan de är borta för gott. Det är avsiktligt kort här, två kontakter och ett hårt stopp, eftersom djup återaktivering är en egen disciplin; om du vill ha hela sekvensdesignen, se hur du återengagerar bortfallna spelare.
Exempeltext för sparande av första sessionen, andra kontakten: “Du var två drag från att klara Nivå 1. Den finns kvar när du är redo.” Ingen utropstecken, ingen falsk brådska, en konkret referens till var spelaren faktiskt slutade.
App-push och webb-push tillsammans: kanalen som SERP glömde
Vad push-meddelanden i spelappar inte kan nå
Varje konkurrerande artikel om detta ämne antar en leveransyta: en mobilapp som skickar spel-push-meddelanden via FCM eller APNs. Det mesta av täckningen av push-meddelanden i spelappar stannar precis där, vid en enda yta. Det antagandet gör spelare otillgängliga. Spel lever inte bara inuti en installerad app.
De lever på kompletterande webbplatser där spelare kontrollerar topplistor, på HTML5- och webbläsarbyggen, på community- och patch-notes-sidor och på skrivbordsstartare. En spelare som aldrig installerar appen, eller som avinstallerade den men fortfarande besöker din webbplats, är osynlig för en app-enlig stack.
Det är här att köra webb-push-meddelanden tillsammans med push-meddelanden i spelappar ändrar matematiken. Webb-push-val är inte begränsat bakom en appbutiksinstallation, så en besökare på ditt webbläsarspel eller din kompletterande webbplats kan prenumerera med ett klick, och du kan nå dem igen oavsett om de någonsin laddar ner appen eller inte. Tänk på en spelare som spelar ditt HTML5-spel på skrivbordet på jobbet och aldrig har rört mobilbygget. App-push kan inte nå dem. Webb-push kan, med samma “din tur”-meddelande som appen skickar.
Poängen är inte ”använd två verktyg”. Det är en prenumerantidentitet, ett arbetsflöde och ett frekvens tak som spänner över båda ytorna, så en spelare som är aktiv i appen inte också blir pingad på webben för samma händelse. Den orkestreringen över egna kanaler är det drag som ingen app-enbart konkurrent på första sidan av resultaten kan göra.
Koppla varje notis till intäkter i spelet, inte öppningar
En retentionägare måste så småningom försvara kanalen för någon som kontrollerar budgeten. ”Vår återaktiveringspush gav en öppningsgrad på 19 %” överlever inte det samtalet. ”Vårt arbetsflöde för att spara första sessionen returnerade 4 100 spelare förra månaden, varav 1 300 nådde första köppunkten, vilket genererade 11 400 USD i intäkter från köp i spelet” gör det.
Kedjan du behöver instrumentera körs: notis levererad → session startad → milstolpe eller progression nådd → köp i spelet eller annonsvisning → 30-dagars LTV. Målspårning på notisnivå sluter cirkeln och attribuerar intäkter till det specifika arbetsflödet och den beröring som producerade det, snarare än till push som en odifferentierad klump.
När du kan se intäkter per arbetsflöde slutar du att finjustera för öppningar och börjar skära bort de beröringar som flyttar klick men inte pengar, och dubblar de som flyttar LTV.
Gör notiser om köp i spelet till en spårad intäktsrad
Det är också så notiser om köp i spelet tjänar sin plats. Spåra notiser om köp i spelet som sitt eget arbetsflöde med målspårning kopplad, och intäkter per beröring slutar vara en gissning. Ett meddelande som ”din belöning väntar” är inte en trevlighetsdetalj för retention när du kan visa att det returnerade spelare som sedan konverterade. Det är en intäktslinje du kan attribuera, försvara och skala.
Segmentering är bibehållningsarbetet: progression, spenderande och aktualitet
Varje guide säger ”segmentera dina spelare”. Få säger hur, för ett spel. Retentionversionen av RFM är byggd från tre axlar du redan spårar: progressionsnivå, spendertier och aktualitet (dagar sedan senaste session). Kors dem och arbetsflödena ovan skärps från breda till kirurgiska.
Tre sammansatta segment värda att bygga först:
- Slippande hög-värdespelare. Topp spendertier, djup progression, 7+ dagar sedan senaste session. Detta är din dyraste spelare att förlora och din billigaste att vinna tillbaka, så dirigera dem till en prioriterad återvinning med en genuint värdefull anledning att återvända, inte en generell knuff.
- Tutorial-avhoppare. Installerat, aldrig klarat första milstolpen, låg aktualitet. Första sessionssparandet finns för exakt detta segment; slösa inte bort streak-meddelanden på en spelare som aldrig började.
- Endast helg-casual. Mellanprogression, spelar bara lördag och söndag. Undertryck vardagliga sändningar och koncentrera streak-hållaren på deras faktiska spelfönster.
Segmentering är vad som håller dessa spelar-retentionstrategier från att bli brus. Samma arbetsflöde som behåller en glidande val kommer att irritera en tutorial-avhoppare. Segmentet bestämmer vem varje trigger avfyras på, och att få det rätt är det mesta av skillnaden mellan en kanal spelare behåller och en kanal de stänger av.
Vad push inte kan fixa, och vad det faktiskt kostar
Push förstärker en spel-loop som är värd att återvända till. Den kan inte skapa en. Om spelare slutar spela för att kärn-loopen är tunn, svårighetsgraden ökar orättvist, eller monetariseringen är fientlig, kommer ingen notifikationskadens att hålla kurvan, och att skicka mer push till ett spel som spelare har bestämt sig för att lämna påskyndar bara avprenumerationerna. Den ärliga versionen av push-notiser för spelbehållning börjar med att acceptera att push är en återvändningsväg, inte en anledning att spela.
Med tanke på det är kostnadsfrågan viktig. Att förvärva en ny spelare medför en fullständig installationskostnad: UA-utgifter, butiksavgifter, hela tratten. Att återengagera inaktiva spelare kostar en bråkdel av det, eftersom relationen och kanalen redan finns. Prismodellen bör matcha den logiken.
PushEngage debiterar endast för aktiva prenumeranter, så när en spelare blir inaktiv och du slutar nå dem, krymper räkningen snarare än växer med en lista du inte längre skickar meddelanden till. Jämför det med debitering per meddelande eller liststorleksprissättning, och med Firebase push-notisprissättningens avvägningar som studior väger när deras volym av app-push-notiser för spel skalar.
Det är modellen PushEngage kör på: betala bara för aktiva prenumeranter.
Det är behållningsmatematiken i en enda mening: den billigaste tillväxten ett spel har är spelaren som redan har installerat det. Bygg de fyra arbetsflödena, kör dem över app- och webb-push, segmentera efter progression och utgifter, och mät i intäkter. Det är så push-notiser för spelbehållning slutar vara en veckovis utblåsning och börjar flytta kurvan du öppnar varje måndag.
Redo att bygga ditt första arbetsflöde för att rädda första sessionen? Börja med planen betala bara för aktiva prenumeranter och lansera det den här veckan.
