Kullanıcıların kapatmadığı push bildirimleri: zamanlama ve tasarım

İnsanların push bildirimlerini neden kapattığı

Rahatsız edici bildirimler, tüm gün omzunuzu dürtüyor gibi gelir; sonra odadan çıkınca şaşırmış gibi davranırlar. Kesintiye uğratır, dikkat ister ve çoğu zaman hiçbir karşılık vermez. Birkaç gün sonra insanlar en basit şeyi yapar: sizi sustururlar.

Çoğu opt-out mantıklı nedenlerle olur. Mesajlar çok sık gelir, ilgili değildir veya yanlış zamanda görünür (gece geç saatler, iş sırasında veya kullanıcı zaten işlemi yapmışken). Bazen içerik belirsiz veya ilgi çekmeye çalışır, bu yüzden kullanıcılar güveni kaybeder. Ve ilk bildirim, kullanıcı uygulamanın değerini anlamadan önce gelirse, şöyle okunur: "Beni yeni tanıyorsun ama kilit ekranıma erişmek istiyorsun."

Push'u kapatmak aynı zamanda zihinsel gürültüyü azaltmanın bir yoludur. Birçok insan zaten e-posta, sosyal uygulamalar ve grup sohbetlerinden bildirim yorgunluğu hisseder. Uygulamanız küçük rastgele uyarılar eklerse, diğerlerinin yanına katılır ve kesilir. Mobilde bu karar serttir: bir kez kapatıldığında, birçok kullanıcı onu asla tekrar açmaz.

Gerçek hedef bir kerelik izin almak değil. Her mesaj yerini hak ettiği için aylardır izni korumaktır.

İyi bir bildirim tanımı basittir: beklenen, faydalı ve zamanında olandır. Beklenen, kullanıcının neden aldığını tahmin edebilmesi anlamına gelir. Faydalı, zaten önem verdikleri bir konuda onlara yardımcı olması demektir. Zamanında ise sisteminiz hazır olduğunda değil, yardım edebileceği anda gelmesi demektir.

Opt-out'i tetikleyen kalıplar tahmin edilebilirdir: ilk açılışta açık neden belirtilmeden izin istemek, kişisel değeri olmayan "Seni özledik" mesajları, kullanıcı iki kez görmezden geldikten sonra aynı hatırlatmayı tekrarlamak, rutin güncellemeler için aciliyet kelimeleri kullanmak ve pazarlama patlamalarını önemli uyarılarla aynı kanala karıştırmak.

Push'u bir ayrıcalık olarak ele alırsanız, kullanıcılar bunu bir fayet gibi görür. Onu ücretsiz reklam alanı gibi görürseniz, kullanıcılar buna spam muamelesi yapar.

Birinin izne razı olmasını sağlayan şey

İnsanlar, bildirimlerin onlara yardımcı olacağına inandıklarında "İzin Ver" der. Kapatılmayan push bildirimleri elde etmek için en kolay yol, izni bir değer değişimi olarak görmek: belirli bir şey vadedersiniz ve sonra bunu tutarlı şekilde teslim edersiniz.

İzni istemeden önce, vaadi açık dilde söyleyin. "Güncel kalın" gibi belirsiz satırlardan kaçının. Bunun yerine ne geleceğini, neden önemli olduğunu ve kullanıcının neyi kontrol edebileceğini açıklayın. İyi bir ön-izin ekranı üç şeyi yanıtlar: ne göndereceksiniz (sipariş durumu, hatırlatmalar, fiyat düşüşleri, güvenlik uyarıları), ne sıklıkta olacak (ve "nadiren"in ne anlama geldiği) ve daha sonra nasıl değiştirebilecekleri (tercihler, sessiz saatler, duraklat).

İzinler, kullanıcının zaten sahip olduğu gerçek bir hedefle eşleştiğinde artar. Onların ne yapmaya çalıştığını düşünün, siz neyi tanıtmak istersiniz diye değil.

İnsanlar somut değere daha yatkındır: tasarruflar ("Fiyat düştü"), hatırlatmalar ("Randevunuz 2 saat içinde"), güncellemeler ("Teslimatınız 10 dakika içinde"), güvenlik ("Yeni giriş"), veya ilerleme ("Haftalık hedefinizi yakaladınız").

Beklentileri erken belirleyin, hatta bu daha az "satış odaklı" hissettirse bile. Haftada beş mesaj gönderiyorsanız, bunu söyleyin. Tetkik-odaklıysa (örneğin gönderim güncellemeleri), onu da belirtin. Sürprizler güvensizlik yaratır ve güvensizlik opt-out'e dönüşür.

Sistem istemi görünmeden önce küçük bir değer örneği gösterin. Bir gerçekçi örnek bir paragraf kopyasından daha çok iş yapabilir:

"Örnek bildirim: Paketi teslimata çıktı - 15:10 ile 15:40 arasında varacak."

Bu bir satır, insanların bunun hangi anı kurtardığını hayal etmelerine yardımcı olur ve onlara spam planınız olmadığını işaret eder.

Doğal hissettiren izin zamanlaması

Çoğu insan bildirimlerden nefret etmez. Çok erken, ne alacaklarını anlamadan sorulmasından nefret ederler. İzin zamanlaması çoğu zaman kapanmayan push ile sonsuza dek kapatılan push arasındaki farktır.

Basit bir kural işe yarar: ilgi gösterdiğini kanıtlayan bir eylemden hemen sonra isteyin. Birisi bir öğeyi kaydettiğinde, bir konuyu takip ettiğinde, bir randevu aldığında veya bir antrenmanı bitirdiğinde, neyin onlar için önemli olduğunu göstermiş olur. İşte güncellemelere bağlı bildirim teklif etme zamanı.

Güvenilir bir desen, sistem izin isteminden önce bir yumuşak-izin ekranıdır. Kısa ve spesifik tutun: ne alacakları, ne sıklıkta ve neden yardımcı olacağı. Sonra iki net buton ekleyin: "Bildirimlere izin ver" ve "Şimdi değil." Kullanıcı "İzin Ver" seçerse yalnızca sistem istemi gösterin. Bu sürprizi ortadan kaldırır ve beklentileri belirler.

Sormak için iyi anlar genellikle bir kazanımın hemen sonrasıdır (sipariş verildi, hedef tamamlandı), takip/abonelikten hemen sonra, kaydetme/yer işareti koyduktan sonra, hatırlatıcı ayarladıktan veya bir şeyi takip etmeye başladıktan sonra, ya da güncellemeye ihtiyaç duyan bir özelliği açtıktan sonra.

Kötü anlar ise kullanıcıların meşgul, endişeli veya şüpheci olduğu anlardır. İlk açılışta sormak yaygın bir hatadır çünkü henüz güven yoktur. Kayıt sırasında sormak da risklidir çünkü insanlar formları, parolaları ve doğrulamayı halletmeye çalışıyordur.

Eğer hayır derlerse, onları cezalandırmayın ve sürekli istem göstermeyin. Nazikçe geri çekilin. Uygulamayı normal kullanmaya devam edebileceklerini doğrulayın ve daha sonra ilgili özelliğin yakınında sessiz bir seçenek sunun. Örneğin: "Kaydedilen öğeniz değiştiğinde bildirim al" şeklinde bir açma/kapama, böylece seçim gerçek bir faydaya bağlı hissedilir.

Somut örnek: bir ikinci el satış uygulaması kullanıcıların "8 numara bot" için arama kaydetmesine izin veriyor. Kullanıcı "Aramayı kaydet"e dokunduktan hemen sonra bir ekran şöyle der: "Yeni eşleşmeler göründüğünde bildirim ister misiniz? Günde en fazla 1 göndeririz." Bu istek hak edilmiş hisseder çünkü kullanıcı az önce bunu istemiştir.

Bir bildirim tercih merkezi tasarlamak

İyi bir tercih merkezi güvenlik süzgecinizdir. Kullanıcıların sistem düzeyinde bildirimleri kapatmalarını önler çünkü ayarları kilitlenmiş hissetmeden yukarı veya aşağı çekebilirler.

İnsanların çabucak anlayacağı üç kontrolle başlayın: konular, sıklık ve sessiz saatler. Konular onların gerçekten neyle ilgilendiklerini seçmelerini sağlar. Sıklık, birçok opt-out'in arkasındaki gerçek soruyu yanıtlar: "Neden bu kadar mesaj atıyorsunuz?" Sessiz saatler, kapatılmanın en hızlı yolunu engeller: yanlış saatte gelen bir titreşim.

Dahil edilecek kontroller (ve nasıl etiketlenecekleri)

Seçimleri az ve düz tutun. 20 anahtar sunarsanız, insanlar onları yönetmek yerine sizi kapatır.

Kısa bir set hedefleyin: konu kategorileri (siparişler, hatırlatmalar, güvenlik, ürün güncellemeleri — kullanıcıların kullandığı kelimelerle), sıklık seçenekleri (anlık, günlük özet, haftalık özet), sessiz saatler (cihaz saatine göre zaman aralığı), kanal seçimleri (push vs e-posta vs uygulama içi uyarılar) ve duraklatma seçeneği (24 saat veya 7 gün için ertele).

Varsayılanlar önemlidir. Yardımcı ama agresif olmayan ayarlar seçin. Birçok üründe güvenli bir varsayılan: temel uyarılar açık (güvenlik veya işlem durumu), pazarlama tarzı güncellemeler kapalı ve uygun olduğunda özet sıklığı açık. Her şey başta açıksa, ilk günde bildirim yorgunluğu yaratırsınız.

Nereye yerleştirilmeli

Tercihleri yalnızca derin bir ayarlar menüsünde saklamayın. İnsanların ilgilendiklerinde doğal olarak baktıkları yerlere koyun.

Önemli işlemlerden sonra küçük bir istem gösterin: "Bu konuda güncelleme ister misiniz?" ve onları doğrudan konu ve sıklık seçeneklerine gönderin. Örneğin bir sipariş verildikten sonra, "Sipariş durumu" push'unu etkinleştirmelerine izin verin, promosyonları kapalı bırakın.

Ayrıca Hesap/Ayarlar içinde kolay erişilebilir yapın ve bir bildirim gösterildiğinde (örneğin uygulama içi gelen kutusunun yanında) "Bildirimleri yönet" gibi bir bağlantı olsun. Bir kullanıcı rahatsız hissederse, duraklat veya daha az sıklık seçeneklerini 10 saniyeden kısa sürede bulabilmelidir, sistem ayarına gitmek zorunda kalmamalıdır.

Koder.ai ile ürünler geliştiriyorsanız, tercih merkezini dipnot değil birinci sınıf özellik olarak ele alın. Bir opt-in'i korumak, onu yeniden kazanmaktan daha ucuzdur.

Kullanıcıların güvendiği mesaj tasarımı

Kullanıcılar, mesajlar omuzlarına faydalı bir dokunuş gibi geldiğinde bildirimleri açık tutar, dikkat çekmeye çalışan bir çırpınış gibi değil. Kapatılmayan en iyi push bildirimleri, neden geldiklerini ve kişinin ne yapabileceğini açıkça belirtir.

İnsan gibi yazın. Kısa, sade kelimeler kullanın ve önemli detayı öne koyun. "Raporunuz hazır" "Yeni güncelleme var"dan iyidir. Spesifik olmak zekâpçılıktan iyidir.

Bir mesajı bir amaç için sınırlayın. Bir bildirim iki şey yapmaya çalışırsa (haber + promosyon + hatırlatma), reklam gibi görünür ve insanların görmezden gelmesine sebep olur. Söylenecek daha fazla şey varsa, daha az bildirim gönderin ve geri kalanını uygulama halletsin.

Kişiselleştirme hak edilmelidir. Kullanıcının açıkça yaptığı bir şeye dayandırın, tahminlerinize değil.

Örneğin, biri dün kaynak kodu dışa aktardıysa, "Dışa aktarma tamamlandı. ZIP'iniz hazır" mantıklıdır. Eğer mobil yapmak hiç istememiş birine "Bugün mobil uygulama yapalım mı?" gönderirseniz, bu rastgele ve rahatsız edici hisseder.

Aciliyet kabul edilebilir. Baskı uygulanamaz. Gerçek aciliyet, sonucu drama yapmadan açıklar:

• İyi: "Ödeme başarısız oldu. Yarın erişimi kaybetmemek için kartınızı güncelleyin."
• Kötü: "Son şans! Hemen harekete geç!"

Zamanlama insanların düşündüğünden daha önemlidir. Yanlış saatte gelen faydalı bir mesaj rahatsızlığa dönüşür. Yerel zamana saygı gösterin ve yaygın uyku saatlerinden kaçının. İşle ilgili ürünler için, gerçekten acil değilse tipik iş saatleri içinde kalmayı deneyin.

İşe yarayan basit bir şablon

Tutarlı bir yapı, kullanıcıların tarzınıza güvenmeyi öğrenmesine yardımcı olur:

• Ne oldu (1 kısa cümle)
• Neden önemli (isteğe bağlı, 1 kısa ifade)
• Ne yapmalı (bir net eylem)

Koder.ai gibi bir ürün için örnek: "Deployment başarısız oldu. Tekrar denemek için loglara bak." Doğrudan, kullanıcının yaptığı bir eyleme uyuyor ve her şeyin acilmiş gibi görünmesine neden olmuyor.

Mesajlar spesifik, beklenen ve iyi zamanlanmış olduğunda, kullanıcılar bildirimleri ürünün bir parçası olarak deneyimler, gürültü olarak değil.

Adım adım: bildirim sisteminizi planlayın

Kapatılmayan push bildirimleri istiyorsanız, plan yapmak kopya kadar önemlidir. Küçük bir plan, “ne faydalı geliyorsa onu gönder” hatasına düşüp istemeden yorgunluk yaratmanızı engeller.

1) Bir bildirim envanteri oluşturun

Gönderebileceğiniz her push mesajını listeleyin; açık olanları (sipariş güncellemeleri, hatırlatmalar) ve "belki sonra" olanları (özetler, promosyonlar) dahil edin. Her birine konuşurken kullanacağınız bir çalışma adı verin.

Her bildirim için yazın: ne için, kimi yardımcı eder ve kullanıcı bunu gördükten sonra ne yapmalı. Bunları bir cümlede cevaplayamıyorsanız, gönderilmeye değmeyebilir.

2) Mesajları amaçlarına göre gruplayın

Envanterinizi birkaç insan dostu kovaya ayırın. Birçok uygulama için bunlar yeterlidir: hatırlatmalar (kullanıcının istediği veya başlattığı şeyler), güncellemeler (bekledikleri durum değişiklikleri), promosyonlar (indirimler, upsell), güvenlik/hesap (güvenlik uyarıları, politika değişiklikleri) ve ipuçları/öğretici (kullanıcılar açıkça isterse).

Bu gruplar tercih merkezi UX'inizin omurgası olur. Kullanıcılar 25 toggle istemez; 3 ila 6 mantıklı seçenek isterler.

3) Tetikleyicileri ve limitleri belirleyin

Her mesaj için neyin tetikleyeceğini ve hangi sınırlar olacağını tanımlayın. Tetikleyiciler "ne zaman ilgili?" sorusunu, limitler ise "spam'ı nasıl önleriz?" sorusunu yanıtlar.

Pratik bir set: gün başına maksimum, hafta başına maksimum ve sessiz pencere (örneğin kullanıcının yerel saatinde gece gönderme). Ayrıca birden fazla bildirim yarıştığında ne olacağını kararlaştırın: hangisi kazanır, hangileri atılır?

4) Şablonlar taslaklayın ve kullanıcı dilinde adlandırın

Her bildirim için kısa bir şablon oluşturun: başlık, gövde ve dokunma eylemi. Ona kullanıcıların tarif edeceği gibi bir isim verin, dahili kod gibi değil. "Teslimat güncellemesi" "SHIP_STATUS_CHANGED_V2"dan daha iyidir.

Bu ad disiplininin faydası, izinli mesajlaşma ve ayarlar inşa ederken ve destek gerektiğinde kullanıcının ne aldığını açıklarken ortaya çıkar.

5) Gerçek senaryolarla QA yapın

Planınızı tekil mesajlar yerine gerçek yolculuklarla test edin. Yeni bir kullanıcı (düşük güven), geri gelen bir kullanıcı (daha az sürpriz ister) ve bir power user (yüksek hacim, kontrol ister) üzerinden geçin. Promosyonları kapatıp güvenlik uyarılarını açık tutan bir vaka ve 30 gün boyunca inaktif olan bir vaka dahil edin.

Herhangi bir senaryo bir dizi bildirim, kafa karıştırıcı zamanlama veya çok varsayım yapan mesaj üretiyorsa, izni istemeden önce tetikleyiciyi düzeltin veya limitleri sıkılaştırın.

Opt-out'e yol açan yaygın hatalar

Çoğu insan bildirimlerden nefret etmez. Sürprizlerden, karmaşadan ve şirket için gönderilen mesajlardan nefret ederler. İzni tek seferlik bir zafer değil, devam eden bir ilişki olarak görmek güveni kaybetmenin en hızlı yoludur.

Yaygın bir hata, uygulama açılır açılmaz izin istemektir; kişi henüz hiçbir şey yapmamıştır. Bağlam olmadan istek rastgele hissedilir, bu yüzden kullanıcı ya reddeder ya da kabul edip sonra pişman olur. Daha iyi kural: ilk "evet"i, gerçekten bir fayda olduğunda hak edin.

Bir diğer güven katili hacimdir. Birçok ekip, birini etkinleştirmek için opt-in'den hemen sonra bir dizi mesaj gönderir. Bu genelde bildirim yorgunluğu yaratır ve kullanıcının sonraki hareketi her şeyi kapatmaktır. Erken mesaj göndermeniz gerekiyorsa, az, spesifik ve kullanıcının zaten yaptığı eylemlere bağlı olsun.

Belirsiz metin de opt-out'e yol açar. "Buna göz at" veya "Kaçırmayın" gibi mesajlar, kullanıcıları ne için kesildiklerini öğrenmek üzere uygulamayı açmaya zorlar. Değer gerçekse, açıkça söyleyin.

Zamanlama hataları da aynı derecede zarar vericidir. Zaman dilimlerini yok sayarsanız, insanları toplantı, akşam yemeği veya uyku sırasında rahatsız edersiniz. Tek bir 03:00 titreşimi bile tüm uyarıları kapatmaya yetebilir.

Son olarak, tercihleri kolay hale getirin. Tek seçenekler "hepsi" veya "hiçbiri" ise "hiçbiri" kazanır. İnsanların bir şeyi duraklatma yolu da olmalı.

Opt-out'lerin arkasındaki kalıplar tutarlıdır: izin istemi çok erken çıkıyor, ilk 24-72 saatte çok fazla bildirim gidiyor, mesajlar amacını gizliyor, gönderimler garip yerel saatlere düşüyor ve basit bir kontrol yok (duraklat, sessiz saatler, konu seçimleri).

Örnek: bir alışveriş uygulaması sabah 7'de üç gün üst üste "Büyük haber!" gönderiyor ve promosyonları susturmanın bir yolu yok. Kullanıcı tüm bildirimleri kapatır, faydalı olanlar da dahil.

Göndermeden önce hızlı kontroller

Göndermeden önce 30 saniye durun. Çoğu opt-out beklenmeyen, belirsiz veya çok sık gelen bir mesaj sonrası olur.

5 saniyelik alaka testi

Bir soru sorun: kullanıcı şu anda bunu bekliyor mu?

Bir sipariş gönderildiğinde teslimat güncellemesi mantıklıdır. Bir ürünü aldıktan sonraki sabah gönderilen promosyon mantıklı değildir. Hızlı bir kontrol listesi kullanın:

• Bu, kullanıcının az önce yaptığı bir şeyle eşleşiyor mu?
• İlk satırdan açmadan anlaşılabilir mi?
• Mantıklı yerel saatte inecek mi ve sessiz saatlerden kaçınıyor mu?
• Bu tür mesaj için bir üst sınır var mı?
• Eğer kullanıcı hoşlanmazsa, bu kategoriyi ayarlardan kapatabiliyor mu?

Sonra mesajı yabancı biri gibi okuyun. Değer ilk bakışta açık değilse, ilk satırı yeniden yazın. Çok fazla bağlam gerekiyorsa, muhtemelen push olmamalıdır.

Yorgunluğu önleyen zamanlama ve kontrol kontrolleri

İki şey sessizce yorgunluğu sürer: kötü zamanlama ve çıkış yolu olmaması. Yerel saat düşündüğünüzden daha fazla önemlidir. Sizin için sabah 9 olan gönderim, onlar için 02:00 olabilir ve bir kaba uykudan uyandırma kanalınızı kaybettirebilir.

Sıklık üstleri diğer koruyucudur. Kategori başına bir tavan belirleyin (örneğin promosyonlar için haftada en fazla 2) ve pazarlama heyecanı gelsin diye buna sadık kalın. Kendi kuralınızı bozduğunuz anda kullanıcılar bunun devam edeceğini varsayar.

Son olarak, tercih merkezinin bu kategoriyi gerçekten içerdiğini doğrulayın. Hızlı bir akıl testi: bir kullanıcı şikayet ederse destek ona 10 saniyeden kısa sürede nereden değiştirebileceğini söyleyebiliyor mu? Eğer hayırsa, gönderdiğiniz mesajın arkasında durmaya hazır değilsiniz demektir.

Örnek: biri uçuşlara baktıysa, tek bir fiyat düşüşü bildirimi faydalıdır. Aynı gün içinde üç bildirim ve "fiyat düşüşleri"ni susturma yolu yoksa, teklifler gerçek olsa bile spam gibi hissedilir.

Gerçekçi bir örnek: rahatsız etmeden izin kazanmak

Bir yemek planlama uygulamasını düşünün. Push izinleri istiyor ama kötü bir ilk izlenimin hızlı kapatmalara yol açacağını da biliyor.

İlk oturumda uygulama önce kullanıcıya yardım eder. Tarif aramalarına izin verir, favorileri kaydettirir ve basit bir haftalık plan oluşturur. İzin penceresi yok. Bunun yerine küçük bir not gösterir: "İstersen daha sonra hatırlatmalar alabilirsin." Kullanıcı göreve odaklanır, sistem penceresiyle değil.

Uygulamanın sorma hakkını kazandığı an, belirgin bir eyleme bağlıdır. Kullanıcı 3 tarif kaydettikten sonra nazik bir ekran gösterir (hala OS istemi değil): "Pişirme zamanı geldiğinde hatırlatılmak ister misiniz? Ne istediğinizi seçin." Kullanıcı "Evet" derse uygulama izin isteğini tetikler. "Şimdi değil" derse uygulama geri çekilir ve normal şekilde çalışmaya devam eder.

Sonraki ekran sade bir tercih merkezi sunar; sade dil ve mantıklı varsayılanlar içerir. Birkaç seçenek sunar: yemek hatırlatmaları (planlanan akşamlar için), yeni tarifler (haftalık özet) ve fırsatlar (yalnızca istenirse). Her seçenek sıklığı açıklar. Örneğin, "Yemek hatırlatmaları: planladığınız günlerde günde en fazla 1." "Yeni tarifler: haftada bir." Fırsatlar varsayılan olarak kapalıdır.

Bir hafta sonra sonuçlar, genelde "açılışta sorma" yaklaşımından farklıdır. Toplamda daha az kişi izin veriyor olabilir, ama izin verenler daha memnun. Gönderimler daha az çünkü uygulama yalnızca bu tür mesajı isteyenleri, seçtikleri hızda tetikliyor. Bu daha az kapatma ve daha az "her şeyi kapat" anı demektir.

İşte kullanıcıların kapatmadığı push bildirimlerini elde etme yolu: izin isteğini kullanıcının zaten kazandığı bir başarıya bağlayın ve her mesajın kişisel olarak istedikleri bir şey gibi hissetmesini sağlayın.

Ölçün, iyileştirin ve sonraki adımları belirleyin

Bildirimleri bir ürün özelliği gibi ele alın: ne olduğunu ölçün, bir şeyi değiştirin ve hızlı öğrenin.

İlk olarak güveni kazanıp kazanmadığınızı söyleyen çıktıları izleyin. Yalnızca açılara takılmayın. Maliyeti de görün:

• İzin oranı (ekran, an, kullanıcı segmentine göre)
• Kapatma oranı (belirli bildirimlerden sonra ve zaman içinde)
• Açılma oranı (ve sonrası eylemler, sadece dokunuş değil)
• Churn sinyalleri (kaldırmalar, daha az oturum, e-posta abonelikten çıkışlar)
• Tercih düzenlemeleri (hangi kullanıcılar kategorileri kapattı vs hepsini kapattı)

Sonra en büyük suçluları inceleyin. Bir kategori, zaman penceresi veya tekrar eden bir şablon olup olmadığını arayın; bunlar kapatmalara yol açıyor olabilir. Her bildirimi basit bir sebep etiketiyle (sipariş güncellemesi, hatırlatma, promosyon) etiketleyin ki şu soruyu yanıtlayabilesiniz: "Hangi mesajlar her 1.000 gönderimde en çok opt-out'e neden oldu?" Önce onları düzeltin.

Büyük yeniden lansmanlar yerine küçük testler yapın. Her seferde bir değişken değiştirin: daha sonra sorma (belirgin bir başarı anından sonra), faydayı açıkça söyleyecek şekilde kopyayı yeniden yazma, kategori başına frekans sınırı koyma, mutlaka bilinmesi gereken ile isteğe bağlı olanı ayırma ve başlangıçta daha az kategori etkinleştirme.

Tercihleri görünür ve düzenlemesi kolay tutun. Kullanıcı bir tür bildirimi hızla susturabiliyorsa, her şeyi kapatma olasılığı düşer. Faydalı bir kural: herhangi bir bildirim tercih merkezinden 2 dokunuş veya daha azla düzenlenebilir olmalı.

Hızlı ilerlemek istiyorsanız, izin akışı ve tercih merkezini Koder.ai (koder.ai) içinde oluşturup yineleyerek değişiklikleri hızlıca yayınlayabilir, hazır olduğunuzda kaynak kodunu dışa aktarabilirsiniz.