# Onboarding e-posta serisi: Günlere değil olaylara göre kurun URL: https://notificationharbor.com/tr/journal/onboarding-e-posta-serisi-olaylara-gore-kurun Type: blog Locale: tr Published: 2026-10-27 Updated: 2026-10-28 --- > Olay odaklı bir onboarding e-posta serisi için pratik bir plan: beş e-posta, tetikleyici mantığı, çıkış koşulları ve ölçüm yöntemi. Bir onboarding e-posta serisi, yeni bir kullanıcının ne yaptığına tepki verdiğinde işe yarar; kaç gün geçtiğine tepki verdiğinde değil. Onu tek bir aktivasyon olayı etrafında kurun, her e-postayı bir sinyal tetiklesin ve her e-postanın bir çıkış koşulu olsun. Sabit bir 1. gün, 3. gün, 7. gün takvimi tasarım değil, yedek plandır. Çoğu ekip tersini yapar. Beş e-posta yazarlar, aralarına gecikmeler koyarlar ve yayına alırlar. Altı hafta sonra aktivasyon oranı kıpırdamamıştır ve hangi e-postanın bunun sorumlusu olduğunu kimse söyleyemez. ## Hoş geldin e-postası yerine aktivasyon olayından başlayın Seri, bir kayıt olan kullanıcıyı ölçülebilir tek bir eyleme götürmek için vardır. Tek kelime metin yazmadan önce bu eylemi seçin. "Proje oluşturdu" ya da "ilk API isteğini gönderdi" bu işi görür. "Oturum açtı" görmez, çünkü oturum açmak henüz bir şeyin yapıldığı anlamına gelmez. Pencereyi de tanımlayın. Bizim varsayılanımız, kayıt kohortu başına, kayıttan itibaren 14 gün içinde aktivasyondur. Pencere olmadan serinin iki sürümünü karşılaştıramazsınız. Biri daha çok aktivasyon getirdiğinde bunun nedenini de söyleyemezsiniz. Sonra geriye doğru çalışın. Kullanıcının o olaya ulaşmak için tamamlaması gereken adımları listeleyin ve her adıma en fazla bir e-posta verin. Bir adımın hiç e-postası yoksa, kullanıcı o adımı kendi başına atar ya da düşüşü kabul edersiniz. ![Elle çizilmiş akış şemasıyla bir defter, yanında klavye ve kahve](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-10/595e85-img1.webp) Hoş geldin e-postasının görevi bilgi vermek değil, tek bir kapıyı açmaktır. Kullanıcı e-postayı açtığında ne yapacağını bilmeli ve bu bilgi tek bir düğmeyle verilmelidir. Metin ne kadar uzunsa, düğme o kadar kaybolur. Özellik turu e-postasını atlayın. İkinci günde kimsenin sormadığı bir soruyu yanıtlar. Bir e-posta, bir eylem, bir bağlantı. ## Pratikte minimum bir seri nasıl görünür? Ücretsiz denemesi olan çoğu SaaS ürünü için beş e-posta yeterlidir. Beş sayısı bir kural değildir; ama aşağıdaki yapı, her birinin tetikleyicisiyle birlikte, işe yaradığını gördüğümüz biçimdir. - **Hoş geldin**: `user.signed_up` olayında, saniyeler içinde gönderilir. Hesabı doğrular, tek bir ilk eylemi adlandırır ve doğrudan o eyleme bağlanır. - **İlk eylem hatırlatması**: kayıttan 24 saat sonra, yalnızca aktivasyon adımı 1 olayı gerçekleşmediyse gönderilir. - **Engel yardımı**: bilinen bir hata sinyali göründüğünde gönderilir; geçersiz bir API anahtarı hatası ya da yarıda kalmış bir içe aktarma gibi. Bu setin en değerli e-postasıdır. - **Kanıt e-postası**: 3. günde, başlayıp bitirmeyen kullanıcılara gönderilir. Tek bir müşteri sonucu, bağlamıyla birlikte tek bir sayı içerir. - **Son adım itmesi**: kullanıcı aktivasyona bir olay uzaklıktaysa gönderilir ya da zamana dayalı bir yedek olarak 7. günde. Her e-postanın tek bir bağlantısı olmalı ve bu bağlantı kullanıcıyı tam olarak tetikleyicinin işaret ettiği eyleme götürmelidir. Kullanıcı bağlantıya tıkladığında gördüğü ekran, e-postada vaat edilen şeyle aynı olmalıdır. Aksi halde tıklama aktivasyona değil, hayal kırıklığına dönüşür. Beşin üçünün koşullu olduğuna dikkat edin. Hoş geldin e-postası herkese giden tek e-postadır. Diğerleri, kullanıcının yaptığı ya da yapmadığı şeye göre hareket eder. Hoş geldin e-postalarının açılma oranlarının hayatınızda göreceğiniz en yüksek değerler olduğunu da unutmayın. Bu sayıya şüpheyle yaklaşın: Apple Mail Gizlilik Koruması görselleri önceden yükler ve listenizin büyük bir bölümünde açılmaları şişirir. Bunun yerine tıkla-aktive et oranını izleyin. ## Zamana dayalı seriler en çok önem verdiğiniz kullanıcılarda başarısız olur Yalnızca zamana dayalı bir seri, birinci günde aktive olmuş bir kullanıcıya 3. günkü e-postayı gönderir. Bu kullanıcıya zaten yaptığı bir şeyi yapması söylenir. Bu, otomasyon gibi görünür ve gerçekten de otomasyondur. Başarısızlık diğer yönde de olur. İkinci adımda takılan bir kullanıcı yardım yerine neşeli bir özellik e-postası alır. Seri sorunu göremez, dolayısıyla ona tepki de veremez. Çözüm karmaşık değildir, ama bir olay kaynağı gerektirir. Davranışa dayalı seriler üç girdiye ihtiyaç duyar: olay akışı, kullanıcı başına bir durum ve her gönderimden önce durumu kontrol eden bir kural. `{ "trigger": "user.signed_up", "steps": [ { "id": "welcome", "delay": "0s" }, { "id": "first_action_nudge", "delay": "24h", "send_if": "NOT event(project.created)" }, { "id": "proof", "delay": "72h", "send_if": "event(project.created) AND NOT event(first_send)" }, { "id": "last_step", "delay": "7d", "send_if": "NOT event(activated)" } ], "exit_when": ["activated", "unsubscribed", "account.deleted"] }``send_if` kontrolü kayıt anında değil, gönderim anında çalışır. Bu ayrım önemlidir. Koşulu kullanıcı akışa girdiğinde değerlendirirseniz statik bir segment kurmuş olursunuz ve gönderim geldiğinde durum eskimiş olur. `exit_when` listesi de aynı mantıkla okunmalıdır: her çıkış koşulu, kullanıcının artık o seriye ait olmadığını söyler. ## Çıkış koşulu, insanların unuttuğu özelliktir Her serinin onu bitiren bir kurala ihtiyacı vardır. Açık olan kural aktivasyondur. Kaçırılan iki kural daha vardır: onboarding akışının aboneliğinden çıkış ve hesap silme ya da deneme süresinin bitmesi. Ücretli plana geçtikten sonra da e-posta almaya devam eden seriler gördük. Bu bir çıkış koşulu hatasıdır ve kaçırılan bir açılmadan daha pahalıya mal olur. Kullanıcıya, e-postalarınızın hesaplarına bağlı olmadığını öğretir. Deneme süresi özellikle dikkat ister. Deneme bittiğinde ücretli plana geçmeyen kullanıcıya gönderilen e-postanın tonu, ücretli plana geçen kullanıcıya gönderilenden farklı olmalıdır. İki kullanıcı grubunu aynı akışta tutuyorsanız, en az bir çıkış koşulu fazladan yazmanız gerekir. Çıkış kurallarını önce yazın ve önce test edin. Gerçek kullanıcı zaman çizelgelerinden birkaçını staging ortamında akıştan geçirin ve her birinin olması gereken yerde durduğunu kontrol edin. İyi metni olup çıkışı olmayan bir seri, sade metinli ama temiz çıkışları olan bir seriden daha kötüdür. ![Olay günlüklerini gösteren terminal ekranının açık olduğu, loş bir odadaki dizüstü bilgisayar](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-10/390062-img2.webp) ## Olay verisi nereden gelir? Serinin kalitesi sinyalin kalitesine bağlıdır. Üç yaygın kaynak vardır ve gecikme ile hata biçimleri birbirinden farklıdır. Segment gibi bir ürün analitiği hattı olayları saniyeler içinde iletir, ama yalnızca sizin kurduğunuz olayları. Backend'inizden gelen doğrudan bir webhook en güvenilir olanıdır, çünkü işi yapan kod yolundan tetiklenir. Postgres değişiklik yakalama (CDC) ise satıra dokunan her değişikliği görür; yönetici betiklerinin yaptıkları da dahil. Bu bir özellik de olabilir, bir hata da. Aktivasyon olayı için tek bir doğruluk kaynağı seçin ve bunu akış tanımının yanında belgeleyin ki bir sonraki mühendis ikinci bir kaynak eklemesin. Birbirinden birkaç dakika sapan iki kaynak, ürün durumuyla çelişen e-postalar üretir. Kurulumu bitirdikten sonra "Kurulumu tamamlayın" e-postası alan kullanıcı bunun tipik örneğidir. Olay adlarını da erken sabitleyin. `project.created` ile `projectCreated` gibi iki adlandırma, aynı olayın iki ayrı olay gibi görünmesine yol açar ve tetikleyici hiç ateşlenmez. Adlandırma kuralını bir kez yazın, ekibin geri kalanı ona uysun. Idempotency anahtarları burada da önemlidir. Olay hatları yeniden dener, dolayısıyla aynı `project.created` olayı iki kez gelebilir. Göndericiniz anahtara göre tekilleştirme yapmıyorsa kullanıcı aynı e-postayı iki kez alır. Customer.io bu modelin etrafında kurulmuştur: olayları bir API, SDK'lar veya bir CDP üzerinden alır ve bir iş akışı oluşturucusundan tetikler. Farklı bir yığın kullanıyorsanız, aynı desen, tetikleyici kabul eden ve koşulları gönderim anında değerlendiren herhangi bir gönderici ile çalışır. ## İşlemsel mi, pazarlama mı: akışı bilinçli seçin Bazı onboarding e-postaları pratikte işlemseldir. "API anahtarınız hazır" ya da e-posta doğrulama mesajı bir pazarlama kuyruğunun arkasında beklememeli ve bir promosyon gönderimiyle gönderim itibarını paylaşmamalıdır. Postmark bu ayrımı, mesaj akışlarını farklı altyapılara ayırarak bir tasarım ilkesine dönüştürür. Gerekçe, kullanmasanız bile sağlamdır: kötü bir promosyon gönderimi asla bir şifre sıfırlama e-postasını geciktirmemelidir. Kuralımız basit. Kullanıcı e-posta olmadan ilerleyemiyorsa işlemsel akışa gider. E-posta teşvik niteliğindeyse pazarlama akışına gider ve yalnızca o akışı etkileyen bir abonelik iptali bağlantısı taşır. ![Bir demiryolu yolu ayrımındaki pirinç makas kolu](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-10/547606-img3.webp) ### Geliştirici öncelikli bir gönderici inşayı değiştirir mi? Başlangıç noktasını değiştirir. API öncelikli bir göndericide seri mantığı kodunuzda ya da küçük bir worker'da yaşar; sağlayıcı yalnızca teslim eder. Akışlarınız için sürüm kontrolü, testler ve kod incelemesi elde edersiniz, görsel oluşturucuyu kaybedersiniz. Resend bu yolu izler: REST API, resmi SDK'lar ve React Email şablonları. E-postaları bileşen olarak ele alan bir ekip için makul bir uyum. Her dağıtım olmadan metin düzenlemek isteyen bir büyüme ekibi için ise sürtünmedir. Seriyi kimin düzenlediği konusunda dürüst olun. Cevap "büyüme ekibi, haftalık" ise, mühendisler sevmese bile bir iş akışı oluşturucusu doğru seçimdir. Cevap "mühendislik, her sürümde" ise, seriyi kodda tutun. ## Açılma oranı yerine tıkla-aktive et oranını ölçün Açılma oranı bu iş için zayıf bir sinyaldir. Gizlilik özellikleri onu şişirir ve bir açılma, kullanıcının bir şey yaptığı anlamına gelmez. Üç sayı size daha fazlasını söyler. - **Tıkla-aktive et**: belirli bir e-postaya tıklayan kullanıcılardan kaçı 24 saat içinde aktivasyon olayına ulaştı. - **Tetikleme gecikmesi**: olay ile gönderim arasındaki süre. Bir engel e-postası için birkaç dakikanın ötesi, anı kaçırmak demektir. - **Kontrol grubuna karşı aktivasyon**: kayıtların küçük bir grubunu seriden çıkarın ve 14 günlük aktivasyonlarını geri kalanla karşılaştırın. Ekibinizde bu üç sayıyı bir panoda birlikte gösterin. Tek başına tıkla-aktive et oranı yükselirken aktivasyon düşüyorsa, e-posta insanları kapıya çekiyor ama ürün ikinci kapıda onları kaybediyor demektir. Bu durumda sorun e-postada değil, ürün akışındadır. Kontrol grubu, serinin işe yaradığını bilmenin tek yoludur. Onsuz, aktivasyonun zaten gerçekleşecek olan kısmını e-postalara borçlandırıyorsunuz. Burada yayımlanmış bir aktivasyon oranı kıyaslaması vermiyoruz, çünkü yayımlanmış rakamlar farklı tanımlar kullanan satıcılardan geliyor. Önce kendi temel değerinizi ölçün. Sonra bir seferde yalnızca bir e-postayı değiştirin. ### Tek bir seri mi, birden fazla mı kurmalı? Persona etiketlerine göre değil, giriş koşuluna göre bölün. Davetle kaydolan bir kullanıcının ilk eylemi, tek başına kaydolan birinden farklıdır. Veri içe aktarmış bir kullanıcı, diğerlerinin henüz geçmediği bir çizgiyi çoktan aşmıştır. İki ya da üç giriş yolu genellikle yeterlidir. Daha fazlası bakım maliyetini kazancın üzerine çıkarır, çünkü her yolun kendi çıkışlarına ve testlerine ihtiyacı vardır. Ekip küçükse, hepsi bir arada bir platform kurulum işini azaltabilir. Brevo e-postayı, SMS'i ve bir CRM'i tek bir girişte toplar; henüz bir olay hattı kurmak istemeyen ekipler için uygun olabilir. Bunun bedeli, pazarlama panosunun merkezde olması ve saniyenin altındaki tetiklemelerin optimize edilen şey olmamasıdır. ## Önce neyi yayımlayacağız Aktivasyon olayını ve 14 günlük pencereyi tek bir satırda yazın. Hoş geldin e-postasını ve 24 saatlik hatırlatmayı, bir `send_if` kontrolü ve temiz bir çıkışla kurun. İlk günden itibaren yüzde 5 ila 10 oranında bir kontrol grubu ekleyin. Kanıt e-postasını ve son adım itmesini iki haftalık veri elinizde olana kadar bekletin. Loglarınızda en sık görülen hatayı adlandırabildiğiniz anda engel e-postasını ekleyin. Ürününüzde önce hangi hata sinyalini bağlardınız? Planı ekibe yazılı olarak verirken her e-postanın neden var olduğunu tek cümleyle yazın. Cümleyi yazamıyorsanız, e-posta muhtemelen fazlalıktır. ## FAQ ### Bir onboarding e-posta serisinde kaç e-posta olmalı? Genellikle 7 ila 10 gün içinde dört ila altı e-posta yaygın bir aralıktır. Ancak sayı, tetikleyicilerden daha az önemlidir. Hoş geldin e-postasından sonraki her e-posta kullanıcının yaptığı ya da yapmadığı bir şeye bağlı olmalı ve seri, kullanıcı aktive olduğunda sona ermelidir. ### Damla kampanyası ile onboarding e-posta serisi arasındaki fark nedir? Damla kampanyası herkese sabit bir takvimle gönderilir. Onboarding serisi ise bir aktivasyon olayına bağlıdır, her gönderimden önce kullanıcının durumunu kontrol eder ve kullanıcı aktive olduğunda, abonelikten çıktığında ya da ayrıldığında sona erer. ### İlk onboarding e-postası ne zaman gönderilmeli? Kayıttan saniyeler sonra. Hoş geldin e-postası hesabı doğrular ve tek bir ilk eylemi adlandırır; birkaç dakikalık bir gecikme bile kullanıcının başka bir şeye geçmiş olması demektir. ### Bir onboarding e-posta serisinin işe yarayıp yaramadığını nasıl ölçersiniz? Seriyi alan kullanıcılarla, serinin dışında tutulan küçük bir kontrol grubunun 14 günlük aktivasyonlarını karşılaştırın. E-posta başına tıkla-aktive et oranını ve tetikleme gecikmesini de ekleyin. Gizlilik nedeniyle önceden yüklenen görseller yüzünden tek başına açılma oranı güvenilir değildir. ### Onboarding e-postaları işlemsel mi yoksa pazarlama e-postası mı olmalı? İkisi de vardır. Doğrulama ya da API anahtarı gibi kullanıcının ilerlemek için ihtiyaç duyduğu e-postalar işlemsel akışa aittir. Teşvik ve ipuçları ise kendi abonelik kapsamına sahip bir yaşam döngüsü akışına aittir. ### Davranışa göre onboarding e-postalarını tetiklemek için hangi verilere ihtiyacınız var? Aktivasyon olayınızı içeren bir olay akışına, hangi olayların gerçekleştiğini kaydeden kullanıcı başına bir duruma ve gönderim anında çalışan bir kontrole ihtiyacınız var. Olaylar Segment, backend webhook'u ya da Postgres değişiklik yakalamasından gelebilir.