Olayla tetiklenen pazarlama ve işlemsel e-postaları; tetikleyici payload verileri, yayımlama ve gecikmeli uygunluk için pratik bir modelle tanıyın.
Tetiklenen bir e-posta, gerçekleşmiş bir şeyle başlar: bir kayıt, başarısız bir fatura ödemesi, tamamlanmış bir dışa aktarma ya da sisteminizin tanımlayabildiği başka bir olay. Bu olay, mesaja bağlam sağlar.
Mesajın pazarlama mı yoksa işlemsel mi olduğuna tetikleyici karar vermez; buna mesajın amacı ve alıcıyla olan ilişki karar verir. Bir makbuz ile bir plan yükseltme teklifi aynı üründen çıkabilir, ama yine de farklı gönderim kuralları gerektirir.
Bir eylemi ya da doğrulanmış bir durumu tanımlayan bir ad seçin. E-postanın ihtiyaç duyduğu alanları tanımlayın ve gerçeği yansıtan payload örnekleriyle test edin. Hangi servisin gönderdiğine göre farklı anlamlara gelen bir olaydan kaçının.
Örneğin tamamlanmış bir sipariş olayı alıcının adresini, sipariş referansını ve siparişe giden bir bağlantıyı taşıyabilir. Hassas ya da gereksiz verileri payload verisinin dışında tutun. Desteklenen istek yapılarını API referansı belgeliyor.
Brew içinde bir otomasyon, tetikleyiciyi e-posta gönderme gibi adımlara bağlar. Taslağı oluşturup gözden geçirin; üretim ortamındaki olayların otomasyonu çalıştırmasını beklemeden önce de otomasyonu yayımlayın. Kayıttan yeniden etkileşime kadar önce hangi yaşam döngüsü akışlarını kurmanız gerektiğini yapay zekâ ile e-posta otomasyonu yazımız ele alıyor.
Bir ürünü tanıtan hoş geldin serisi pazarlamadır. Bir sipariş makbuzu ya da talep edilmiş bir hesap güvenliği mesajı işlemsel olabilir. Karma mesajlar birincil amaç değerlendirmesi gerektirir; küçük bir tanıtım eklemek, hukuki soruyu ne bir yönde ne de öbür yönde kendiliğinden yanıtlar.
Temel hesap bilgilerini kolayca bulunabilir tutun. Alan adı için uygun gönderim amacını kullanın ve abonelik işleyişini test edin. Bu ayrım ve bağlantısı verilen sağlayıcı gereksinimleri için işlemsel e-posta rehberimizi okuyun.
Pazarlama e-postalarında izni doğrulayın; abonelikten çıkma ve gönderim engeli durumlarına uyun. Eşleşen bir olay, adresi payload verisinde geçen herkese e-posta göndermek için izin değildir.
Altı gün sonra kurulumu hâlâ tamamlamamış bir deneme kullanıcısına hatırlatma göndermek istediğinizi varsayalım. Kayıt olayı, yalnızca kayıt anında neyin doğru olduğunu bilir. Kullanıcının kurulumu yarın tamamlayıp tamamlamayacağını öngöremez.
Brew içinde altıncı gün kontrolü için bir Filtre ya da koşullu Dallanma düğümü, contact.<name> üzerinden Brew içindeki güncel kişi alanlarını okuyabilir. Aktivasyon ve abonelik alanlarını tanımlayıp senkronize edin, ardından beklemeden sonra bu alanları kontrol edin. payload.activated gibi olay alanları ise hâlâ orijinal olayın değerlerini içerir. Gerekli durum Brew dışında tutuluyorsa uygulamanızın bunu altıncı gün kontrol etmesini ve yalnızca kullanıcı hâlâ koşulları sağlıyorsa yeni bir hatırlatma olayı tetiklemesini sağlayın.
Koşul “satın almadı” ya da “hâlâ ücretsiz planda” olduğunda da aynı kural geçerlidir. Uygulama tarafındaki yaklaşımı deneme süresi serisi yazımız açıklıyor.
Olay isteğini, otomasyon çalıştırmasını ve gelen e-postayı test edin. Eksik alanları, yeniden denemeleri, kendi test alıcılarınızı ve sonraki bir gönderimi engellemesi gereken bir durum değişikliğini de teste dâhil edin.
Bağlı sağlayıcılar için onların gerçek olay adlarını kullanın. Stripe sayfası, Brew tarafından desteklenen olayları listeler ve “Ad ve soyadı senkronize et” ayarının bir otomasyonu yayımlamakla neden ilgisi olmadığını açıklar.
Yol çalışır hâle geldikten sonra seriyi anlaşılır tutun. Az sayıda net olay ve gözden geçirilmiş mesajdan oluşan bir yapıyı sürdürmek, koşullarını kimsenin açıklayamadığı uzun bir otomasyondan daha kolaydır.
