Praktik catatan rilis

Template email update produk yang dibaca orang

5 menit baca diperbarui

Email update produk yang dibaca adalah yang dikirim ke seseorang yang meminta persis apa yang diumumkannya. Segalanya bersaing dengan sisa kotak masuk soal seberapa menarik, kompetisi yang kalah dari pengumuman rilis di kebanyakan minggu. Fakta tunggal ini seharusnya menentukan bentuk email sebelum kata apa pun dirumuskan: siapa yang menerimanya, dan apa yang dilakukan orang itu hingga masuk daftar.

Apa itu email update produk?

Ini adalah pesan yang memberi tahu pengguna yang ada tentang apa yang berubah pada produk yang sudah mereka gunakan. Ada empat jenis berbeda, dan memperlakukannya sebagai satu daftar adalah alasan mengapa tingkat buka menurun. Masing-masing punya pemicu berbeda, audiens berbeda, dan frekuensi yang bisa diterima berbeda.

JenisPemicuAudiensFrekuensi
Notifikasi bertargetPermintaan spesifik seseorang dirilisSatu orangSetiap kali terjadi
Pemberitahuan breaking changePerubahan yang membebani pekerjaan pembacaHanya akun terdampakSetiap kali terjadi
DigestBerlalunya waktuPengguna opt-inMaksimal bulanan
Pengumuman peluncuranPeluncuran yang layak menginterupsiSegmen atau semuaJarang, dan harus terasa jarang

Kebanyakan tim hanya membangun yang ketiga, mengirim ke semua orang, lalu menyimpulkan bahwa email update produk tidak berhasil. Dua yang pertama membawa hampir seluruh nilainya, karena pembaca punya alasan sebelumnya untuk peduli, dan pesan tiba selagi alasan itu masih hidup.

Keempat baris di sini semuanya ditulis untuk pelanggan. Sales, support, dan customer success juga perlu tahu apa yang dirilis, biasanya dalam bentuk berbeda dari keempat ini; release notes internal membahas apa yang seharusnya dikatakan dokumen itu dan mengapa harus keluar sebelum catatan untuk pelanggan.

Email adalah salah satu dari beberapa kanal yang bisa dipakai pengumuman peluncuran, bukan satu-satunya. Cara mengumumkan fitur baru membahas yang lain, dan cara memilih di antaranya berdasarkan seberapa besar fitur itu sebenarnya.

Apa yang masuk template?

Enam blok, dalam urutan ini. Yang pertama biasanya yang paling sering hilang, dan itulah yang melakukan pekerjaan.

Subjek:  <apa yang berubah, dengan kata-kata pembaca>

1. Mengapa Anda menerima ini
   "Anda meminta ekspor CSV bulan Maret." atau
   "Integrasi Anda memanggil /v1/invoices, yang berubah 15 Januari."

2. Apa yang berubah
   Satu kalimat. Apa yang sekarang mungkin, atau apa yang sekarang
   rusak.

3. Apa yang harus Anda lakukan
   Sering "tidak ada". Katakan secara eksplisit, jangan biarkan
   tersirat.

4. Di mana melihatnya
   Tautan ke entri changelog, bukan ke homepage.

5. Kapan
   Tanggal rilis, atau sejak kapan berlaku.

6. Cara berhenti berlangganan
   Satu klik, dan langsung dihormati.

Blok 1 adalah perbedaan antara pesan dan siaran umum. Pembaca yang diberi tahu, di baris pertama, bahwa ini adalah penyelesaian dari sesuatu yang secara pribadi ia minta, akan membaca sisanya. Tanpa itu, blok 2 sampai 5 adalah newsletter, sebagus apa pun tulisannya.

Jaga keseluruhannya di bawah sekitar 150 kata. Email adalah penunjuk ke entri changelog, dan entrilah tempat detail berada. Email yang mereproduksi seluruh entri tidak memberi pembaca alasan untuk klik, dan tidak memberi Anda sinyal apakah ada yang peduli.

Subjek apa yang berhasil?

Sebutkan perubahannya, bukan rilisnya. “Ekspor CSV sudah live” mengalahkan “update September” karena yang pertama adalah fakta yang bisa dinilai pembaca dan yang kedua adalah wadah. Nomor versi di subjek berguna bagi pemanggil sebuah API dan noise bagi semua orang lain, alasan lain untuk memisahkan audiens.

Hindari mengklaim manfaat yang belum disetujui pembaca. “Laporan Anda sekarang lebih cepat” mengklaim sesuatu tentang pengalamannya; “Laporan di atas 10.000 baris sekarang dimuat dalam kurang dari satu detik” melaporkan perubahan dan membiarkan dia memutuskan apakah itu penting.

Kapan mengirimnya, dan kepada siapa?

Kirim notifikasi bertarget pada saat hal itu dirilis, kepada orang-orang yang memintanya, secara individual. Kirim pemberitahuan breaking change segera setelah tanggal pasti dan sekali lagi mendekati tanggal itu, kepada akun yang benar-benar terdampak alih-alih seluruh daftar. Kirim digest hanya jika Anda punya cukup perubahan hingga pembaca akan melewatkan sesuatu jika tidak, dan biarkan orang mendaftar secara terpisah.

Daftar yang hampir tidak pernah sebaiknya Anda gunakan adalah “semua pengguna”. Itu mengubah pesan spesifik menjadi generik, dan melatih orang berhenti berlangganan. Segmentasikan berdasarkan perilaku yang sudah Anda simpan: siapa yang memintanya, siapa yang menggunakan endpoint ini, siapa yang ada di paket ini.

Apakah butuh persetujuan untuk mengirimnya?

Bagi pelanggan yang ada, update tentang layanan yang mereka gunakan biasanya adalah pertanyaan hukum yang berbeda dari marketing ke calon pelanggan, dan jawabannya tergantung di mana mereka berada dan apa yang Anda katakan saat pendaftaran. Di UE, pertanyaan relevannya adalah dasar hukum mana dari Pasal 6 GDPR yang berlaku, dan di Amerika Serikat pesan komersial membawa persyaratan spesifik yang ditetapkan dalam panduan kepatuhan CAN-SPAM FTC. Keduanya menuntut hal yang sama dalam praktik: katakan siapa Anda, perjelas tujuannya, dan biarkan orang bisa berhenti.

Apa pun dasarnya, jaga aliran transaksional dan marketing tetap terpisah di tingkat pengiriman. Pemberitahuan breaking change yang berhenti dilanggan pelanggan karena berbagi daftar dengan digest promosi adalah insiden support yang menunggu tanggalnya.

Seperti apa jika diisi?

Notifikasi bertarget, email update produk paling berharga dan yang paling jarang dibangun tim:

Subjek: Ekspor CSV sudah live

Hai Dana,

kamu meminta ekspor CSV bulan Maret.

Sudah live pagi ini. Laporan sekarang punya tombol Ekspor
yang menghasilkan CSV dari tampilan saat ini, termasuk
filter.

Tidak ada yang perlu kamu lakukan. Sudah aktif di akunmu.

  Detail: example.com/changelog#csv-export
  Dirilis: 2 September 2026

Kamu menerima ini karena memintanya. Berhenti berlangganan
update permintaan: <tautan>

Sembilan puluh kata, dan pembaca tahu di baris pertama mengapa ini datang. Bandingkan dengan perubahan yang sama dalam digest bulanan, di mana ia muncul sebagai satu dari sembilan poin dan Dana tidak punya alasan menyadari permintaannya sendiri sudah keluar.

Apa yang harus diukur?

Bukan hanya tingkat buka. Untuk notifikasi bertarget, pertanyaannya adalah apakah orang yang meminta kembali dan menggunakan hal itu, jadi angka yang perlu diamati adalah klik ke entri dan apakah akun itu menggunakan fitur dalam seminggu. Untuk pemberitahuan breaking change, itu cakupan: berapa persen akun terdampak yang membuka sebelum tanggal, dan dengan siapa Anda menindaklanjuti secara individual.

Digest adalah satu-satunya dari keempatnya di mana tingkat buka berarti banyak, dan bahkan di sana lebih berguna sebagai tren terhadap riwayatnya sendiri daripada terhadap benchmark industri. Jenis email update produk yang berbeda punya tugas yang berbeda, jadi angka yang dirata-rata di semuanya tidak menggambarkan apa pun yang bisa ditindaklanjuti.

Apa bedanya dengan release notes?

Release notes adalah dokumen yang tetap tersedia. Email adalah mekanisme pengiriman yang terjadi sekali. Perubahan yang sama menghasilkan keduanya, dan email sebaiknya lebih pendek daripada entri yang ditunjuknya. Praktik terbaik release notes membahas dokumennya, dan changelog vs release notes membahas yang mana yang sedang Anda tulis.

Hubungan yang layak dibenarkan: entri changelog adalah teks kanonik dan email mengutipnya. Ketika keduanya menyimpang, pembaca yang klik menemukan deskripsi berbeda tentang perubahan itu dan berhenti mempercayai keduanya. Menerbitkan entri lebih dulu dan menghasilkan email darinya menghilangkan penyimpangan itu secara konstruksi. changeloop bekerja dengan cara yang sama di sisinya: entri ditinjau sekali dan diterbitkan di halaman, feed, dan widget, dan orang yang memintanya melalui widget diberi tahu di issue GitHub yang berasal dari masukannya, dan di widget itu sendiri. changeloop tidak mengirim email; alat email Anda mengutip entri yang diterbitkan.

FAQ

Seberapa sering email update produk sebaiknya keluar? Sesering ada sesuatu yang spesifik yang ingin diketahui penerima, yang untuk notifikasi bertarget berarti setiap kali permintaannya dirilis, dan untuk digest maksimal bulanan.

Haruskah email berisi seluruh entri changelog? Tidak. Satu kalimat dan satu tautan. Entri adalah versi kanonik, dan salinan lengkap di email berarti dua teks yang harus dijaga tetap selaras.

Tingkat buka berapa yang harus saya harapkan? Bandingkan setiap jenis dengan dirinya sendiri, bukan dengan benchmark. Notifikasi bertarget dan digest bulanan adalah produk yang berbeda, dan merata-ratakannya menyembunyikan satu-satunya angka yang layak diamati.

Apakah saya perlu daftar terpisah untuk breaking change? Ya, dan itu sebaiknya daftar yang orang tidak bisa berhenti berlangganan begitu saja tanpa memahami konsekuensinya, karena itulah daftar yang membuat mereka kehilangan layanan.


Klaim teknis dalam artikel ini belum ditinjau secara independen. Jika ada yang keliru, beri tahu kami dan kami akan memperbaikinya.

Terkait di changeloop: Contoh changelog, Dokumentasi developer

changeloop
Tim di balik changelog yang menutup lingkaran. Pengguna meminta sesuatu, timmu mengirimkannya, yang meminta jadi tahu.