Din app sender tre notifikationer inden for et minut, og spillerens telefon viser dem som ét banner. Det er ikke en fejl i din push-udbyder. Det er Android-notifikationsafkølingen, der er aktiveret som standard i Android 16, og den omskriver stille og roligt reglerne for enhver afsender med højt volumen. Hvis du sender push-beskeder til en betting- eller spil-app, er dine mest værdifulde øjeblikke præcis dem, den målretter: et mål, et odds-skift og en udbetalingsprompt lander inden for de samme tres sekunder. Dette indlæg dækker, hvad afkølingen gør, FCM-ratebegrænsningerne, der allerede var der under den, og de designmønstre for afsendelse, der sikrer, at din app bliver hørt.
Hvad Android-notifikationsafkølingen gør ved en burst
Android 16 nåede stabil version den 10. juni 2025, og notifikationsafkølingen fulgte med, aktiveret som standard. Adfærden blev først dokumenteret i Android 16-udviklerforhåndsvisningerne i slutningen af 2024, hvor den stadig var en valgfri funktion. I den stabile udgivelse slog Google den til for alle.
Mekanismen er enkel. Når en app sender en burst af notifikationer, alarmerer den første normalt, med fuld lydstyrke og et fuldt banner. Hver efterfølgende notifikation i burst'en reduceres gradvist i lydstyrke og visuelt minimeres, i op til et minut, og burst'en grupperes under et enkelt banner. Intet bliver slettet. Notifikationerne ankommer stadig, ligger stadig i bakken, tæller stadig med i dine leveringsrapporter. De holder bare op med at kræve opmærksomhed.
Det sidste punkt er vigtigt for, hvordan du læser dine dashboards. Leveringsraten vil ikke ændre sig. Det, der ændrer sig, er alt, der kommer efter opmærksomhed: visninger, klik og de konverteringer, dine andet og tredje afsendelser skulle have drevet.
Android 16 notifikationer: hvad der stadig alarmerer, hvad der dæmpes
Afkølingen behandler ikke alle Android 16-notifikationer ens. Opkald, alarmer og prioriterede samtaler er undtaget; de alarmerer normalt, uanset hvor hurtigt de stables. Alt andet er underlagt dæmpningskurven, og det dækker alle betting-app-notifikationer, både marketing og transaktionelle.
En bemærkning om anvendelighed, og det er en slutning snarere end en dokumenteret platformerklæring: afkølingen opererer på notifikationslaget, så den bør efter mekanisme gælde både for FCM-leverede app-pushes og for web-push-notifikationer, som Chrome gengiver på Android. Hvis dit brand driver både en app og et mobilsite, skal du behandle Android 16-notifikationer fra begge kanaler som delende ét opmærksomhedsbudget på samme enhed.
FCM-ratebegrænsninger begrænsede dig allerede
Afkølingen er det synlige lag. Under det har Firebase Cloud Messaging håndhævet enheder-specifik drosling i årevis. FCM-dokumentationen sætter grænserne til 240 beskeder pr. minut og 5.000 pr. time til en enkelt enhed, og advarer om, at afsendere, der kører tæt på disse grænser, risikerer at få appen markeret som misbrugende.
Ingen fornuftig kampagne rammer 240 beskeder i minuttet til én bruger. Men disse FCM-rategrænser er pr. enhed, ikke pr. kampagne, hvilket betyder, at hvert system, du kører, sender mod det samme delte budget: din CRM, din handelsmotors oddsalarmer, din promo-planlægger, dit transaktionslag. En arkitektur, hvor fire systemer hver opfører sig rimeligt, kan stadig producere et enhedsniveau-mønster, der opfattes som misbrug af FCM og som en burst af nedkøling.
De to mekanismer forstærker hinanden. FCM-rategrænser begrænser, hvad der fysisk kan ankomme; Android-notifikationsnedkølingen bestemmer, hvor meget af det, der ankommer, der bliver bemærket. Afsendere med højt volumen designer nu mod begge på én gang.
Hvorfor betting-app-notifikationer pludselig opstår
Betting-apps opstår ikke, fordi CRM-teams er skødesløse. De opstår, fordi produktets bedste øjeblikke er iboende samtidige. Et mål i en fulgt kamp er i samme øjeblik en score-alarm, en oddsbevægelse og en cash-out-mulighed. Tre forskellige systemer ejer hver én af disse beskeder, og ingen af dem tjekker, hvad de to andre lige har sendt.
Her er burst'en, som spillerens telefon oplever den under nedkøling:
| Tid | System | Notifikation | Hvad spilleren oplever |
|---|---|---|---|
| 0:00 | CRM / event feed | “MÅL. 1-0 i kampen du følger” | Fuld alarm: lyd, vibration, banner |
| 0:15 | Handelsmotor | “Odds ændret på næste målmarked” | Dæmpet: reduceret lydstyrke, minimeret, grupperet |
| 0:40 | Promo-motor | “Cash out tilgængelig nu på dit åbne spil” | Dæmpet yderligere: næsten lydløs, kollapset i gruppen |
Den smertefulde del er rækkefølgen. Cash-out-prompten, den ene notifikation i den burst med direkte indtægt tilknyttet, er den, som nedkølingen begravede, fordi den ankom som nummer tre. Den, der sender først, ejer minuttet. Lige nu, i de fleste betting-app-notifikationsstakke, er vinderen det system, der har lavest latenstid, ikke den besked, der betyder mest.
Kampdags-push-sekvensen har altid krævet bevidst sekvensering. Nedkølingen gør det fra håndværk til krav.
Designmønstre, der overlever push-notifikations-bursts
Du kan ikke slå nedkølingen fra for dine brugere, og du bør heller ikke ønske det; den straffer præcis det mønster, dine spillere allerede foragtede. Løsningen er arkitektonisk. Fire mønstre forhindrer push-notifikations-bursts i at æde din rækkevidde.
Fordel afsendelser med minutter, ikke sekunder
Nedkølingsvinduet løber op til et minut. Enhver to notifikationer, du kontrollerer, der lander inden for det vindue, konkurrerer om én alarm. Så håndhæv et mellemrum pr. abonnent målt i minutter mellem forskellige beskeder, og håndhæv det overalt, inklusive den transaktionelle vej, som de fleste teams glemmer at tælle med. En mål-alarm kl. 0:00 og en cash-out-prompt kl. 2:30 alarmerer begge normalt. Det samme par tredive sekunder fra hinanden er én alarm og én spøgelse.
Tildel burst'en en enkelt ejer
For hvert forudsigeligt øjeblik, beslut på forhånd, hvilken notifikation der ejer det. Når et mål sker, udløser scoreadvarslen, oddsbevægelsen eller cash-out-prompten? Vælg én, normalt den, der er tættest på omsætning, eller den, spilleren eksplicit har tilmeldt sig, og undertryk eller forsink resten. Prioritetstrin slår racesystemer.
Kollaps opdateringer til én notifikation
Oddssporing er den klassiske synder: fem oddsbevægelser bør ikke være fem notifikationer. Brug beskedudskiftning, hvor den nye nyttelast opdaterer den eksisterende notifikation i bakken i stedet for at stable en ny. FCM har understøttet kollapsadfærd i årevis. Én live, kontinuerligt opdateret oddsnotifikation udløser aldrig nedkøling, og den læses som en funktion snarere end som støj.
Spred udsendelsen efter segment
En udsendelse til 500.000 abonnenter, der går ud i én bølge, producerer også spidsbelastninger på befolkningsniveau, der kolliderer med alt andet, dine systemer sender i det vindue. Opdel udsendelsen i segmentbølger: live-spillere på den fulgte kamp først, nylige indbetalere næste, køligere segmenter minutter senere eller slet ikke. Din spillersegmenteringsmodel definerer allerede bølgerne; udsendelsen behøver blot at respektere dem.
Notifikationsfrekvensbegrænsning og stille timer afslutter arbejdet
De fire ovenstående mønstre ordner minuttet. Notifikationsfrekvensbegrænsning ordner dagen og ugen. Nedkølingen er Googles håndhævelse, på OS-niveau, af en disciplin, som de bedste afsendere allerede har pålagt sig selv, og det vil ikke være den sidste håndhævelsesmekanisme. Indstil huslofter pr. abonnent pr. dag og pr. uge, og skaler dem efter segmentvarme:
| Segmentering | Max/dag | Max/uge |
|---|---|---|
| Aktiv sidste 7 dage, følger live-begivenheder | 3–4 på kampdage | 10–12 |
| Aktiv sidste 7 dage, casino-rytme | 2 | 8–10 |
| Opgivende, 8–20 dage stille | 1 | 3–4 |
| Sovende, 21+ dage | — | 1, genaktiver derefter eller undertryk |
Stille timer er den hårde bund under begrænsningerne: definer et forstyr ikke-vindue, og lad intet markedsføringsformet krydse det. I denne vertikal er notifikationsfrekvensbegrænsning også spillersbeskyttelse, ikke kun leveringshygiejne. Begrænsninger, stille timer og en streng ingen-hastværksregel på indbetalingsprompter er den samme praksis set fra to vinkler, og operatører, der holder den linje, giver spillere en grund til at lade notifikationer være tændt. fastholdelses-playbooken for betting-sider dækker hele hygiejnestakken.
Opbygning af afstandsdisciplinen i PushEngage
Hvert mønster ovenfor kan bygges i PushEngage Workflows i dag, uden brugerdefineret afsendelsesinfrastruktur. Betting- og spilsider på PushEngage har sendt over 3,5 milliarder notifikationer, og kontrolfunktionerne til afsendelsesformning eksisterer, fordi afsendere med det volumen har brug for dem.
Vent-knudepunkter, tilgængelige på Business-abonnementer og derover, er den grundlæggende enhed til afstand: indsæt en pause på minutter, timer eller dage mellem to afsendelser i en arbejdsgang, så ingen sekvens, du designer, kan overbelaste en abonnent. Beslutningsknudepunkter og afslutningskriterier, på de samme abonnementer, er hvordan en arbejdsgang tjekker status, før den udløses, hvilket er, hvad "tildel den overbelastede ejer" ser ud i praksis: hvis beskeden med højere prioritet allerede blev sendt, afslut i stedet for at stable ovenpå.
Stilletider konfigureres pr. arbejdsgang med en fallback, du vælger: spring afsendelsen helt over, eller omlæg den til et minut efter vinduet slutter, løst i hver abonnents egen tidszone. Brug omlægning til tilbud med en holdbarhedsdato og spring over til øjebliksbestemte alarmer; en startmeddelelse leveret kl. 09:01 er støj. Tidszonebevidst planlægning giver dig også segment-forskudt fan-out uden scripts, da bølger kan afgå lokalt i stedet for som én global udsendelse.
To funktioner sidder højere på abonnementsstigen: A/B-splitstier inde i en arbejdsgang starter på Premium, og brugerdefinerede hændelsestriggere og webhooks, de dele, der lader din handelsmotor eller wallet-hændelser starte en arbejdsgang direkte, starter på Growth. Hvis du kortlægger hele app-sideopsætningen, start med push-meddelelser til betting-apps, vejledningen for denne serie.
Chrome kører det samme spil på nettet
Hvis du også kører web push, politiserer den samme engagementlogik nu den kanal. Siden januar 2026 scorer Chrome hver afsendende oprindelse dagligt på pushes i forhold til den tid, brugerne rent faktisk bruger på siden, og drosler afsendere, den klassificerer som forstyrrende. Forskellig mekanisme, identisk besked: platforme måler nu opmærksomhed, og afsendere, der målretter engagerede brugere, bevarer deres rækkevidde, mens blasters mister den. Web-versionen af denne historie, og segmentarkitekturen, der besvarer den, er dækket i hvorfor segmentering nu er et leveringskrav.
Hvad skal ændres før din næste kampdag
Tre trin, i rækkefølge. Først, revider sidste måneds afsendelser for push-meddelelses-bursts på samme enhed: hent enhver abonnent, der modtog to eller flere meddelelser inden for et minut, identificer hvilke systemer der kolliderede, og bemærk hvor ofte den begravede meddelelse var den med indtægt tilknyttet. For det andet, tildel hvert forudsigeligt øjeblik en enkelt ejer-meddelelse og nedgradér resten til kollapsede opdateringer eller forsinkede opfølgninger. For det tredje, flyt enhver tilbagevendende sekvens ind i arbejdsgange med vent-knudepunkter, frekvensgrænser og stilletider, så afstand håndhæves af platformen snarere end af teamhukommelse.
Android-notifikationsafkølingen fjernede ikke din rækkevidde. Den fjernede illusionen om, at tre notifikationer på et minut var tre chancer for at blive set. Afsendere, der holder pause, prioriterer og kollapser, vil advare med fuld lyd, mens deres konkurrenters udbrud kollapser til en lydløs gruppe. Hvis du vil have sendingsformningskontrollerne uden at skulle bygge dem, leveres app-push-notifikationer på PushEngage med ventenoder, stille timer og tidszoneplanlægning på ethvert betalt plan-niveau, understøttet af en 30-dages pengene-tilbage-garanti.
