Uygulamanız bir dakika içinde üç bildirim gönderiyor ve oyuncunun telefonu onlara tek bir başlık gösteriyor. Bu, anlık bildirim sağlayıcınızdaki bir hata değil. Bu, Android 16'da varsayılan olarak etkinleştirilen Android bildirim soğutma süresidir ve her yüksek hacimli gönderici için kuralları sessizce yeniden yazar. Bir bahis veya oyun uygulaması için anlık bildirim gönderiyorsanız, en değerli anlarınız tam olarak hedefledikleridir: bir gol, bir oran değişikliği ve bir nakit çekme istemi aynı altmış saniye içinde gelir. Bu yazı, soğutma süresinin ne yaptığını, altında zaten var olan FCM hız limitlerini ve uygulamanızın duyulmasını sağlayan gönderme tasarım düzenlerini kapsar.
Android bildirim soğutma süresi bir patlamaya ne yapar
Android 16, 10 Haziran 2025'te kararlı sürüme ulaştı ve bildirim soğutma süresi varsayılan olarak etkinleştirilmiş olarak onunla birlikte geldi. Davranış, 2024'ün sonlarında Android 16 geliştirici önizlemelerinde ilk kez belgelenmişti ve o zamanlar hala isteğe bağlı bir geçişti. Kararlı sürümde Google, bunu herkes için açtı.
Mekanizma basittir. Bir uygulama bir bildirim patlaması gönderdiğinde, ilki normal şekilde, tam sesle, tam bir başlıkla uyarır. Patlamadaki sonraki her bildirim, bir dakikaya kadar giderek azalan sesle ve görsel olarak en aza indirilir ve patlama tek bir başlık altında gruplanır. Hiçbir şey silinmez. Bildirimler hala gelir, hala tepside durur, hala teslimat raporlarınızda sayılır. Sadece dikkat çekmeyi bırakırlar.
Son nokta, panolarınızı nasıl okuduğunuz açısından önemlidir. Teslimat oranı değişmeyecektir. Değişen şey, dikkat çekmenin aşağı akışındaki her şeydir: görünümler, tıklamalar ve ikinci ve üçüncü gönderilerinizin sağlaması beklenen dönüşümler.
Android 16 bildirimleri: ne hala uyarıyor, ne sessize alınıyor
Soğutma süresi, tüm Android 16 bildirimlerini aynı şekilde ele almaz. Aramalar, alarmlar ve öncelikli konuşmalar muaftır; ne kadar hızlı yığılırlarsa yığılsınlar normal şekilde uyarırlar. Geri kalan her şey sessize alma eğrisine tabidir ve bu, tüm bahis uygulaması bildirimlerini, hem pazarlama hem de işlemsel olanları kapsar.
Bir uygulama notu ve bu belgelenmiş bir platform ifadesinden ziyade bir çıkarımdır: soğutma süresi bildirim katmanında çalışır, bu nedenle mekanizma gereği hem FCM tarafından gönderilen uygulama bildirimlerine hem de Chrome'un Android'de oluşturduğu web anlık bildirimlerine uygulanmalıdır. Markanız hem bir uygulama hem de mobil site çalıştırıyorsa, her iki kanaldan gelen Android 16 bildirimlerini aynı cihazda tek bir dikkat bütçesini paylaşan olarak ele alın.
FCM hız limitleri sizi zaten sınıyordu
Bekleme süresi görünür katmandır. Bunun altında, Firebase Cloud Messaging yıllardır cihaz başına kısıtlamalar uyguluyor. FCM belgeleri, tek bir cihaza dakikada 240 mesaj ve saatte 5.000 mesaj sınırını belirliyor ve bu sınırlara yakın gönderenlerin uygulamayı kötü niyetli olarak işaretlenme riskiyle karşı karşıya kalacağı konusunda uyarıyor.
Hiçbir akıllı kampanya bir kullanıcıya dakikada 240 mesaj göndermez. Ancak bu FCM hız sınırları cihaza özeldir, kampanyaya özel değil, bu da çalıştırdığınız her sistemin aynı paylaşılan bütçeye karşı gönderim yaptığı anlamına gelir: CRM'niz, ticaret motorunuzun oran uyarıları, promosyon zamanlayıcınız, işlemsel katmanınız. Makul davranan dört sistemin olduğu bir mimari, FCM'nin kötü niyetli olarak algıladığı ve bekleme süresinin bir patlama olarak algıladığı bir cihaz düzeyinde desen üretebilir.
İki mekanizma birleşir. FCM hız sınırları fiziksel olarak neyin ulaşabileceğini sınırlar; Android bildirim bekleme süresi, ulaşanların ne kadarının fark edildiğini belirler. Yüksek hacimli göndericiler artık her ikisine birden karşı tasarlıyor.
Bahis uygulaması bildirimleri neden en başta patlıyor?
Bahis uygulamaları CRM ekiplerinin dikkatsizliği nedeniyle patlamaz. Ürünün en iyi anları doğası gereği eşzamanlı olduğu için patlarlar. Takip edilen bir maçtaki gol, aynı anda bir skor uyarısı, bir oran hareketi ve bir nakit çekme fırsatıdır. Üç farklı sistem bu mesajlardan birinden sorumludur ve hiçbiri diğer ikisinin az önce ne gönderdiğini kontrol etmez.
İşte bekleme süresi altındaki oyuncunun telefonunun deneyimlediği patlama:
| Zaman | Sistem | Bildirim | Oyuncu ne deneyimliyor |
|---|---|---|---|
| 0:00 | CRM / etkinlik akışı | “GOL. Takip ettiğiniz maçta 1-0” | Tam uyarı: ses, titreşim, banner |
| 0:15 | Ticaret motoru | “Bir sonraki gol piyasasında oranlar değişti” | Sessize alındı: azaltılmış ses, en aza indirilmiş, gruplandırılmış |
| 0:40 | Promosyon motoru | “Açık bahsinizde şimdi nakit çekme mevcut” | Daha da sessize alındı: neredeyse sessiz, gruba daraltılmış |
Acı veren kısım sıralamadır. Nakit çekme istemi, o patlamadaki doğrudan gelir getiren tek bildirim, bekleme süresinin gömdüğü, çünkü üçüncü sırada geldi. İlk gönderen dakikaya sahip olur. Şu anda, çoğu bahis uygulaması bildirim yığınında, kazanan en düşük gecikmeye sahip sistemdir, en önemli mesaj değil.
Maç günü anlık bildirim dizisi her zaman kasıtlı bir sıralama gerektirmiştir. Bekleme süresi bunu zanaattan gerekliliğe dönüştürür.
Anlık bildirim patlamalarına dayanan tasarım desenleri
Bekleme süresini kullanıcılarınız için kapatamazsınız ve istememelisiniz; tam da oyuncularınızın zaten kızdığı deseni cezalandırır. Çözüm mimaridir. Dört desen, anlık bildirim patlamalarının erişiminizi yemesini engeller.
Gönderimleri saniye değil, dakikalarla aralayın
Bekleme süresi penceresi bir dakikaya kadar çalışır. O pencereye düşen kontrol ettiğiniz herhangi iki bildirim, bir uyarı için rekabet eder. Bu nedenle, farklı mesajlar arasında dakikalarla ölçülen bir abone başına aralık zorlayın ve bunu, çoğu ekibin saymayı unuttuğu işlemsel yol da dahil olmak üzere her yerde zorlayın. 0:00'daki bir gol uyarısı ve 2:30'daki bir nakit çekme istemi normal şekilde uyarır. Otuz saniye arayla aynı çift bir uyarı ve bir hayalet olur.
Patlamaya tek bir sahip ata
Her öngörülebilir an için, hangi bildirimin onu sahipleneceğini önceden belirleyin. Bir gol olduğunda, skor uyarısı mı, oran hareketi mi, yoksa para çekme istemi mi tetiklenir? Birini seçin, genellikle gelire en yakın olanı veya oyuncunun açıkça abone olduğu, geri kalanları ise bastırın veya geciktirin. Öncelik katmanları yarış sistemlerini yener.
Güncellemeleri tek bir bildirime daralt
Oran takibi klasik suçludur: beş oran hareketi beş bildirim olmamalıdır. Yeni yükün, yeni bir tane istiflemek yerine tepsideki mevcut bildirimi güncellediği mesaj değişimi kullanın. FCM yıllardır çökme davranışını desteklemektedir. Sürekli güncellenen tek bir canlı oran bildirimi asla soğuma süresini tetiklemez ve gürültüden ziyade bir özellik olarak okunur.
Dağıtımı segmente göre kademelendirin
Tek bir dalgada çıkan 500.000 abonelik bir patlama, nüfus düzeyinde de patlamalara neden olur ve sistemlerinizin o pencerede gönderdiği diğer her şeyle çakışır. Dağıtımı segment dalgalarına bölün: önce takip edilen maçtaki canlı bahisçiler, sonra yakın zamanda para yatıranlar, dakikalar sonra veya hiç soğuk segmentler. Sizin oyuncu segmentasyon modeliniz zaten dalgaları tanımlıyor; dağıtımın yalnızca onlara saygı duyması gerekiyor.
Bildirim sıklığı sınırlaması ve sessiz saatler işi bitirir
Yukarıdaki dört desen dakikayı düzeltir. Bildirim sıklığı sınırlaması günü ve haftayı düzeltir. Soğuma, Google'ın işletim sistemi düzeyinde, en iyi göndericilerin kendilerine zaten dayattığı bir disiplini zorlamasıdır ve son uygulama mekanizması olmayacaktır. Abone başına günlük ve haftalık ev tavanları belirleyin ve bunları segment ısısına göre ölçeklendirin:
| Segmentasyon | Günlük Maks | Haftalık Maks |
|---|---|---|
| Son 7 gün aktif, canlı etkinlikleri takip ediyor | Maç günlerinde 3–4 | 10–12 |
| Son 7 gün aktif, casino ritmi | 2 | 8–10 |
| Devre dışı, 8–20 gün sessiz | 1 | 3–4 |
| Uykuda, 21+ gün | — | 1, sonra yeniden etkileşim kur veya bastır |
Sessiz saatler, sınırlamaların altındaki sert zemindir: rahatsız etmeyin penceresi tanımlayın ve pazarlama şeklindeki hiçbir şeyin onu geçmesine izin vermeyin. Bu dikeyde, bildirim sıklığı sınırlaması yalnızca teslim edilebilirlik hijyeni değil, aynı zamanda oyuncu korumasıdır. Sınırlamalar, sessiz saatler ve para yatırma istemlerinde katı bir aciliyet kuralı olmaması, iki açıdan bakıldığında aynı uygulamadır ve bu çizgiyi koruyan operatörler oyunculara bildirimleri açık bırakmaları için bir neden verir. Bahis siteleri için elde tutma oyun kitabı tüm hijyen yığınını kapsar.
PushEngage'de aralıklandırma disiplinini oluşturma
Yukarıdaki her desen, özel gönderi altyapısı olmadan bugün PushEngage İş Akışlarında oluşturulabilir. PushEngage'deki bahis ve oyun siteleri 3,5 milyardan fazla bildirim gönderdi ve gönderi şekillendirme kontrolleri, o hacimdeki göndericilerin onlara ihtiyaç duyduğu için mevcuttur.
Bekleme düğümleri, Business plan ve üzeri planlarda mevcuttur ve aralık ilkelidir: bir iş akışındaki herhangi iki gönderim arasına dakikalar, saatler veya günler süren bir bekleme ekleyin, böylece tasarladığınız hiçbir dizi bir aboneyi aşırı yükleyemez. Aynı planlardaki karar düğümleri ve çıkış kriterleri, bir iş akışının ateşlemeden önce durumu nasıl kontrol ettiğidir, bu da pratikte "aşırı yüklenen tek sahip atanıyor" ifadesinin ne anlama geldiğidir: daha yüksek öncelikli mesaj zaten gönderildiyse, yığılma yerine çıkış yapın.
Sessiz saatler, seçtiğiniz bir geri bildirimle iş akışı başına yapılandırılır: gönderimi tamamen atlayın veya pencere bittikten bir dakika sonrasına yeniden planlayın, her abonenin kendi saat diliminde çözülür. Teklifler için yeniden planlamayı, raf ömrü olanlar için ve anlık bildirimler için atlamayı kullanın; 09:01'de teslim edilen bir başlatma bildirimi gürültüdür. Saat dilimi duyarlı zamanlama, komut dosyaları olmadan segmentlere göre kademeli yayılma sağlar, çünkü dalgalar tek bir küresel patlama olarak değil, yerel saatte başlayabilir.
Plan basamaklarında iki yetenek daha üstte yer alır: bir iş akışı içindeki A/B bölme yolları Premium'da başlar ve özel olay tetikleyicileri ve webhook'lar, ticaret motorunuzun veya cüzdan olaylarınızın bir iş akışını doğrudan başlatmasına izin veren parçalar, Growth'ta başlar. Tam uygulama tarafı kurulumunu haritalıyorsanız, bu serinin temel kılavuzu olan bahis uygulamaları için anlık bildirimlerle başlayın.
Chrome web'de aynı oyunu oynuyor
Ayrıca web anlık bildirimleri de çalıştırıyorsanız, aynı etkileşim mantığı artık bu kanalı denetliyor. Ocak 2026'dan beri Chrome, her gönderme kaynağını günlük olarak, kullanıcıların sitede geçirdiği zamana göre anlık bildirimler için puanlıyor ve rahatsız edici olarak sınıflandırdığı göndericileri kısıtlıyor. Farklı mekanizma, aynı mesaj: platformlar artık dikkati ölçüyor ve etkileşimli kullanıcıları hedefleyen göndericiler erişimlerini korurken, patlayıcılar kaybediyor. Bu hikayenin web tarafı versiyonu ve buna yanıt veren segment mimarisi, segmentasyonun neden artık teslim edilebilirlik gereksinimi olduğu bölümünde ele alınmaktadır.
Bir sonraki maç gününüzden önce neyi değiştirmelisiniz
Üç hamle, sırayla. Birincisi, geçen ayın gönderimlerini aynı cihazda anlık bildirim patlamaları için denetleyin: bir dakika içinde iki veya daha fazla bildirim alan herhangi bir aboneyi çekin, hangi sistemlerin çakıştığını belirleyin ve gelir eklenen bildirimin ne sıklıkla gömüldüğünü not edin. İkincisi, her öngörülebilir ana ana tek bir sahip bildirim atayın ve diğerlerini daraltılmış güncellemeler veya gecikmiş takip bildirimlerine indirin. Üçüncüsü, her tekrarlayan diziyi bekleme düğümleri, frekans sınırları ve sessiz saatler içeren iş akışlarına taşıyın, böylece aralıklar ekip belleği yerine platform tarafından zorlanır.
Android bildirim soğutması, erişiminizi ortadan kaldırmadı. Bir dakika içinde üç bildirimin görülmek için üç şans olduğu yanılsamasını ortadan kaldırdı. Mesafeyi ayarlayan, önceliklendiren ve daraltan göndericiler, rakiplerinin patlamaları sessiz bir gruba çökerken tam sesle uyaracaktır. Oluşturmadan gönderme şekillendirme kontrollerini istiyorsanız, PushEngage'deki uygulama anlık bildirimleri, her ücretli plan katmanında bekleme düğümleri, sessiz saatler ve saat dilimi zamanlaması ile birlikte gelir ve 14 günlük para iade garantisi ile desteklenir.
