Olay başına anahtarlar, sessiz saatler, özetler ve teslimat takibi ile kullanıcıları spamlanmış hissetmeden haberdar eden bildirim tercihleri tasarlayın.
Çoğu insan bildirimlerden nefret etmez. Nedeni olmayan kesintilerden nefret ederler. Uyarılar çok sık geldiğinde, kendini tekrarladığında veya yanlış zamanda ortaya çıktığında kullanıcılar okumayı bırakır ve kaydırmaya başlar.
Temel sorun genellikle hacim değildir. Sorun uyumsuzluktur. Sisteminiz için acil olan bir şey kişiye göre alakasız olabilir. Bir satış temsilcisi bir lead atamasını hemen bilmek isteyebilir, ama 21:07'de gelen “haftalık ipuçları” bildirimi istemez. Her şey eşit derecede önemli görünürse, hiçbir şey önemli hissettirmez.
İnsanlar bildirimleri tahmin edilebilir nedenlerle kapatır: çok sık olmaları, rollerine uygun olmamaları, kötü zamanlanmış olmaları (uyku, toplantılar, yolculuk), sonraki adımın net olmaması veya hangi kaynaktan geldiğinin belirsiz olması.
Yardımcı uyarılar çabayı azaltır. Gürültü çabayı artırır. İyi bir bildirim hızlıca üç soruyu yanıtlar: Ne oldu? Bu benim için önemli mi? Sonraki ne yapmalıyım?
Kullanıcıların her şeyi kapatıp kaçınmasının gizli maliyeti de vardır: gerçekten önemli olan tek bir mesaj kaçırılır. Kilitlenmiş bir hesap, ödeme hatası veya güvenlik uyarısı, kullanıcı haftalarca düşük değerli pinglemelerden sonra vazgeçtiği için gözden kaçabilir. Böylece “sinir bozucu” olan şey “destek bileti” olur.
İyi bildirim tercihleri tek bir işi yapar: insanlara net seçeneklerle kontrol verir ve davranışı öngörülebilir kılar. Bir kullanıcı bir tür uyarıyı kapatırsa, kapalı kalmalı. Sessiz saatler ayarlarsa, uygulama bunlara her seferinde, tüm kanallarda saygı göstermeli.
İyi bildirim tercihleri bir soru ile başlar: kullanıcı neyle ilgili haberdar olmak istiyor ve ne bekleyebilir.
Biri “yeni siparişler” için uyarıları açarsa genelde “çabucak haber verin ki ben aksiyon alayım” demek ister. “Haftalık ürün ipuçları” istiyorsa “vaktim olduğunda okuyacağım” demektir. Ayarları dahili olay listeniz etrafında değil, o niyet etrafında kurun.
Olay sayısını az ve birbirinden farklı tutun. Eğer “durum değişti”nin beş çeşidi varsa, çoğu insan ya her şeyi kapatır ya da her şeyi açık bırakır ve pişman olur. Benzer olayları tek bir net seçenekte birleştirin ve yalnızca sonraki eylem gerçekten farklıysa ayırın.
Varsayılanlar çoğu ekipten daha önemli etki yapar. Kritik olmayan her şey için sessiz başlayın, sonra insanların katılmasına izin verin. Yeni bir kullanıcı hiçbir şey yapmadan bile saygı görmüş hissetmelidir.
Basit dil kullanın. Kullanıcılar gerçekten kullanmadıkça “workflow”, “ticket lifecycle” veya “webhook failure” gibi terimlerden kaçının. Etiketleri, bir kişinin bunları bir iş arkadaşına nasıl açıklayacağı şeklinde yazın.
Biri bir anahtara dokunduğunda üç şeyi anlamalıdır:
Uzun bir bildirim tercihleri listesi oluşturmadan önce hangi olayların gerçekten bir ayarı hak ettiğine karar verin. Çoğu ayar ekranı sinir bozucu hissettirir çünkü yüksek sesli, düşük değerli olaylar için seçenek sunar, oysa gerçekten önemli olanlar gömülüdür.
İnsanların ne alacaklarını tahmin edebilmeleri için olayları amaçlarına göre gruplayarak başlayın:
Her grup içinde olayları kritik, bilgilendirici ve tanıtım (promosyon) olarak ayırın. Kritik, eylem gerektiğini veya riskin yüksek olduğunu; bilgilendirici “bilse iyi olur”u; tanıtım ise “iyi olur”u ifade eder. Her olay için aciliyeti ve kabul edilebilir gecikmeyi tanımlayın. Bir ödeme hatası anında teslim gerektirebilir. Haftalık rapor bir özet için bekleyebilir.
“Kapatılmasına izin verilmeyen” olaylarla dikkatli olun. Bir şeyin açık kalması gerekiyorsa, listeyi çok kısa tutun ve nedenini açıklayın (genellikle güvenlik ve belirli faturalama uyarıları). Diğer her şey kullanıcı tarafından kontrol edilebilir olmalıdır.
Pratik bir kural: her olay için ne olduğuna ve neden önemli olduğuna dair tek cümle yazın. Örnek: “Hesabınıza yeni bir cihaz giriş yaptı, böylece şüpheli erişimi fark edebilirsiniz.” O cümleyi belirsiz olmadan yazamıyorsanız, olay muhtemelen kendi anahtarını hak etmiyordur.
Olay başına anahtarlar, kullanıcıların gerçekten önem verdiği anlara denk geldiğinde işe yarar. Olay onlara para, zaman veya güven kaybettirebilecek bir şeyse, kendi anahtarını hak eder. Daha çok “bilgi amaçlı” ise, ayrı bir anahtar eklemek yerine özet içine koymayı düşünün.
Anahtarları gerçek olaylar gibi adlandırın, özellik alanları gibi değil. “Ödeme başarısız” “Faturalama güncellemeleri”nden daha nettir. Bu, saygılı hissettiren tercihlerle ayarlar labirenti hissi verenler arasındaki farktır.
Her anahtarın altında mesajın nasıl görüneceğine dair tek satırlık bir örnek gösterin. Bu beklenti oluşturur ve kararı kolaylaştırır.
Kategori anahtarları yalnızca kategoriler açık ve sabitse faydalıdır. “Güvenlik”, “Faturalama” ve “Hesap erişimi” genelde açıktır. “Ürün güncellemeleri” veya “Aktivite” ise çok şey gizleyebilir.
Gizli bağımlılıklardan kaçının. “Yorumları” kapatmak aynı anda “Bahsetmeleri” de devre dışı bırakıyorsa bunu hemen söyleyin. Daha iyisi, bunları ayrı tutmaktır. Sürprizler insanların tüm ekranı güvensiz bulmasına neden olur.
Seçimleri silmeyen global bir duraklatma ekleyin. “Tüm bildirimleri 1 saat / 1 gün / kendim açana kadar duraklat” gibi seçenek yoğun günler için güvenlik valfidir ve olay başına ayarları korur.
Sessiz saatler bir şeyi ifade etmeli: kullanıcı rahatsız edilmek istemediği zamanlarda kritik olmayan mesajlar.
Zaman dilimleri sessiz saatlerin “doğru” veya “bozuk” hissetmesine neden olur. Bazı insanlar seyahat ederken sessiz saatlerin mevcut konumlarını takip etmesini ister. Diğerleri seyahatte bile sabit bir “ev” programı ister. Her ikisini de “Mevcut zaman dilimimi kullan” ve “Ev zaman dilimimi kullan” gibi düz etiketlerle sunun.
Sessiz saatlerin net istisnaları da olmalı. Kullanıcılar atlamalara nadir ve anlaşılır olduklarında izin verir. İstisna listesini kısa tutun ve pazarlamaya dayalı değil, risk temelli yapın:
Kenar durumlar önemlidir. Yaz saati uygulaması programları saatlik kaydırabilir, bu yüzden UI'da bir sonraki “sessiz başlıyor” ve “sessiz bitiyor” zamanlarını gösterin.
Hafta sonları için kullanıcıların iki ayrı program oluşturmasını gerektirmeyin. Basit bir “Yalnızca hafta içi” anahtarı veya tek dokunuşla gün seçimi sunun.
Önayarlar insanların hızlıca bitirmesine yardımcı olur: “Gece (22:00–08:00)” ve “Özel”. Seçildikten sonra önayarların düzenlenebilir olmasına izin verin ki tuzak gibi hissetmesin.
Özet bir söz verir: “Sizi haberdar edeceğiz, sadece rahatsız etmeyeceğiz.” Gürültülü, düşük öncelikli güncellemeler (reaksiyonlar, rutin aktivite, günlük istatistikler) için en iyi sonucu verir. İş engelleyen, hızlı cevap gerektiren veya son tarihli şeyler için kötü çalışır.
Özet seçeneği, olayları iki kovaya ayırarak başlamalıdır. Yüksek aciliyeti olan olayları gerçek zamanlı tutun (güvenlik uyarıları, ödemeler, onaylar, kesintiler). Yüksek hacimli olayları özete taşıyın (aktif yorum dizileri, takipçi etkinliği, rutin özetler).
Sıklık seçeneklerini tanıdık tutun:
Kullanıcıların bir özet gönderim saati seçmesine izin verin ve zaman dilimini onaylatın. Saat 03:00'te düşen bir özet bozuk hisseder, doğru olsa bile.
Karmaşık kontrol yerine netlik kazanın. Her olayı “Gerçek zamanlı” veya “Özet” olarak etiketleyin ki kullanıcılar tahmin etmek zorunda kalmasın. Bir olayı değiştirmenin onu özete taşıyacağını söylüyorsanız, kontrolün yanında bunu belirtin.
Önizleme endişeyi giderir. Özette nelerin olacağını küçük bir örnek gösterin: bazı başlıklar, sayılar ve en önemli öğeler. Örneğin “3 yeni yorum, 2 durum değişikliği, 1 bahsetme” ve kısa alıntılar.
“Gönderildi” sadece uygulamanızın mesajı sağlayıcıya verdiği anlamına gelir. Kullanıcılar bundan sonrasını önemsiyor. Kritik bir uyarı için “denedik” ile “ulaştı” aynı şey değildir.
Basit bir model şöyle görünür:
Bir şey başarısız olduğunda, mümkünse nedeni takip edin. “Başarısız” harekete geçirici değildir. Daha iyi örnekler: engellendi (operatör filtresi), geri döndü (posta kutusu reddetti), geçersiz adres/numara veya süresi dolmuş token (push token artık geçersiz). Her sağlayıcıdan mükemmel detay alamasanız bile bildiğiniz bilgiyi saklayın.
Geçici hatalar için yeniden deneme kuralları gerek. İyi bir varsayılan, sağlayıcıları spamlememek veya bataryayı tüketmemek için geri çekilen sınırlı yeniden denemelerdir. Örneğin: 1 dakika sonra yeniden dene, sonra 5, sonra 30, sonra durdur ve başarısız olarak işaretle. “Geçersiz numara” gibi kalıcı hatalar tekrar denenmemeli.
Kritik mesajlar için kullanıcıya basit bir durum gösterin. Birisi “Parola sıfırlama kodunu hiç almadım” dediğinde, “SMS başarısız: geçersiz numara” gibi görünen bir satır hayal kırıklığını engeller ve gerçek sorunu düzeltmelerini sağlar.
Destek ve uyumluluk için bir denetim izi tutun. Mesajın kimin için olduğunu, hangi kanalın seçildiğini, her durum için zaman damgalarını ve son bilinen hatayı saklayın.
Bildirim tercihlerini bir ayarlar yığını yerine ürün mantığı olarak ele alın. Kuralları önce kurarsanız, UI ve gönderim sistemi yeni olaylar eklendikçe tutarlı kalır.
Bildirim gönderebileceğiniz şeylerin envanteriyle başlayın. Her olay için ne kadar acil olduğunu ve hangi kanalların mantıklı olduğunu (push, e-posta, SMS) karar verin. Ardından çoğu insanın dokunmasına gerek kalmayacağı varsayılanları seçin.
Pratik bir kontrol: bir anahtarı kısa bir cümlede açıklayamıyorsanız, muhtemelen birden fazla olayı birleştiriyor ve bölünmelidir.
Her gönderimin aynı karar noktasından geçtiğinden emin olun. Kullanıcının tercihlerini, sessiz saatleri ve özet mantığını göndermeden önce uyguladığınız yer orasıdır.
Tercihleri insanların düşündüğü gibi bir yapıda saklayın: olay bazlı, kanal bazlı ve zamanlama bazlı. Sessiz saatler ve özet pencereleri için zaman dilimi işleme ve kritik uyarılar için istisnalar ekleyin. Tam zinciri kaydedin: gönderim denemesi, sağlayıcı yanıtı (teslim edildi, geri döndü, başarısız) ve kullanıcı eylemleri (abone çıkma, değişiklikler).
Örnek: bir kullanıcı “haftalık ipuçları” e-postasını kapattı ama “güvenlik uyarıları” e-postasını açık tuttu ve sessiz saatleri 22:00–07:00 olarak ayarlı. Kurallarınız yine de acil bir parola sıfırlama e-postasına 02:00'de izin vermeli, düşük öncelikli mesajları sabah özetine tutmalıdır.
Çoğu insan güncellemeler almaktan rahatsız olmaz. Hissedilenler: kapana kısılmış, kafası karışmış veya görmezden gelinmiş hissetmek. Birkaç tasarım hatası bildirim tercihler ekranınızı kullanıcıların bir kez gelip sinirlenip tekrar dokunmadığı bir yere çevirebilir.
Yaygın kalıplar:
Bunun çoğunu engelleyen iki düzeltme var. Birincisi, her kontrolün tek bir soruyu yanıtlamasını sağlayın: hangi olay, hangi kanal, hangi zamanlama. İsimleri somut tutun, örneğin “Yeni fatura ödendi” gibi. İkincisi, teslimatı sadece “gönderildi” olarak ele almayın; aksi halde e-posta geri döndüğünde veya push cihaza ulaşmadığında başarı iddia etmiş olursunuz.
Bildirim tercihlerini yayımlamadan önce gerçek bir kullanıcı gibi hızlı bir geçiş yapın. Yorulmuş, meşgul ve sadece gürültüyü durdurup önemli bir şeyi kaçırmamak isteyen biriymiş gibi davranın.
Önce en gürültülü olayı düşünün. Birisi tek bir gürültülü tetikleyiciyi kapatamıyorsa ve aynı anda kritik uyarıları da kaybediyorsa, ayarlar haksız hissedilir.
Sonra zamanlamayı kontrol edin. Kullanıcıların bir mesajın şimdi mi, özette mi yoksa hiç mi geleceğini tahmin etmek zorunda kalmaması gerekir. UI bunu net olarak söylemeli ve önizleme metni gerçekten olanla uyuşmalıdır.
Yayın öncesi kontrol listesi:
Sessiz saatler kafa karışıklığının en çok sızdığı yerdir. Kontrol basit bir pencere göstermeli: “22:00 – 07:00” gibi ve engellenen bildirimlere ne olacağını açıklamalı (sessize alınır, geciktirilir veya bir sonraki özete taşınır). Eğer istisnalara izin veriyorsanız, bunları “Her zaman güvenlik uyarılarına izin ver” gibi sade ifadelerle etiketleyin.
Son olarak, eylem ile kanıt arasındaki döngüyü test edin. Bir kullanıcı “Hiç almadım” dediğinde, sisteminiz şu sorunun cevabını verebilmeli: sıraya alındı mı, sağlayıcıya verildi mi, cihaza teslim edildi mi yoksa reddedildi mi?
Maya 12 kişilik bir destek ekibine liderlik ediyor. Müşteri verilerini riske atabilecek bir şey olup olmadığını bilmek istiyor, ama telefonunun her yorum, emoji veya rutin güncelleme için titremesini istemiyor. Ayrıca sık sık toplantıda oluyor, bu yüzden varsayılan olarak sessiz ve yalnızca gerçekten gerekliyse yüksek sesli bir kurulum istiyor.
Tercihleri şöyle görünüyor:
Arka plan gürültüsü için ticket aktivitesi, durum değişiklikleri ve acil olmayan yorumları özet olarak alıyor. Bir şey acil hale gelirse, bildirim olur, özetin parçası olmaz.
Sessiz saatleri hafta içi 21:00–07:00 yerel zamanında ayarlı ve bir istisna var: güvenlik uyarıları sessiz saatleri atlıyor. Şüpheli bir giriş 02:00'de olursa, onu yine alır.
Teslimat takibi kurulu olduğunda kurulumu tahmin oyunundan çıkarır. Maya parola sıfırlama istediğinde, mesajın sadece uygulama tarafından “gönderildi” olarak işaretlenmediğini, e-posta sağlayıcısına teslim edildiğini görebilir. Öte yandan, bir müşterinin aylık faturası geri dönerse ekip bunun gelen kutusuna ulaşmadığını bilir.
Birisi “Hiç almadım” dediğinde destek şu yolu takip eder:
Bir olay listesiyle başlayın. Her olay için kritik mi (güvenlik, faturalama, hesap erişimi) yoksa isteğe bağlı mı (yorumlar, beğeniler, ipuçları) karar verin. Bir olayı tek cümlede neden var olduğunu açıklayamıyorsanız, muhtemelen ilk sürümünüze dahil edilmemelidir.
Kullanıcıya dönük etiketleri meşgul bir kişiye konuşuyormuş gibi yazın. Spesifik tutun (“Yeni cihazdan giriş”) ve tek satırlık bir önizleme ekleyin (“Hesap güvenliği için hemen haber verilecektir”).
Yayınlamadan önce teslimat günlüklemesini ekleyin ki destek gerçek soruyu cevaplayabilsin: “Bana ulaştı mı?” Oluşandan kuyruğa, sağlayıcıya devreye, teslim edildi veya başarısız olana ve varsa açılma bilgisine kadar yolu takip edin.
Eğer tercihler merkezini no-code bir platform içinde inşa ediyorsanız, bildirimleri birinci sınıf ürün özellikleri gibi ele almak faydalıdır: olayları tanımlayın, kullanıcı başına ayarları PostgreSQL'de saklayın ve tüm bildirimler için tek bir karar adımı tutun ki UI ve backend ürün büyüdükçe uyumlu kalsın. AppMaster (appmaster.io) bu tür uygulama mantığı için tasarlanmıştır; backend kuralları ve UI ayarları ürün büyüdükçe uyumlu kalmalıdır.
Küçük bir yüzdeyle yayınlayın, sonra çıkış oranlarını, “tümünü sustur” kullanımını, eksik uyarılarla ilgili destek ticketlarını ve şikayet temalarını izleyin. Eğer tek bir olay çoğu kapatma sebebiyle çıkıyorsa, daha fazla eklemeden önce o olayı düzeltin.
Kullanıcılar özellik faydalı olsa bile neden bildirimleri kapatıyor?Çünkü uyarı kullanıcının niyetiyle eşleşmiyor. İnsanlar bildirimlerin hareket etmelerine gerçekten yardımcı olduğunu açıkça gördüklerinde sık bildirimlere katlanırlar; ancak mesajlar tekrarlı, alakasız veya yanlış zamanda geldiğinde kapatırlar.
Yeni kullanıcı için varsayılan bildirim ayarları ne olmalı?Kritik olmayan her şey için varsayılan olarak sessiz başlamak iyi bir yaklaşımdır; ardından kullanıcıların isteğe göre katılmasına izin verin. Güvenlikle ilgili ve bazı faturalama uyarıları gibi kritik maddeleri varsayılan açık tutun; geri kalanının kontrolünü kullanıcılara kolayca bırakın, böylece yeni kullanıcılar ayarlarla uğraşmadan saygı görmüş hisseder.
Çok fazla bildirim anahtarım olduğunu nasıl anlarım?Bir sonraki adım aynıysa benzer olayları gruplayın; karar değiştiğinde bölün. Bulmaca: O anahtarın ne olduğunu ve ne yapılacağını kısa bir cümlede açıklayamıyorsanız, muhtemelen çok belirsiz veya çok geniştir.
Bildirim tercihlerini anlaşılır hissettirecek en iyi etiketleme yöntemi nedir?Anahtarları ürün alanı yerine gerçek olaylar olarak adlandırın. “Ödeme başarısız” veya “Hesabınıza yeni giriş” gibi etiketler beklentiyi belirler; “Güncellemeler” veya “Aktivite” gibi etiketlerse kullanıcıyı tahmin etmeye zorlar ve genelde kapatma ile sonuçlanır.
Hangi bildirimlerin kullanıcılar tarafından asla kapatılamaması gerekir?‘Kapatılamaz’ yalnızca nadir, yüksek riskli uyarılar için kullanılmalı; öncelikle güvenlik ve bazı faturalama hataları (birini kilitleyebilecek veya hizmeti durdurabilecek durumlar). Bir şeyi açık tutmak zorundaysanız, nedenini basitçe açıklayın ki bu koruyucu hissetsin, baskıcı değil.
Kullanıcıları şaşırtmamak için sessiz saatler nasıl davranmalı?Sessiz saatler, kullanıcının seçtiği zaman aralığında kritik olmayan bildirimleri geciktirip sessize almalıdır; aynı zamanda küçük bir istisna listesine izin vermelidir. Zaman dilimini doğru ele alın, böylece seyahat eden veya yaz saati uygulaması değişikliğine maruz kalan kullanıcılar aynı ayarı ‘bozuk’ olarak hissetmesin.
Gerçek zamanlı yerine ne zaman özet sunmalıyım?Gürültülü, düşük öncelikli güncellemeler (reaksiyonlar, rutin aktivite, günlük istatistikler) için özetleri kullanın; işinizi engelleyen, hızlı yanıt gerektiren veya son tarih içeren şeyleri gerçek zamanlı tutun. Anahtar: tahmin edilebilirlik — kullanıcı aynı olay için hem özet hem anlık bildirim almamalı, aksi halde kafa karışıklığı oluşur.
“Gönderildi” ile “teslim edildi” arasındaki fark nedir ve neden önemli?“Gönderildi” yalnızca mesajın sağlayıcıya verildiği anlamına gelir; kullanıcının alıp almadığını göstermez. Teslim edildi, geri döndü (bounced), engellendi veya geçersiz hedef gibi durumları takip edin ki destek “sana ulaştı mı?” sorusuna cevap verebilsin ve kullanıcı yanlış e-posta veya süresi dolmuş push tokenı gibi sorunları düzeltebilsin.
Bildirim teslimi başarısız olduğunda tekrar denemeleri nasıl ele almalıyım?Geçici hatalarda geri deneme için sınırlı, geri çekilen (backoff) bir strateji kullanın; sonra durup mesajı eylem alınabilecek bir nedene göre başarısız olarak işaretleyin. Geçersiz telefon numarası gibi kalıcı hataları tekrar denemeyin ve hızlı tekrarlarla sağlayıcıları spamlemeyin veya cihaz bataryasını tüketmeyin.
Dağınık bir sistem yaratmadan bildirim tercihlerini nasıl uygularım?Kullanıcı başına tercihleri olay, kanal ve zamanlama bazında saklayın, sonra her bildirimi göndermeden önce bu kuralları uygulayan tek bir karar adımından geçirin. AppMaster'da bu genelde tercihleri PostgreSQL'de modellemek ve sessiz saatleri, özetleri ve istisnaları tek bir iş sürecinde zorunlu kılmak demektir; böylece UI ve backend, daha fazla olay ekledikçe uyumlu kalır.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
