Bülten Deneyimi: Abonelik, Çıkış ve Şablonun Teknik Sınırları
Bülten, kullanıcının en dar alanına giren içerik türü. Gelen kutusunda bir bültenin rakibi başka bir bülten değil, kişinin o gün cevaplaması gereken işler. Bu yüzden bülten deneyiminde kırılma noktası abonelik formunda değil, çıkış akışında ve şablonun teknik davranışında.
Kişisel alanda tolerans düşüktür
Bir web sitesinde kullanıcı yanlış bir sayfaya düşerse geri tuşuna basar ve unutur. Aynı kullanıcı gelen kutusunda bozuk görünen, açılmayan veya iki kere gelen bir bültenle karşılaşırsa bunu markanın ihmali olarak okur. Aradaki fark, davetli olup olmamanız. Siteye kullanıcı gelir, bültene siz gidersiniz.
Pratik sonucu şu: bültende hata payınız sitedekinden düşüktür. Yanlış isimle başlayan bir selamlama ("Merhaba {{ad}}") ya da yerelleştirilmemiş bir tarih formatı, sitede fark edilmeyecek bir kusurken burada doğrudan özensizlik sinyali verir.
Çıkışı zorlaştırmak artık teknik olarak da işe yaramıyor
Abonelikten çıkmayı üç tıka yaymak, giriş yapmayı zorunlu kılmak, "gerçekten emin misiniz" ekranı koymak eski bir alışkanlık. Bu yöntemin bugün tek sonucu var: kullanıcı çıkış bağlantısını aramak yerine spam düğmesine basar. Spam şikayeti, listeden çıkmaktan çok daha pahalıdır, çünkü sadece o kişiyi değil gönderen itibarınızı etkiler.
2024 başından itibaren Gmail ve Yahoo, toplu gönderim yapanlardan RFC 8058 uyumlu tek tıkla çıkış desteği istiyor ve çıkış talebinin iki gün içinde işlenmesini şart koşuyor. Yani "zor çıkış" tasarımı artık bir tercih meselesi olmaktan çıktı. Bültenin başlıklarına List-Unsubscribe ve List-Unsubscribe-Post ekle, istemcinin kendi çıkış düğmesini göstermesine izin ver; gönderim aracın bunu kendi başına yapmıyorsa aracı değiştir.
Çıkış sayfasında tek yararlı ekleme, sıklık seçeneği. Haftada üç yerine ayda bir alabileceğini gören kullanıcıların bir kısmı listede kalır. Bunun dışındaki her ek adım, kaybettiğiniz aboneyi geri getirmez.
Bülten HTML'i, web HTML'i değildir
Bültenlerin farklı istemcilerde bozulmasının sebebi tasarımcının dikkatsizliği değil, e-posta istemcilerinin ortak bir render standardında buluşmamış olması. Windows üzerindeki Outlook masaüstü sürümleri HTML'i Word'ün motoruyla çizer. Flexbox yok, grid yok, modern kutu modeli garantisi yok. Gmail'in mobil uygulaması Google dışı hesaplarda <style> bloklarını atar, bu yüzden stil inline olmayan her şey kaybolur.
Bunun tasarıma yansıması sade: tek sütun düzen, 600 piksel civarı genişlik, düzeni taşıyan tablolar, satır içi CSS, gerçek metin olarak yazılmış başlıklar. Karanlık mod ayrı bir dert; bazı istemciler renkleri kendiliğinden ters çevirir, bu yüzden şeffaf arka planlı siyah PNG logolar siyah zeminde kaybolur. Logoyu çevresine beyaz bir dolgu bırakarak dışa aktar, sorun orada biter.
Test tarafında kısayol aramaya değmez. Kendi gelen kutunda güzel görünmesi hiçbir şey kanıtlamaz; en az Outlook masaüstü, Gmail web, Gmail mobil uygulaması ve Apple Mail üzerinde bak. Dört istemci, gerçek kitlenin büyük çoğunluğunu temsil eder.
İçerik: bülten tek bir iş yapsın
Bültenlerin çoğu, içine sığdırılan bağlantı sayısı yüzünden okunmuyor. Beş haber, üç duyuru ve bir kampanya bir arada gönderildiğinde kullanıcı hangisinin kendisini ilgilendirdiğini ayırmak için efor harcamak zorunda kalır, ve bu eforu harcamaz.
Konu satırı bültenin içeriğini söylesin, merak uyandırmaya çalışmasın. Merak uyandıran konu satırları ilk seferde açılma oranını yükseltir, üçüncü seferde kullanıcı kalıbı öğrenir ve açmayı bırakır. Gönderim sıklığı da aynı mantıkla: düzenli ve tahmin edilebilir bir ritim, sık gönderimden daha değerli.
Bültenin başarısını açılma oranıyla ölçmek ise artık güvenilir değil. Apple'ın Mail Privacy Protection özelliği izleme piksellerini kullanıcı adına önden yükler, dolayısıyla açılma verisi şişer. Tıklama ve tıklamadan sonra sitede tamamlanan işe bak; ölçmek istediğin şey zaten oydu.