Okunan ürün güncellemesi e-posta şablonu

Okunan ürün güncellemesi e-postası, tam olarak duyurduğu şeyi talep eden birine gönderilmiş olandır. Gerisi, gelen kutusunun kalanıyla ilginçlik açısından rekabet eder, çoğu hafta bir release duyurusunun kaybettiği bir rekabet. Bu tek gerçek, herhangi bir ifadeden önce e-postanın şeklini belirlemelidir: onu kim alıyor, ve o kişi listeye girmek için ne yaptı.

Ürün güncellemesi e-postası nedir?

Mevcut kullanıcılara zaten kullandıkları bir üründe neyin değiştiğini söyleyen bir mesajdır. Dört ayrı türü vardır, ve onları tek bir liste olarak ele almak, açılma oranlarının düşmesinin nedenidir. Her birinin farklı bir tetikleyicisi, farklı bir kitlesi ve farklı bir kabul edilebilir sıklığı vardır.

Çoğu ekip sadece üçüncüsünü kurar, herkese gönderir, ve ürün güncellemesi e-postalarının işe yaramadığı sonucuna varır. İlk ikisi neredeyse tüm değeri taşır, çünkü okuyucunun önceden bir ilgilenme nedeni vardır, ve mesaj o neden canlıyken gelir.

Buradaki dört satırın hepsi müşteriler için yazılmıştır. Satış, destek ve customer success de neyin gönderildiğini bilmeli, genelde bu dördünden farklı bir biçimde; dahili release notları bu belgenin ne söylemesi gerektiğini ve müşteriye yönelik notdan önce neden çıkması gerektiğini ele alır.

E-posta, bir lansman duyurusunun kullanabileceği birkaç kanaldan yalnızca biridir. Yeni bir özellik nasıl duyurulur diğerlerini ve özelliğin gerçek büyüklüğüne göre aralarında nasıl seçim yapılacağını ele alır.

Şablona ne girer?

Bu sırayla altı blok. İlki genellikle eksik olan ve işi yapan bloktur.

Konu:  <ne değişti, okuyucunun kelimeleriyle>

1. Bunu neden alıyorsunuz
   "Mart'ta CSV dışa aktarma istediniz." veya
   "Entegrasyonunuz 15 Ocak'ta değişecek olan /v1/invoices'ı çağırıyor."

2. Ne değişti
   Bir cümle. Artık ne mümkün, veya artık ne bozuluyor.

3. Ne yapmanız gerekiyor
   Genellikle "hiçbir şey". Bunu üstü kapalı bırakmak yerine açıkça
   söyleyin.

4. Nerede görülür
   Ana sayfaya değil, changelog kaydına bir bağlantı.

5. Ne zaman
   Yayınlandığı tarih, veya ne zamandan beri geçerli olduğu.

6. Nasıl abonelikten çıkılır
   Bir tık, ve hemen saygı gösterilen.

Blok 1, bir mesaj ile genel bir yayın arasındaki farktır. İlk satırda, bunun kişisel olarak talep ettiği bir şeyin çözümü olduğu söylenen bir okuyucu gerisini okur. Onsuz, 2’den 5’e kadar olan bloklar ne kadar iyi yazılmış olursa olsun bir bültendir.

Bütünü yaklaşık 150 kelimenin altında tutun. E-posta, changelog kaydına bir işaretçidir, ve detayın ait olduğu yer kayıttır. Kaydın tamamını yeniden üreten bir e-posta, okuyucuya tıklamak için bir sebep vermez, size de kimseyi ilgilendirip ilgilendirmediğine dair bir sinyal vermez.

Hangi konu satırları işe yarar?

Değişikliği isimlendirin, release’i değil. “CSV dışa aktarma yayında” “Eylül güncellemesi”ni yener, çünkü ilki okuyucunun değerlendirebileceği bir gerçek, ikincisi ise bir kapsayıcıdır. Konu satırındaki sürüm numaraları bir API’nin çağıranları için yararlıdır ve herkes için gürültüdür, bu da kitleleri ayırmak için başka bir sebeptir.

Okuyucunun onay vermediği bir fayda iddia etmekten kaçının. “Raporlarınız artık daha hızlı” onun deneyimi hakkında bir şey iddia eder; “10.000 satırın üzerindeki raporlar artık bir saniyeden az sürede yükleniyor” bir değişikliği bildirir ve önemli olup olmadığına karar vermesini ona bırakır.

Ne zaman ve kime gönderilmeli?

Hedeflenmiş bir bildirimi şey yayınlandığı anda, isteyen kişilere, ayrı ayrı gönderin. Bir breaking change bildirimini tarih kesinleşir kesinleşmez ve ona yakın bir kez daha, tüm listeye değil gerçekten etkilenen hesaplara gönderin. Bir özeti sadece bir okuyucunun aksi halde bir şeyi kaçıracağı kadar değişikliğiniz varsa gönderin, ve insanların ayrı ayrı kaydolmasına izin verin.

Neredeyse hiç kullanmamanız gereken liste “tüm kullanıcılar”dır. Belirli bir mesajı genel bir mesaja dönüştürür, ve abonelikten çıkmayı öğretir. Zaten depoladığınız davranışa göre segmentleyin: kim istedi, kim bu endpoint’i kullanıyor, kim bu planda.

Göndermek için onay gerekli mi?

Mevcut müşteriler için, kullandıkları bir hizmetle ilgili bir güncelleme genellikle bir potansiyel müşteriye pazarlamadan farklı bir hukuki sorudur, ve cevap nerede olduklarına ve kayıt olurken onlara ne söylediğinize bağlıdır. AB’de ilgili soru GDPR’nin 6. maddesi kapsamında hangi yasal dayanağın geçerli olduğudur, ve ABD’de ticari mesajlar FTC’nin CAN-SPAM uyum kılavuzunda belirtilen özel gereksinimler taşır. İkisi de pratikte aynı şeyi ister: kim olduğunuzu söyleyin, amacı netleştirin, ve insanların durdurabilmesine izin verin.

Dayanak ne olursa olsun, işlemsel ve pazarlama akışlarını gönderim düzeyinde ayrı tutun. Bir müşterinin promosyonel bir özetle aynı listeyi paylaştığı için abonelikten çıktığı bir breaking change bildirimi, tarihini bekleyen bir destek olayıdır.

Doldurulmuş nasıl görünür?

Hedeflenmiş bildirim, en değerli ürün güncellemesi e-postası ve çoğu ekibin hiç kurmadığı:

Konu: CSV dışa aktarma yayında

Merhaba Dana,

Mart'ta CSV dışa aktarma istemiştin.

Bu sabah yayına girdi. Raporların artık mevcut görünümün CSV'sini
üreten bir Dışa Aktar düğmesi var, filtreler dahil.

Senin tarafında yapman gereken bir şey yok. Hesabında zaten açık.

  Detaylar: example.com/changelog#csv-export
  Yayınlandı: 2 Eylül 2026

Bunu talep ettiğin için alıyorsun. Talep güncellemelerinden çık:
<bağlantı>

Doksan kelime, ve okuyucu ilk satırda bunun neden geldiğini biliyor. Bunu, dokuz maddeden biri olarak göründüğü ve Dana’nın kendi talebinin gittiğini fark etmesi için hiçbir sebebi olmadığı aylık bir özetteki aynı değişiklikle karşılaştırın.

Ne ölçülmeli?

Sadece açılma oranı değil. Hedeflenmiş bir bildirim için soru, talep eden kişinin geri gelip şeyi kullanıp kullanmadığıdır, dolayısıyla izlenmesi gereken sayı, kayda tıklama ve o hesabın özelliği bir hafta içinde kullanıp kullanmadığıdır. Bir breaking change bildirimi için bu kapsamdır: etkilenen hesapların yüzde kaçı tarihten önce açtı, ve kiminle bireysel takip yaptınız.

Bir özet, dördü arasında açılma oranının bir şey ifade ettiği tek türdür, ve orada bile bir sektör kıyaslamasına karşı olmaktan çok kendi geçmişine karşı bir eğilim olarak daha kullanışlıdır. Farklı ürün güncellemesi e-postası türlerinin farklı işleri vardır, dolayısıyla hepsi üzerinden ortalanmış bir rakam, üzerinde hareket edilebilecek hiçbir şeyi tanımlamaz.

Sürüm notlarından nasıl farklı?

Sürüm notları erişilebilir kalan bir belgedir. E-posta bir kez gerçekleşen bir teslimat mekanizmasıdır. Aynı değişiklik ikisini de üretir, ve e-posta işaret ettiği kayıttan daha kısa olmalıdır. Sürüm notları en iyi uygulamalar belgeyi kapsar, ve changelog vs sürüm notları hangisini yazdığınızı kapsar.

Doğru kurulması gereken ilişki şu: changelog kaydı kanonik metindir ve e-posta onu alıntılar. Bu ikisi ayrıştığında, tıklayan okuyucu değişikliğin farklı bir tanımını bulur ve ikisine de güvenmeyi bırakır. Önce kaydı yayınlamak ve e-postayı ondan üretmek sapmayı yapı gereği ortadan kaldırır. changeloop da kendi tarafında aynı şekilde çalışır: bir kayıt bir kez gözden geçirilir ve sayfa, akış ve widget üzerinde yayınlanır, ve onu widget aracılığıyla isteyen kişi, geri bildiriminin dönüştüğü GitHub issue’sunda ve widget’ın kendisinde bilgilendirilir. changeloop e-postayı göndermez; e-posta aracınız yayınlanan kaydı alıntılar.

FAQ

Bir ürün güncellemesi e-postası ne sıklıkla çıkmalı? Alıcının bilmek istediği belirli bir şey olduğu kadar sık, ki bu hedeflenmiş bir bildirim için talebi yayınlandığında her seferinde, bir özet için en fazla aylık demektir.

E-posta changelog kaydının tamamını içermeli mi? Hayır. Bir cümle ve bir bağlantı. Kayıt kanonik versiyondur, ve e-postadaki tam bir kopya, uyumlu tutulması gereken iki metin anlamına gelir.

Ne açılma oranı beklemeliyim? Her türü bir kıyaslamaya karşı değil kendisine karşı karşılaştırın. Hedeflenmiş bir bildirim ve aylık bir özet farklı ürünlerdir, ve onları ortalamak üzerinde hareket edilmeye değer tek rakamı gizler.

Breaking change’ler için ayrı bir liste gerekli mi? Evet, ve insanların sonucunu anlamadan gelişigüzel abonelikten çıkamayacağı liste bu olmalı, çünkü onlara bir kesintiye mal olan liste budur.

Bu yazıdaki teknik iddialar bağımsız olarak kontrol edilmedi. Yanlış bir şey varsa bize söyle, düzeltelim.

changeloop'ta ilgili sayfalar: Changelog örnekleri, Geliştirici dokümantasyonu