# Ürün olaylarıyla SaaS deneme süresi dönüşüm serisi nasıl kurulur?

Kanonik URL: https://brew.new/tr/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events
Yazar: Thomas Park
Yayımlandı: 2026-09-26
Güncellendi: 2026-09-29

Deneme süresi dönüşüm e-postası, kullanıcının ne yaptığına göre şekillenmelidir. Henüz proje oluşturmamış birinin kurulum yardımına ihtiyacı vardır. Ürünü her gün kullanan biri ise ücretli planın net bir açıklamasını bekler. İkisine de aynı geri sayımı göndermek bu farkı gözden kaçırır.

Bu rehber, seri tasarımını ve her e-postayı kimin alacağına karar veren uygulama mantığını birbirinden ayırıyor.

## Bir aktivasyon olayı seçin

Kullanıcının üründe ilk işe yarar sonuca ulaştığını gösteren tek bir eylem seçin. Bu eylem, sunucunuzun kaydedebileceği kadar belirli olmalı: oluşturulan bir proje, tamamlanan bir içe aktarma ya da davet edilen bir ekip arkadaşı. Bir sayfa görüntüleme tek başına nadiren yeterlidir.

Kayıt zamanını, deneme süresinin bitişini, aktivasyonu ve ücretli plan durumunu, bu bilgilerin esas kaynağı olan sistemde kaydedin. E-posta platformundaki kişi alanlarını, daha önce başlamış bir akışın güncel durumu okuduğunun kanıtı olarak değil, senkronize edilmiş veri olarak görün.

## Her mesaja tek bir görev verin

| Mesaj | Ne zaman işe yarar? | Zamanı geldiğinde kontrol edilen uygunluk |
| --- | --- | --- |
| Hoş geldin | Kayıttan ya da doğrulamadan sonra | Hesap mevcut ve bu mesajı alabilir |
| Kurulum yardımı | Yaklaşık iki gün sonra; ürününüze göre ayarlayın | Henüz aktive olmamış |
| Bir sonraki işe yarar eylem | Aktivasyondan sonra | Aktive olmuş ve o eylemi henüz tamamlamamış |
| Deneme süresinin bitişi | Deneme süresinin gerçek bitiş tarihinden önce | Deneme süresi hâlâ devam ediyor ve hesap ücretli değil |
| Son hal hatır sorma | Deneme süresi bittikten sonra, uygunsa | Hâlâ ödeme yapmamış, uygun ve pazarlama e-postası almasına izin verilmiş |

Bu zamanlamalar, ölçülmüş en iyi aralıklar değil, test için başlangıç noktalarıdır. Deneme süresinin gerçek bitiş tarihini ve sonrasında ne olacağını belirtin. Yapay bir kıtlık yaratmayın; kayıtlı bir ödeme yöntemi yokken ücret alınacakmış gibi bir izlenim de vermeyin.

## Uygunluk kontrolleri için kaynağı seçin

Brew içinde olayla tetiklenen bir akışta `payload.activated` orijinal olayı okur; `contact.activated` ise bir Filtre ya da koşullu Dallanma düğümü çalıştığı anda alıcının Brew içindeki güncel kişi alanını okur. Aktivasyondan sonra kurulum hatırlatmalarını atlamak için bu evet/hayır alanını tanımlayın, ürününüzden senkronize tutun ve ilgili her Bekle adımından sonra `contact.activated equals false` koşulunu kontrol edin. Değerin hiç olmaması, yanlış (false) olmasıyla aynı şey değildir; bu durumu ayrıca test edin.

Bu okumalar uygulamanızın veritabanını ya da canlı bir Stripe isteğini değil, Brew içinde kayıtlı kişiyi kullanır. Bir aktivasyon ya da ödeme olayının alınması, daha önce başlamış bir çalıştırmayı otomatik olarak iptal etmez. Graf, duruma bağlı her gönderimden önce bir koşul içermelidir.

Brew dışında tutulan bilgiler için uygulamanızda zamanlanmış bir iş oluşturun. İşin zamanı geldiğinde güncel hesabı ya da faturayı okuyun ve Brew içinde ayrı bir özel olayı yalnızca alıcı hâlâ koşulları sağlıyorsa tetikleyin. Kişiselleştirme için gereken güncel verileri bu yeni olaya ekleyin.

Örneğin uygulamanın planladığı bir hatırlatma şöyle işler:

```text
Signup committed → fire welcome event
Reminder job becomes due → read current account
  Already activated or paid → finish without firing an email event
  Still eligible → fire setup-reminder event with current data
```

Yani kayıt işlemi tamamlandığında hoş geldin olayı tetiklenir. Hatırlatma işinin zamanı geldiğinde uygulama güncel hesabı okur: Kişi zaten aktive olmuşsa ya da ödeme yapmışsa iş, hiçbir e-posta olayı tetiklemeden biter; hâlâ uygunsa güncel verilerle kurulum hatırlatması olayı tetiklenir.

Brew tarafından döndürülen gerçek tetikleyici kimliğini ve tetikleyicinin tanımlanan şemasını kullanın. [Otomasyon kurulum rehberini](https://docs.brew.new/create-emails/build-an-automation) ve [tipli payload sözleşmelerini](https://docs.brew.new/api-reference/guides/typed-payload-contracts) izleyin. Yeniden denenen olay tetiklemelerinde, tekrarlanan isteklere karşı belgelenmiş koruma mekanizmasını (idempotency) kullanın.

## Esas kaynağı Stripe olan bilgiler için Stripe’ı kullanın

Deneme süresini Stripe yönetiyorsa abonelik olayları faturalandırma bağlamını sağlar. [Stripe entegrasyonu](/tr/browse/integrations/stripe), `customer.subscription.trial_will_end` olayı dâhil desteklenen olay tetikleyicilerini sunar. Bu bilgiyi ayrıca göndermediğiniz sürece ürün aktivasyonunun esas kaynağı yine uygulamanızdır.

Ödemeyle ilgili sonraki bir hatırlatma için Stripe’taki güncel kaydı kontrol edin. Başarılı bir kart güncellemesi, faturanın ödendiğinin kanıtı değildir. Müşterinin her amaç için tek bir bildirim alması için Stripe’ın kendi e-postalarıyla eşgüdüm sağlayın.

## E-postayı uygunluk kuralından sonra yazın

Alıcının gerçek durumundan yola çıkın. İşe yarar tek bir eylemi açıklayın ve doğrudan ona bağlantı verin. Bir kurulum e-postası kısa bir örnek ve bir yanıt adresi sunabilir. Ücretli planı anlatan bir e-posta, ilgili sınırı ya da özelliği ve gerçek fiyatı, güncel fiyatlandırmaya giden bir bağlantıyla birlikte açıklamalıdır.

Pazarlama iznini, abonelikten çıkma işleyişini ve alan adının gönderim amacını mesajla uyumlu tutun. Bir deneme kaydı, ilgisiz tanıtım e-postalarını haklı çıkarmaz.

## Çıkışların çalıştığını kanıtlayın

Bir kişinin her uygunluk kontrolünden önce aktive olduğu ya da ödeme yaptığı durumda ne olduğunu test edin. Kişi koşullarında, bekleme sırasında ilgili Brew alanlarını güncelleyin ve hatırlatmanın atlandığını doğrulayın. Uygulamanın planladığı kontrollerde, uygun olmayan hesapların hatırlatma olayı üretmediğini doğrulayın. Yeniden denemeleri, deneme süresi uzatmalarını, hesap silmeyi, abonelikten çıkmaları ve eksik alanları da test edin. Hem uygulama günlüklerini hem de Brew içindeki çalıştırma geçmişini kontrol edin.

Aktivasyonu ve ücretli plana geçişi ürün verilerinizle, teslim hatalarını ise e-posta platformuyla değerlendirin. Açılma oranları tek başına serinin deneme kullanıcısına yardımcı olup olmadığını göstermez. Örnekler için [hoş geldin serisi tasarımı](/tr/blog/welcome-email-sequence), uygulamada işin nasıl bölüneceği için [MCP ve REST API karşılaştırması](/tr/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use) yazılarımıza göz atın.