ENTR

Kullanıcıların yüksek oranda bildirimleri kapattığı bir tüketici uygulamasının bildirim sistemini nasıl yeniden tasarlarsın?

Model cevap

Model cevapBildirimlerin yüksek oranda kapatılıyor olması, bildirim sisteminin kullanıcının değil, ürünün hedefleri doğrultusunda inşa edildiğini gösterir. İşe verilerle başlardım: Bildirim kapatma işlemlerini bildirim türüne, günün saatine ve kullanıcı kıdemine göre segmentlere ayırırdım. Çünkü ilk haftasında bildirimleri kapatan birinin sorunu ile 6 ay sonra kapatan birininki farklıdır. Ardından, her bildirim türü için bir değer skoru hesaplardım: Açılma oranı ile aksiyon oranının çarpımından bildirim kapatma oranını çıkarırdım. Negatif değer üreten türleri derhal kaldırırdım. Yeniden tasarım süreci üç katmandan oluşur: Daha akıllı varsayılanlar (daha az sayıda ve daha iyi zamanlanmış), granüler tercih kontrolleri (sadece aç/kapat değil; türe ve zamana göre) ve zaman içinde kişiselleştirme. Başarı metrikleri ise şunlar olurdu: Bildirim opt-in oranı ve en az bir bildirim türünü açık tutan kullanıcılar ile tümünü kapatan kullanıcıların 30 günlük retention oranlarının kıyaslanması.

Framework · HEART Yöntemi

  1. HHappiness
    Bildirim türüne göre kapatma oranı, kullanıcıların kendine saygısızlık olarak gördüğü yerin en net sinyali
  2. EEngagement
    Türe ve günün saatine göre açılma ve aksiyon oranı, kullanıcıların gerçekten değer verdiği bildirimleri belirle
  3. AAdoption
    Kullanıcıların yüzde kaçı tercihlerini özelleştirdi? Düşük özelleştirme varsayılanların bozuk olduğunu gösterir
  4. RRetention
    En az bir bildirimi açık olan kullanıcılar 30 günde daha iyi süreklilik sağlıyor mu? Evet ise bildirimler değer yaratıyor.
  5. TTask Success
    Kullanıcılar 60 saniyede bildirim tercihlerini bulup değiştirebiliyor mu? Cevap hayırsa bildirim ayarları fazla gizlenmiş.

İlgili sorular

Ürün İçgörüsü

Bu kategorideki case çalışmaları

Bu kategoride pratik yap