Din app skickar tre meddelanden inom en minut och spelarens telefon visar dem som en banner. Det är inte ett fel i din push-leverantör. Det är Androids meddelandekylning, aktiverad som standard i Android 16, och den skriver tyst om reglerna för alla avsändare med hög volym. Om du hanterar push för en betting- eller spelapp är dina mest värdefulla ögonblick exakt de som den riktar sig mot: ett mål, en oddsändring och en uppmaning till uttag landar inom samma sextio sekunder. Det här inlägget täcker vad kylningen gör, FCM-hastighetsbegränsningarna som redan fanns under den, och sändningsdesignmönster som ser till att din app blir hörd.
Vad Androids meddelandekylning gör med en burst
Android 16 nådde stabil version den 10 juni 2025, och meddelandekylningen levererades med den, aktiverad som standard. Beteendet dokumenterades först i Android 16 utvecklarförhandsvisningar i slutet av 2024, då det fortfarande var en valfri inställning. I den stabila versionen slog Google på den för alla.
Mekaniken är enkel. När en app skickar en burst av meddelanden, varnar det första normalt, med full volym, med en full banner. Varje efterföljande meddelande i burstet sänks gradvis i volym och minimeras visuellt, i upp till en minut, och burstet grupperas under en enda banner. Ingenting raderas. Meddelandena kommer fortfarande fram, ligger fortfarande i meddelandefältet, räknas fortfarande i dina leveransrapporter. De slutar bara att kräva uppmärksamhet.
Den sista punkten är viktig för hur du läser dina instrumentpaneler. Leveranshastigheten kommer inte att ändras. Det som ändras är allt nedströms från uppmärksamhet: visningar, klick och de konverteringar som dina andra och tredje sändningar skulle driva.
Android 16-meddelanden: vad som fortfarande varnar, vad som tystas
Kylningen behandlar inte alla Android 16-meddelanden lika. Samtal, larm och prioriterade konversationer är undantagna; de varnar normalt oavsett hur snabbt de staplas. Allt annat är föremål för tystningskurvan, och det täcker alla betting-appmeddelanden, både marknadsföring och transaktionella.
En tillämplighetsanmärkning, och det är en slutsats snarare än ett dokumenterat plattformsuttalande: kylningen fungerar på meddelandeskiktet, så genom mekanism bör den gälla både för FCM-levererade app-pushar och för webb-push-meddelanden som Chrome renderar på Android. Om ditt varumärke driver både en app och en mobilwebbplats, behandla Android 16-meddelanden från båda kanalerna som att de delar en uppmärksamhetsbudget på samma enhet.
FCM-hastighetsbegränsningar begränsade dig redan
Nedkylningen är det synliga lagret. Under det har Firebase Cloud Messaging i åratal haft begränsningar per enhet. FCM-dokumentationen anger gränserna till 240 meddelanden per minut och 5 000 per timme till en enskild enhet, och varnar för att avsändare som kör nära dessa gränser riskerar att appen flaggas som missbrukande.
Ingen vettig kampanj skickar 240 meddelanden per minut till en användare. Men dessa FCM-hastighetsgränser är per enhet, inte per kampanj, vilket innebär att varje system du kör skickar mot samma delade budget: ditt CRM, dina oddsvarningar från handelssystemet, din kampanjschemaläggare, ditt transaktionslager. En arkitektur där fyra system var och en beter sig rimligt kan fortfarande ge ett enhetsnivåmönster som FCM uppfattar som missbruk och som en burst för nedkylningen.
De två mekanismerna förstärker varandra. FCM-hastighetsgränserna begränsar vad som fysiskt kan anlända; Android-notifikationsnedkylningen bestämmer hur mycket av det som anländer som uppmärksammas. Avsändare med hög volym designar nu mot båda samtidigt.
Varför notifikationer från spelappar skickas i burst-läge till att börja med
Spelappar skickar inte i burst-läge för att CRM-team är slarviga. De skickar i burst-läge för att produktens bästa ögonblick är av naturen samtidiga. Ett mål i en match du följer är, i samma ögonblick, en poängvarning, en oddsförändring och en möjlighet att ta ut pengar. Tre olika system ansvarar för ett av dessa meddelanden var, och inget av dem kontrollerar vad de andra två just skickade.
Här är burst-läget som spelarens telefon upplever det under nedkylning:
| Tid | System | Meddelande | Vad spelaren upplever |
|---|---|---|---|
| 0:00 | CRM / händelseflöde | “MÅL. 1–0 i matchen du följer” | Fullständig varning: ljud, vibration, banner |
| 0:15 | Handelssystem | “Oddsen har ändrats på nästa målmarknad” | Dämpad: minskad volym, minimerad, grupperad |
| 0:40 | Kampanjmotor | “Ta ut pengar nu tillgängligt på ditt öppna spel” | Ännu mer dämpad: nästan tyst, hopslagen i gruppen |
Det smärtsamma är ordningen. Erbjudandet om att ta ut pengar, den notifikationen i den burst-sändningen som har direkt intäkt kopplad till sig, är den som nedkylningen begravde, eftersom den anlände som tredje. Den som skickar först äger minuten. Just nu, i de flesta notifikationsstackar för spelappar, är vinnaren det system som har lägst latens, inte det meddelande som betyder mest.
Push-sekvensen på matchdagen har alltid krävt medveten sekvensering. Nedkylningen gör det från hantverk till ett krav.
Designmönster som överlever push-notifikationsbursts
Du kan inte stänga av nedkylningen för dina användare, och du bör inte heller vilja det; den straffar exakt det mönster som dina spelare redan ogillade. Lösningen är arkitektonisk. Fyra mönster hindrar push-notifikationsbursts från att äta upp din räckvidd.
Sprid ut sändningar per minuter, inte sekunder
Nedkylningsfönstret löper upp till en minut. Två notifikationer som du kontrollerar och som landar inom det fönstret konkurrerar om en varning. Så inför ett mellanrum per prenumerant mätt i minuter mellan distinkta meddelanden, och inför det överallt, inklusive den transaktionella vägen som de flesta team glömmer att räkna med. En målvarning kl. 0:00 och ett erbjudande om att ta ut pengar kl. 2:30 varnar båda normalt. Samma par med trettio sekunders mellanrum är en varning och en spöknotifikation.
Tilldela utbrottet en enda ägare
För varje förutsägbar stund, bestäm i förväg vilken enskild avisering som hanterar den. När ett mål inträffar, är det då poängvarningen, oddsförändringen eller kontantuttagsmeddelandet som skickas? Välj en, vanligtvis den som ligger närmast intäkter eller den som spelaren uttryckligen prenumererat på, och undertryck eller fördröj resten. Prioriteringsnivåer slår tävlingssystem.
Kollapsa uppdateringar till en avisering
Oddsföljning är den klassiska boven: fem oddsförändringar bör inte vara fem aviseringar. Använd meddelandesubstitution, där den nya nyttolasten uppdaterar den befintliga aviseringen i fältet istället för att stapla en ny. FCM har stöttat kollapsbeteende i åratal. En live, kontinuerligt uppdaterad oddsavisering utlöser aldrig nedkylningen och uppfattas som en funktion snarare än som brus.
Sprid ut sändningarna i segment
En utskick till 500 000 prenumeranter som skickas ut i en enda våg ger också toppar på befolkningsnivå, vilket kolliderar med vad dina system än skickar ut under den tidsperioden. Dela upp utskicket i segmentvågor: live-spelare på den följda matchen först, nyligen insättande spelare därefter, lugnare segment minuter senare eller inte alls. Din spelarsegmenteringsmodell definierar redan vågorna; utskicket behöver bara respektera dem.
Begränsning av aviseringars frekvens och tysta timmar fullbordar jobbet
De fyra ovanstående mönstren fixar minuten. Begränsning av aviseringars frekvens fixar dagen och veckan. Nedkylningen är Googles påtvingande, på OS-nivå, av en disciplin som de bästa avsändarna redan har infört för sig själva, och det kommer inte att vara den sista påtvingande mekanismen. Ställ in interna tak per prenumerant per dag och per vecka, och skala dem efter segmentvärme:
| Segmentering | Max/dag | Max/vecka |
|---|---|---|
| Aktiv senaste 7 dagarna, följer live-evenemang | 3–4 på matchdagar | 10–12 |
| Aktiv senaste 7 dagarna, casino-rytm | 2 | 8–10 |
| Passiv, 8–20 dagar tyst | 1 | 3–4 |
| Vilande, 21+ dagar | — | 1, återengagera eller undertryck sedan |
Tysta timmar är den hårda golvgränsen under taket: definiera ett fönster för "stör ej" och låt inget marknadsföringsmässigt passera det. I denna vertikal är begränsning av aviseringars frekvens också spelarskydd, inte bara hygien för leverans. Tak, tysta timmar och en strikt regel om ingen brådska för insättningsuppmaningar är samma praxis sedd från två vinklar, och operatörer som håller den linjen ger spelarna en anledning att ha aviseringar påslagna. Retentionshandboken för bettingsajter täcker hela hygienstacken.
Bygga upp avståndsdisciplinen i PushEngage
Varje mönster ovan kan byggas i PushEngage Workflows idag, utan anpassad sändningsinfrastruktur. Betting- och spelsajter på PushEngage har skickat över 3,5 miljarder aviseringar, och kontrollerna för sändningsformning finns eftersom avsändare med den volymen behöver dem.
Väntanoder, tillgängliga på Business-planer och uppåt, är den grundläggande enheten för avstånd: infoga en väntan på minuter, timmar eller dagar mellan två sändningar i ett arbetsflöde, så att ingen sekvens du designar kan överbelasta en prenumerant. Beslutsnoder och avslutningskriterier, på samma planer, är hur ett arbetsflöde kontrollerar status innan det utlöses, vilket är vad "tilldela den överbelastade ägaren" ser ut i praktiken: om meddelandet med högre prioritet redan har skickats ut, avsluta istället för att lägga till.
Tystnadstimmar konfigureras per arbetsflöde med en fallback du väljer: hoppa över sändningen helt, eller schemalägg den till en minut efter att fönstret slutar, löst i varje prenumerants egen tidszon. Använd "schemalägg om" för erbjudanden med en begränsad hållbarhet och "hoppa över" för ögonblickbundna varningar; en startnotis som levereras kl. 09:01 är brus. Tidszonsmedveten schemaläggning ger dig också segment-staggered fan-out utan skript, eftersom vågor kan lämna på lokal tid snarare än som en enda global sändning.
Två funktioner ligger högre upp i planstegen: A/B-delade sökvägar inuti ett arbetsflöde börjar på Premium, och anpassade händelseutlösare och webhooks, de delar som låter din handelsmotor eller plånbokshändelser starta ett arbetsflöde direkt, börjar på Growth. Om du kartlägger hela app-sidans installation, börja med push-notiser för bettingappar, den centrala guiden för den här serien.
Chrome kör samma spel på webben
Om du också kör webb-push, poliserar samma engagemanglogik nu den kanalen. Sedan januari 2026 poängsätter Chrome varje sändande ursprung dagligen på pushar i förhållande till den tid användare faktiskt spenderar på webbplatsen, och stryper sändare som den klassificerar som störande. Olika mekanism, identiskt meddelande: plattformar mäter nu uppmärksamhet, och sändare som riktar sig till engagerade användare behåller sin räckvidd medan blasters förlorar den. Webbversionen av den här historien, och segmentarkitekturen som svarar på den, täcks i varför segmentering nu är ett krav för leveransbarhet.
Vad du ska ändra före din nästa matchdag
Tre åtgärder, i ordning. Först, granska förra månadens sändningar för push-notis-bursts på samma enhet: hämta alla prenumeranter som mottog två eller fler notiser inom en minut, identifiera vilka system som kolliderade, och notera hur ofta den begravda notisen var den med intäkter kopplade. För det andra, tilldela varje förutsägbar stund en enda ägande notis och nedgradera resten till kollapsade uppdateringar eller fördröjda uppföljningar. För det tredje, flytta varje återkommande sekvens till arbetsflöden med väntanoder, frekvensbegränsningar och tystnadstimmar, så att avståndet upprätthålls av plattformen snarare än av teamets minne.
Androids notifikationsavsvalning tog inte bort din räckvidd. Den tog bort illusionen att tre notifikationer på en minut var tre chanser att bli sedd. Avsändare som sprider ut, prioriterar och kollapsar kommer att larma med full volym medan deras konkurrenters utbrott kollapsar till en tyst grupp. Om du vill ha kontrollerna för sändningsformning utan att bygga dem, levereras app push-notifikationer på PushEngage med väntenoder, tysta timmar och tidszonsplanering på varje betald plan-nivå, med en 14-dagars pengarna-tillbaka-garanti.
