# E-posta pazarlama otomasyonu: seriden önce durum kontrolü

Kanonik URL: https://brew.new/tr/blog/email-marketing-automation-guide
Yazar: Thomas Park
Yayımlandı: 2026-08-19
Güncellendi: 2026-09-29

Bir e-posta otomasyonu, bir mesajın ne zaman gönderileceğine dair tekrarlanabilir bir karardır. Editör bunun yalnızca bir parçası. Olay, müşterinin güncel durumu ve durdurma kuralları da en az metin kadar önemlidir.

Bir seriyi çizmeden önce her mesajın neden var olması gerektiğini ve gönderileceği ana kadar onu neyin uygunsuz hâle getirebileceğini yazın.

## Tetikleyiciyi ve verilerini tanımlayın

Bir kayıt, tamamlanmış bir satın alma, başarısız bir ödeme ya da üründe ulaşılan bir dönüm noktası bir otomasyonu başlatabilir. Olaya net bir anlam verin. “Kullanıcı aktif” belirsizdir; “ilk rapor dışa aktarıldı” ise uygulamanın kaydedip test edebileceği bir şeydir.

Yalnızca mesajın ihtiyaç duyduğu verileri, sabit tanımlayıcılarla ve gerektiğinde bir zaman damgasıyla birlikte ekleyin. Her değerin esas kaynağının hangi sistem olduğuna karar verin. Olay teslimi yeniden denenebilir; bu yüzden entegrasyonunuzun desteklediği, tekrarlanan isteklere karşı korumayı (idempotency) kullanın ve mükerrer teslimi test edin.

[Stripe entegrasyonu](/tr/browse/integrations/stripe), belgelenmiş abonelik ve ödeme olayları sağlar. Ürününüze özgü dönüm noktalarını ise özel uygulama olaylarıyla kapsayabilirsiniz.

## Beklemeyi uygunluk kontrolünden ayırın

Bir bekleme, sonraki adımın ne zaman çalışacağını değiştirir. Otomasyonun bildiği bilgileri ise tek başına güncellemez.

Brew içinde olayla tetiklenen bir akışta Filtre düğümleri ve koşullu Dallanma düğümleri, olay verilerini kişi verilerinden ayırır. `activated` ya da `payload.activated` orijinal olayı okur. `activated: false` diyen bir kayıt olayının payload verisi ertesi gün güncelliğini yitirmiş olabilir. `contact.activated` ise o koşul düğümü çalıştığı anda, bir Bekle adımından sonra da dâhil, alıcının Brew içindeki güncel kişi alanını okur.

Bir kurulum hatırlatması için evet/hayır türünde bir `activated` kişi alanı tanımlayın, bu alanı uygulamanızdan senkronize tutun ve beklemeden sonra bir `contact.activated equals false` filtresi koyun. Değerin hiç olmaması, yanlış (false) olmasıyla aynı şey değildir; bu yüzden ikisini de test edin. Bu duruma bağlı her sonraki hatırlatmanın önüne bir koşul koyun; bir kişi güncellemesi ya da yeni bir olay, daha önce başlamış bir çalıştırmayı otomatik olarak iptal etmez.

Kişi alanını okumak, ürününüzün veritabanını ya da faturalandırma sağlayıcınızı sorgulamaz. Uygunluk senkronize edilmeyen bir etkinliğe, belirli bir faturaya ya da sepetin güncel içeriğine bağlıysa bu kontrolü uygulamanızda planlayın. Zamanı geldiğinde esas kaydı okuyun ve yalnızca hatırlatma hâlâ anlamlıysa yeni bir uygunluk olayı tetikleyin.

İki yaklaşımı da [ürün olaylarıyla deneme süresi dönüşümü](/tr/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events) yazımız adım adım anlatıyor. Koşul alanlarının yollarını ise [otomasyon dokümantasyonu](https://docs.brew.new/create-emails/build-an-automation#check-state-before-later-reminders) açıklıyor.

## İşe yarar tek bir seriyle başlayın

Bir hoş geldin otomasyonu, kayıt sırasında vaat edilen kaynağı ya da bir sonraki adımı iletebilir. Bir ödeme bildirimi, gerçek bir faturalandırma olayını açıklayabilir. Üründe ulaşılan bir dönüm noktasıyla ilgili bir e-posta, kişinin az önce tamamladığı işin sonucunu kullanmasına yardımcı olabilir.

İlk sürümü gözden geçirilebilecek kadar küçük tutun. Her mesaj için hedef kitleyi, tetikleyiciyi, gerekli alanları, hedeflenen eylemi ve gönderimi engellemesi gereken koşulları kaydedin. Bu incelemeye abonelik durumunu ve gönderim engellerinin nasıl uygulandığını da dâhil edin.

Brew içinde neyin çalışacağını yayımlanmış otomasyonlar belirler. Bir taslak oluşturmak ya da düzenlemek, onu yayımlamakla aynı şey değildir. Entegrasyon ayarlarının ve otomasyon durumunun görevleri farklıdır; örneğin Stripe entegrasyonundaki **Ad ve soyadı senkronize et** ayarı ad güncellemelerini yönetir, olay otomasyonlarının çalışıp çalışmayacağını değil.

## Durum değişikliklerini test edin

Normal bir çalıştırmayı, eksik isteğe bağlı alanları, mükerrer bir olayı, pazarlama e-postalarından abonelikten çıkmış bir kişiyi ve hatırlatmanın zamanı gelmeden durumu değişen bir müşteriyi test edin. Kişi koşullarında, bekleme sırasında Brew alanını güncelleyin ve sonraki koşulun hatırlatmayı atladığını doğrulayın. Uygulamanın planladığı hatırlatmalarda, müşteri artık koşulları sağlamadığında uygulamanın yeni bir uygunluk olayı tetiklemediğini doğrulayın.

Çalıştırma kaydının yanında gerçek e-postayı da inceleyin. Bağlantıları, birleştirme etiketlerini, gönderim alan adını ve tam olarak hangi sürümün yayımlandığını kontrol edin. Başarılı bir tetikleme isteği, doğru mesajın doğru gelen kutusuna ulaştığını tek başına kanıtlamaz.

## Ürün değiştikçe otomasyonu gözden geçirin

Kurulum adımları, fiyatlandırma ya da ürüne erişim değiştiğinde, sürekli çalışan bir seri sessizce güncelliğini yitirebilir. Her serinin bir sorumlusu olsun ve seriyi ilgili ürün güncellemelerinden sonra gözden geçirin.

Hedeflenen sonucu da istenmeyen etkileri de ölçün. Amaç kurulumun tamamlanmasıysa bu eylemi şikâyetler ve abonelikten çıkmalarla birlikte takip edin. Açılmaları otomasyonun işe yaradığının kanıtı saymamak için [metrik rehberinden](/tr/blog/email-metrics-that-matter) yararlanın.