Site İçi Bildirim Sistemi Kurmak
Kullanıcıya bir şey söylemek istiyorsunuz: siparişi hazırlandı, mesajı yanıtlandı, aboneliği bitmek üzere. E-posta gönderiyorsunuz ama açılma oranı düşük ve bazıları istenmeyen klasörüne düşüyor. Kullanıcı zaten sitenizde — ona orada söylemek çoğu zaman daha etkilidir.
Bu yazı, panel içi bildirim yapısını ele alıyor.
E-postaya Ek Olarak
| Kanal | Güçlü yanı |
|---|---|
| E-posta | Site dışında da ulaşır |
| Site içi bildirim | Kaybolmaz, birikir |
| Anlık bildirim | Hemen görülür |
İkinci satırın gücü sürekliliğindedir: site içi bildirimler kullanıcı giriş yaptığında hâlâ oradadır — e-posta kutusunda kaybolan bir bildirimin aksine, kullanıcı ne zaman gelirse gelsin okunmamış listesini görür.
Bu, önemli duyurular için değerlidir.
Birinci satır ise kullanıcı sitede değilken tek yoldur.
İkisi birbirinin alternatifi değil tamamlayıcısıdır.
Veri Yapısı
- Alıcı kullanıcı.
- Bildirim türü.
- İlgili kayıt bağlantısı.
- Okundu bilgisi.
İkinci madde esneklik sağlar: bildirim metnini veritabanına yazmak yerine tür ve ilgili kayıt kimliğini saklamak, metni sonradan değiştirmenizi ve çok dilli göstermenizi mümkün kılar — metin gösterim anında üretilir.
Yazılmış metin sonradan düzeltilemez.
Tür yaklaşımı bu kısıtı kaldırır.
Ayrıca aynı bildirimi farklı biçimlerde göstermeye izin verir.
Okunmamış Sayacı
- Her sayfada gösterilir.
- Her istekte sayılırsa maliyet artar.
- Sayaç ayrı tutulabilir.
İkinci madde beklenmedik bir yük üretir: okunmamış bildirim sayısını her sayfa yüklemesinde saymak, her ziyaretçi için ek bir sorgu demektir ve yoğun sitelerde bu sorgu toplam yükün önemli bir kısmını oluşturur.
Üçüncü madde bunu çözer.
Sayaç kullanıcı kaydında tutulur ve değiştikçe güncellenir.
Bu, bir sorguyu tamamen ortadan kaldırır.
Bildirim Yığılması
| Durum | Doğru davranış |
|---|---|
| Aynı konuda çok bildirim | Grupla |
| Art arda gelen olaylar | Birleştir |
| Her küçük değişiklik | Bildirim üretme |
Üçüncü satır en önemli disiplindir: her küçük olay için bildirim üretmek, kullanıcının bildirim listesini gürültüye boğar ve bir süre sonra hiçbirini okumamasına yol açar — bildirim değeri, seyrekliğiyle doğru orantılıdır.
Kullanıcı gerçekten bilmesi gerekeni almalıdır.
Birinci satır ise okunabilirliği artırır.
Beş ayrı bildirim yerine tek bir özet gösterilir.
Kullanıcı Tercihleri
- Tür bazında açma kapama.
- Kanal seçimi.
- Varsayılanlar makul olmalı.
Üçüncü madde çoğu kullanıcı için belirleyicidir: kullanıcıların büyük çoğunluğu bildirim ayarlarına hiç girmez — bu yüzden varsayılan ayarlar, hiç dokunulmasa bile makul bir deneyim üretecek biçimde seçilmelidir.
Aşırı bildirim varsayılanı, kullanıcı kaybettirir.
İkinci madde ise kanal ayrımına izin verir.
Kimi bildirim yalnızca site içinde, kimi ayrıca e-postayla gönderilebilir.
Eski Bildirimler
- Tablo hızla büyür.
- Saklama süresi belirlenmeli.
- Düzenli temizlenmeli.
Birinci madde ölçek sorununu işaret eder: on bin kullanıcıya gönderilen tek bir duyuru, bildirim tablosuna on bin satır ekler — birkaç duyuru sonrası tablo milyonlara ulaşır.
Bu nedenle saklama süresi baştan belirlenmelidir.
Okunmuş ve eski bildirimler silinebilir.
Üçüncü madde zamanlanmış bir görevle yapılır.
Toplu Duyurular
| Yöntem | Uygunluk |
|---|---|
| Her kullanıcıya satır | Küçük kitlede uygun |
| Tek duyuru, okundu kaydı | Büyük kitlede verimli |
İkinci satır ölçeklenebilir çözümdür: tüm kullanıcılara gönderilen duyuruyu tek bir kayıt olarak tutup yalnızca okuyanların kaydını eklemek, milyonlarca satır üretmek yerine yalnızca okuyan sayısı kadar satır üretir.
Çoğu kullanıcı duyuruyu hiç okumaz.
Bu yaklaşım tablo boyutunu belirgin küçültür.
Kişiye özel bildirimlerde ise birinci yöntem kullanılır.
Anında Gösterim
- Sayfa yenilendiğinde görünür.
- Aralıklı sorgulama eklenebilir.
- Aralık makul tutulmalı.
Üçüncü madde paylaşımlı barındırmada kritiktir: her beş saniyede bir bildirim kontrolü yapan bir sayfa, tek kullanıcıda saatte yedi yüzden fazla istek üretir — birkaç yüz eşzamanlı kullanıcıda bu, hesabınızın kaynak sınırını tek başına doldurur.
Bu tür kontroller dakikalık aralıklarla yapılmalıdır.
Kullanıcı sayfayı zaten yenileyecektir.
Birinci madde çoğu site için yeterlidir.
Bildirim tabloları ve düzenli temizlik görevleri için yeterli kaynak gerekir; Windows hosting altyapısı veya Linux tarafında ihtiyacınıza uygun paketi seçebilirsiniz.
Sonuç
Site içi bildirimler e-postanın alternatifi değil tamamlayıcısıdır: kullanıcı ne zaman gelirse gelsin okunmamış listesini görür. Metni değil türü saklayın, okunmamış sayacını ayrı tutun ve disiplinli olun — her küçük olay için bildirim üretmek, kullanıcının bir süre sonra hiçbirini okumamasına yol açar. Toplu duyuruları tek kayıtla yönetin ve eski bildirimleri düzenli temizleyin.
Sıkça Sorulan Sorular (SSS)
E-posta varken site içi bildirime gerek var mı?
İkisi farklı işler yapar. Site içi bildirimler kullanıcı giriş yaptığında hâlâ oradadır; e-posta kutusunda kaybolan bir bildirimin aksine, kullanıcı ne zaman gelirse gelsin okunmamış listesini görür. E-posta ise kullanıcı sitede değilken tek yoldur.
Bildirim metnini veritabanına yazmalı mıyım?
Yazmayın. Tür ve ilgili kayıt kimliğini saklayıp metni gösterim anında üretmek, metni sonradan değiştirmenizi ve çok dilli göstermenizi mümkün kılar. Yazılmış metin sonradan düzeltilemez.
Okunmamış sayısını nasıl göstermeliyim?
Sayacı kullanıcı kaydında ayrı tutun. Her sayfa yüklemesinde saymak, her ziyaretçi için ek bir sorgu demektir ve yoğun sitelerde toplam yükün önemli bir kısmını oluşturur.
Tüm kullanıcılara duyuru göndermek tabloyu şişirir mi?
Her kullanıcıya satır eklerseniz evet; on bin kullanıcı on bin satır demektir. Duyuruyu tek kayıt olarak tutup yalnızca okuyanların kaydını eklemek çok daha verimlidir çünkü çoğu kullanıcı duyuruyu hiç okumaz.
