Penyedia mungkin menerima volume bulanan Anda tetapi membatasi lonjakan setelah gangguan checkout. Bandingkan kontrak pengiriman dengan pekerjaan yang harus dipulihkan aplikasi Anda.
Apa itu email transaksional?
Email transaksional melayani transaksi atau aktivitas akun penerima, seperti tanda terima atau reset kata sandi. Tujuan pesan menentukan kategorinya. Jumlah penerima dan pemicu otomatis tidak menjadikan konten promosi sebagai transaksional.
Apa yang harus Anda evaluasi?
Bandingkan kemampuan yang dibutuhkan aplikasi Anda, lalu uji jalur kegagalan sebelum berkomitmen.
- Deliverability dan perangkat reputasi. Bisakah Anda mengautentikasi domain dengan SPF, DKIM, dan DMARC dengan mudah? Apakah IP khusus tersedia jika Anda membutuhkannya, beserta panduan pemanasannya?
- Kualitas API dan SDK. Apakah API terdokumentasi dengan baik, dengan SDK resmi dalam bahasa yang Anda gunakan?
- SMTP dan HTTP keduanya. Periksa antarmuka pengiriman mana yang didukung runtime Anda. Klien SMTP yang sudah ada dapat menggunakan relay; HTTP API melayani aplikasi yang mengirimkan permintaan terstruktur.
- Template. Template sisi server dengan substitusi variabel memungkinkan Anda mengubah teks tanpa deploy dan menjaga format tetap konsisten di seluruh pesan.
- Webhook dan event. Event webhook secara real-time untuk pengiriman, buka, klik, bounce, dan keluhan adalah cara Anda menjaga catatan tetap akurat dan memicu logika tindak lanjut.
- Analitik. Tampilan agregat tingkat pengiriman, bounce, dan keterlibatan, ditambah log yang dapat dicari untuk menyelidiki pesan individual.
- Penanganan supresi. Penyedia harus secara otomatis menekan hard bounce dan keluhan agar aplikasi Anda dapat menghentikan pengiriman yang diblokir oleh sinyal tersebut. Tanyakan bagaimana daftar supresi dikelola dan apakah Anda dapat memeriksanya.
- Skalabilitas. Bisakah layanan menangani volume puncak Anda (peluncuran produk, lonjakan hari libur) tanpa intervensi manual atau throttling mendadak?
- Harga. Pahami modelnya (per pesan, bertingkat, volume termasuk) dan di mana biaya kelebihan berlaku. Hitung untuk volume yang Anda harapkan dan periode puncak.
- Dukungan. Saat email berhenti mengalir pukul 2 pagi, bagaimana Anda menghubungi seseorang, dan seberapa cepat mereka merespons? Periksa tier dukungan yang disertakan dalam paket yang benar-benar akan Anda beli.
- Kepatuhan. Pastikan penyedia memenuhi persyaratan penanganan data dan regional yang berlaku bagi bisnis Anda sebelum Anda berkomitmen.
Kapan sebaiknya Anda memilih layanan relay SMTP?
Pilih relay SMTP jika aplikasi Anda sudah membangun pesan email dan mendukung mail server yang dapat dikonfigurasi. Pilih HTTP API jika Anda memerlukan field permintaan terstruktur atau template tersimpan.
Untuk Bird, bandingkan jalur pengiriman dan pemulihan sebelum memilih antarmuka:
| Keputusan atau kegagalan | Relay SMTP | HTTP email API |
|---|---|---|
| Autentikasi | Username bird, kunci API sebagai password, dengan scope emails. Gunakan TLS pada host SMTP regional. | Kunci API di header Authorization: Bearer, dengan scope emails. |
| Balasan pengiriman | 250 terakhir membawa ID pesan yang di-queue. Simpan bersama event aplikasi. | 202 membawa ID pesan yang diterima. Simpan bersama event aplikasi. |
| Tanggung jawab retry | Aplikasi Anda atau klien SMTP menangani retry pengiriman. Gunakan kembali X-Bird-Idempotency-Key untuk pesan logis yang sama. | Aplikasi Anda atau SDK menangani retry pengiriman. Gunakan kembali Idempotency-Key untuk pesan logis yang sama. |
| Kedaluwarsa | Sebelum mencoba ulang pekerjaan yang belum terkirim, aplikasi Anda memeriksa apakah tautan atau kodenya masih valid. | Terapkan pemeriksaan yang sama sebelum mengirimkan permintaan lain. |
| Asumsi throughput | Periksa batas koneksi bersamaan secara terpisah dari kuota pengiriman. Koneksi terbuka yang lebih banyak tidak menetapkan jatah laju pengiriman. | Atur kecepatan permintaan API menggunakan header rate-limit dari respons. Laju permintaan dan volume penerima adalah kuantitas yang berbeda. |
| Bukti event | Ikuti event penerima setelah balasan queue. Bird mencoba ulang pengiriman yang ditangguhkan. | Ikuti event penerima yang sama setelah penerimaan. Bird mencoba ulang pengiriman yang ditangguhkan. |
| Pemilihan pool | Konfigurasi SMTP dari kunci API memilih pool. Kunci yang tidak dikonfigurasi menggunakan pool default organisasi. | Atur ip_pool_id per pengiriman, atau gunakan pool default organisasi. |
Panduan relay SMTP menyediakan pengaturan koneksi dan penanganan balasan. Referensi pengiriman HTTP mendefinisikan permintaan dan respons API. Kedua antarmuka menggunakan pipeline email yang sama, termasuk penanganan supresi dan penandatanganan.
Penerimaan transport berarti Bird telah meng-queue pesan. Event email.delivered berikutnya berarti server penerima menerimanya. Keduanya tidak menetapkan penempatan inbox atau pembacaan.
Simpan catatan pengiriman Anda sendiri melampaui jendela retensi idempotensi, karena retry selanjutnya dapat membuat pesan lain. Penangguhan sudah dicoba ulang oleh Bird; membuat pengiriman lain menduplikasi pekerjaan yang masih berjalan.
IP khusus bersifat opsional untuk kedua antarmuka. Periksa persyaratan pool dan pemanasan sebelum merutekan lonjakan melalui pool khusus.
Kemampuan terpublikasi mana yang harus Anda bandingkan?
Periksa antarmuka terdokumentasi di balik setiap fitur. Menerima email yang sudah di-parse, menyimpan kontennya, dan mengekspos API percakapan adalah kemampuan yang berbeda.
| Penyedia | Pengiriman | Bukti penerima | Infrastruktur penerimaan dan pengiriman |
|---|---|---|---|
| Bird | Pengiriman HTTP dan SMTP | Event, log pesan dan supresi | Kotak masuk dan thread; pool IP khusus |
| Amazon SES | SendEmail API dan SMTP | Destinasi event dan daftar supresi akun | Aturan penerimaan di region yang didukung; IP khusus standar atau terkelola |
| SendGrid | Mail Send API dan SMTP | Event Webhook dan Email Activity | Inbound Parse webhook; IP pools |
| Mailgun | Messages API dan SMTP | Event pengiriman dan catatan bounce | Rute untuk meneruskan atau menyimpan email; IP pools |
| Postmark | Email API dan SMTP | Webhooks dan supresi stream | Inbound webhook; kelayakan IP khusus |
| Resend | Email API dan SMTP | Event webhook dan log API | Konten dan balasan yang diterima; IP khusus terkelola |
Pastikan kelayakan dan retensi untuk paket yang akan Anda beli. Tautan fitur tidak menetapkan jatah throughput atau komitmen waktu pemulihan.
Untuk konten tersimpan, periksa body, header, lampiran, dan catatan event mana yang tetap dapat diambil. Untuk residensi, dapatkan cakupan penyimpanan dan pemrosesan terpublikasi, termasuk pengecualian. Endpoint regional saja tidak menetapkan kontrak tersebut.
Apa yang berubah pada sepuluh juta pengiriman per bulan?
Lalu lintas puncak dan kapasitas pemulihan menentukan laju pengiriman yang dibutuhkan. Volume bulanan saja tidak.
Dalam ilustrasi bulan 30 hari, sepuluh juta pesan satu penerima rata-rata sekitar 3,86 pesan per detik. Lonjakan 100.000 pesan dalam sepuluh menit membutuhkan sekitar 167 per detik. Evaluasi lonjakan secara terpisah dari jatah bulanan.
Setelah gangguan sepuluh menit pada 100 pesan baru per detik, aplikasi Anda memiliki 60.000 pekerjaan yang belum terkirim. Jika pekerjaan baru terus masuk pada 100 per detik, menguras antrean tersebut dalam dua puluh menit membutuhkan tambahan 50 per detik. Target pemulihan karena itu adalah 150 pesan diterima per detik, sebelum retry atau penundaan server penerima.
Periksa bagaimana setiap penyedia menghitung pekerjaan. Kuota SES menghitung penerima dan berlaku terpisah per region. Kuota ini mencakup kuota harian bergulir dan laju penerimaan. SES juga memperingatkan bahwa penerimaan aktual bisa di bawah laju maksimum akun.
Batas Resend membedakan laju permintaan API dari kuota volume email. Header rate-limit Bird melaporkan kuota permintaan efektif. Konversikan ukuran batch Anda menjadi permintaan sebelum membandingkannya dengan laju penerima skenario.
Bagaimana cara menguji pemulihan insiden?
Uji bagaimana aplikasi Anda melanjutkan setelah pengiriman gagal atau handler webhook-nya tidak tersedia. Halaman status penyedia menyediakan konteks insiden; catatan pesan Anda menetapkan pekerjaan mana yang tersisa.
| Penyedia | Batas terpublikasi atau kontrak error | Status resmi |
|---|---|---|
| Bird | Kuota efektif dan header retry | Status Bird |
| Amazon SES | Kuota pengiriman | Kesehatan layanan AWS |
| SendGrid | Rate limit API | Status SendGrid |
| Mailgun | Kontrak error dan rate-limit API | Status Mailgun |
| Postmark | Kontrak respons dan error API | Status Postmark |
| Resend | Batas penggunaan | Status Resend |
Jeda worker pengujian, kumpulkan pekerjaan, dan lanjutkan dalam batas efektif akun. Ukur berapa lama pekerjaan tertua yang memenuhi syarat menunggu. Pekerjaan reset yang kedaluwarsa memerlukan jalur permintaan baru alih-alih replay otomatis.
Pertahankan setiap identifier business-event selama pemulihan. Verifikasi kontrak pengiriman duplikat penyedia sebelum mencoba ulang pengiriman yang tidak pasti. Postmark mendokumentasikan tidak adanya fitur idempotency-key, sehingga integrasinya memerlukan pengamanan di sisi aplikasi. Retensi completed-response Bird adalah tiga jam. Pemulihan melampaui jendela tersebut memerlukan catatan event Anda sendiri.
Cocokkan event penerima berikutnya dengan ID pesan yang tersimpan. Penerimaan oleh server penerima tidak menetapkan penempatan inbox atau pembacaan. Siklus hidup API transaksional menjelaskan hasil-hasil terpisah ini.
Apa yang perlu masuk dalam perbandingan harga?
Bandingkan inklusi terpublikasi untuk paket, periode penagihan, dan mata uang yang tepat yang akan Anda beli. Pisahkan volume pengiriman dari infrastruktur dan retensi yang dibutuhkan.
| Sumber harga penyedia | Inklusi yang perlu diperiksa untuk beban kerja Anda |
|---|---|
| Harga Bird | Jatah pengiriman, kelebihan, infrastruktur khusus, konten tersimpan, dan dukungan |
| Harga Amazon SES | Penggunaan outbound dan inbound, biaya data, IP khusus, dan fitur opsional |
| Harga SendGrid | Volume paket, kelebihan, kelayakan IP khusus, retensi aktivitas, dan dukungan |
| Harga Mailgun | Volume pengiriman, retensi log dan pesan, IP khusus, dan dukungan |
| Harga Postmark | Jatah pengiriman, volume tambahan, opsi retensi, dan kelayakan IP khusus |
| Harga Resend | Jatah pengiriman dan penerimaan, kelebihan, retensi, dan kelayakan IP khusus |
Periksa apakah jatah yang dikutip menghitung permintaan, pesan, atau penerima. Catat fitur yang dikecualikan di samping paket, jangan asumsikan fitur tersebut termasuk. Perbandingan penyedia Bird memuat perbandingan produk terpisah.
Pertanyaan yang sering diajukan
Apa perbedaan antara email transaksional dan marketing?
Email transaksional melayani transaksi atau aktivitas akun. Email marketing mempromosikan sesuatu atau mengirimkan konten berlangganan. Tujuan pesan menentukan perbedaannya, termasuk ketika keduanya otomatis.
Bisakah satu penyedia menangani email transaksional dan marketing?
Satu penyedia dapat melayani kedua alur kerja. Periksa kebijakan kategori, identitas pengiriman terotentikasi, dan pemilihan pool IP secara terpisah. Infrastruktur bersama tetap dapat mengekspos email operasional pada masalah reputasi dari lalu lintas marketing.
Apakah saya memerlukan IP khusus?
Tidak di awal. Pool IP bersama cukup untuk volume rendah dan menghindarkan Anda dari pemanasan IP. IP khusus masuk akal setelah volume Anda cukup tinggi dan stabil untuk mempertahankan reputasinya sendiri. Pilih penyedia yang memungkinkan Anda memulai dengan IP bersama dan beralih ke khusus ketika angkanya membenarkan hal tersebut.
Di mana posisi Bird
Anda dapat mengirim melalui SMTP atau HTTP API. Publikasikan template untuk konten yang dapat digunakan ulang. Berlangganan event penerima. Periksa pesan individual di log email.
Pilih pool IP secara terpisah dari kategori pesan. Ikuti panduan pemanasan saat mengubah volume pengiriman. Gunakan checklist operasional untuk menguji penanganan duplikat dan pemulihan.
Bagaimana cara membuat pilihan akhir?
- Cocokkan antarmuka terdokumentasi dan kontrol penerima dengan aplikasi Anda.
- Konfirmasi kuota efektif untuk lalu lintas puncak dan pemulihan antrean.
- Uji penanganan kegagalan terhadap catatan pesan dan business-event yang tersimpan.
- Bandingkan inklusi terpublikasi, retensi, dan dukungan untuk paket yang akan Anda beli.