Pasif Bilgi Edinimi: Kullanıcının Alışkanlığı Değil, Arayüzün Kararı

Bir kullanıcı akışta kaydırırken haberi öğreniyorsa, o bilgiyi aramadı; arayüz onu getirdi. Pasif bilgi edinimi üzerine yazılan metinlerin çoğu bu noktada tuhaf bir yere sapıyor ve kullanıcıya kaynak doğrulamayı öğretmeye çalışıyor. Oysa başlığın kaç karakterde kesileceğine, kaynak adının görünüp görünmeyeceğine, bildirimin ne zaman gideceğine karar veren biri var ve o kişi kullanıcı değil.

Bağlamsız başlık bir okuma hatası değil, bir kırpma kararı

Kartın iki satıra sığması bir doğa yasası değil. Birisi o kartı iki satır yaptı, birisi kaynak adını alt köşeye küçük puntoyla koydu, birisi tarihi tamamen çıkardı çünkü tasarım daha temiz görünüyordu. Kullanıcının eksik bağlamla karar vermesi bu kararların toplamı.

Peki aynı alanda başka ne gösterilebilirdi? Genelde üç aday var: içeriğin kaynağı, yayın tarihi ve içeriğin sponsorlu olup olmadığı. Üçü de yer kaplar, üçü de tıklama oranını bir miktar düşürür, çünkü merak boşluğunu kapatırlar. Sorunun tasarım tarafındaki gerçek hali de bu zaten, bilgi eksikliği değil: bağlamı göstermek kısa vadeli metriğe zarar veriyor ve kimse bunu açıkça yazmıyor.

Merak boşluğuyla yazılmış bir başlık teknik olarak yalan söylemez, ama okuyanda oluşan izlenim ile metnin içeriği arasındaki farkı ölçen bir metrik de yoktur. Bu farkı ölçmek isteyen ekipler için basit bir yöntem var: kartı gösterip içeriği göstermeden kullanıcıya ne anladığını sordurmak. Beş kişiyle yapılan böyle bir tur, çoğu A/B testinden daha çabuk sonuç verir.

Bildirim bütçesi tek bir uygulamanın elinde değil

Her ekip kendi bildirimini kendi içeriğine göre değerlendirir. Sipariş durumu değişti, bu önemli. Takip edilen kişi paylaşım yaptı, bu da ilgili. Karar hep tek uygulamanın içinde, kendi alaka eşiğine göre verilir.

Kullanıcı ise tek bir kilit ekranına bakıyor. Kırk uygulamanın her biri kendi ölçüsünde haklı olarak "sadece önemli olanı gönderiyorum" dediğinde, toplamda ortaya çıkan şey kimsenin tasarlamadığı bir yığın oluyor. Ürün ekibinin göremediği kısım da burası, çünkü kendi bildirimini kendi ekranında test ediyor, kullanıcının kilit ekranında değil.

Ya bu bütçe açıkça kabul edilseydi? Pratikte işe yarayan yaklaşım, kanalı sınıflandırmak: durum değişikliği (sipariş kargoya verildi, sunucu düştü, ödeme başarısız) anlık bildirime aittir, çünkü kullanıcının zaten bekleyen bir işi vardır. Keşif ve içerik önerisi ise buna ait değildir, kullanıcı uygulamayı açtığında oradadır. Bu ayrımı yapmayan ürünlerde iki kategori aynı kanalda yarışır ve kaybeden her zaman ilki olur, çünkü sayıca azdır.

Ölçüm yanlış tarafta duruyor

Bir bildirim akışının başarısını açılma oranıyla ölçmem, çünkü o sayı yalnızca kazancı görür.

Maliyet başka tabloda birikir: kaç kullanıcı bildirimleri tamamen kapattı, kaç kişi izni geri çekti, uygulamayı silenlerin son haftada kaç bildirim aldığı. Bu veriler genellikle vardır, ama farklı bir panelde, çoğu zaman farklı bir ekibin panelinde durur ve bildirim kampanyasının sonucuyla aynı ekranda birleştirilmez. Birleştirilmediği sürece her kampanya başarılı görünür, toplam kanal ise sessizce erir.

Bildirim izni kapatan kullanıcı geri dönmüyor, bu yüzden kaybı bir kerelik değil kalıcı bir gelir kaybı olarak yazmak daha doğru. Bunu hesaba katan bir ekip, gönderilecek bildirim sayısını kendiliğinden azaltıyor.

Kullanıcı gerçekten kaçırmak istemediğinde

Pasif edinim baştan sorunlu bir şey değil. Kargonun yola çıktığını öğrenmek için kimse uygulama açmak istemez, sistem çöktüğünde bunu kullanıcıdan önce duymak isteyen bir ekip vardır ve son ödeme tarihi yaklaşan kişi hatırlatılmaktan memnun olur. Bunların ortak noktası şu: bilgi, kullanıcının zaten içinde olduğu bir sürecin durumunu söylüyor.

Ayrım da tam burada. Kullanıcının başlattığı bir sürecin durumu değiştiğinde onu bulmak doğru, kullanıcının haberi olmadığı bir içeriği ona itmek ise dikkatinden borç almak demek. İkisi aynı teknik altyapıyı kullanır, ikisi aynı ekranda görünür, ama biri kullanıcının işini bitirir, diğeri ona yeni bir iş açar.