Email Bülteni: Konu Satırının Çift Görevi ve Şablon Kararları

Bülten tasarımında bütün emek gövdeye gider, oysa okuyucunun gördüğü ilk ve çoğu zaman tek şey konu satırıdır. Üstelik o satır iki ayrı iş yapmak zorunda: bugün açtırmak ve altı ay sonra aratıldığında bulunmak. Bu ikisi aynı anda iyi yapılamaz, bir tercih gerekir.

Konu satırı iki işi birden yapıyor

Bir bülten gönderdiğinizde konu satırı önce gelen kutusunda bir tarama listesinde yer alır. Kullanıcı listeyi okumaz, gözden geçirir. Eyetracking çalışmalarının tekrar tekrar gösterdiği şey şu: dikkat başlığın ilk birkaç kelimesinde yoğunlaşır, gerisi çevresel görüşte kalır. Yani "Nisan ayı bültenimizde sizin için derlediklerimiz" yazan bir satırın ilk yarısı hiçbir şey söylemez.

İkinci iş daha sonra başlar. Kullanıcı o bülteni silmez, arşivler. Aylar sonra "hani şu fiyatlandırma yazısı vardı" diye posta kutusunda arama yapar. O aramada eşleşecek olan şey yine konu satırıdır.

İşte çakışma burada. Açılma oranı için benzersiz, merak uyandıran, her seferinde farklı bir satır istersiniz. Arşivde bulunabilirlik içinse tam tersi gerekir: tahmin edilebilir kelimeler, sabit bir ön ek, konunun adının açıkça geçmesi. Bültenin gelen kutusunda değil de arşivde yaşayacağını düşünüyorsanız (teknik içerik, dokümantasyon, sürüm notları) ikinci tarafı seçin. Kampanya bülteninde birinci taraf kazanır.

Abonelik ve çıkış akışı

Abone olma formunda hâlâ karşılaşılan bir soru var: "HTML mi, düz metin mi?" Bu, kullanıcıya değil sisteme ait bir sorudur. Karşılığı olan tercih "resimli mi, sade mi" olabilir, o da çoğu durumda sorulmaya değmez.

Asıl sorulması gereken şey sıklık. Haftada bir mi, ayda bir mi, sadece önemli bir şey olduğunda mı. Bunu abonelik anında söylemek, sonradan gelen "bu kadar sık gelecek demediniz" tepkisini baştan kesiyor.

Konu satırında isimle hitap etmekle, gönderim sıklığını abonelik anında net yazmak arasında seçmek gerekirse ikincisini daha güvenilir bulurum. İsimle hitap tek seferlik bir açılma getirir ve artık kimseyi şaşırtmıyor; sıklık beyanı listede kalma süresini uzatır, etkisi de her gönderimde tekrarlanır.

Çıkış bağlantısını gizlemenin bir bedeli var: kullanıcı bulamadığı çıkışın yerine spam düğmesini kullanır, o da gönderen itibarınıza yazılır. Tek tıkla çıkış, kaybedilen aboneden daha ucuza gelir.

Şablonun uygulama maliyeti

"Responsive olsun" demek e-postada web'dekiyle aynı şey değil. Tarayıcıda grid kurup bitirdiğiniz düzeni, e-posta istemcilerinde tablo yapısı ve satır içi CSS ile kurmanız gerekir, üstelik bazı istemciler media query'yi hiç uygulamaz.

Bu yüzden baştan tek sütuna göre tasarlanmış bir şablonu, iki sütunlu düzeni her istemcide çalıştırmaya uğraşmaktan daha güvenilir bulurum. Tek sütun media query desteklenmediğinde de bozulmaz, çünkü zaten dar. İki sütunlu düzen ise desteklenmediği her yerde yan yana sıkışmış iki okunmaz blok üretir ve bunu ancak gerçek istemcilerde test ederek görürsünüz. Tasarımın maliyeti çizimde değil, o test matrisinde birikiyor.

Sık yapılan hatalar

• Uzun giriş paragrafı. Kullanıcı bülteni açtığında aradığı şey "merhaba, bu ay yine yoğun bir dönem geçirdik" değil.
• Ana fikrin ortalarda bir yerde geçmesi. Gövdenin ilk ekranında olması gerekir.
• Arşiv sayfası olmaması. Bültenin web'de sabit bir adresi yoksa, paylaşılamaz ve arama motorundan da bulunamaz.

Son madde çoğu ekibin atladığı yer. Posta kutusundaki arşivi siz yönetemezsiniz, kullanıcının istemcisi yönetir. Sitedeki arşivi yönetirsiniz. Bülten içeriğini aynı zamanda bir sayfa olarak yayınlamak, konu satırındaki o ikinci işin yükünü de hafifletiyor: aramayı gelen kutusu bulamazsa, Google buluyor.