E-mail akış sorunlarımızı nasıl aştık?

Dijital pazarlamanın en önemli unsuru olan e-mail marketing hepimiz için büyük önem taşımakta. Ancak bunun yönetimini çok iyi yapmak ve takip etmek gerekiyor. Bu yazımda Hesapkurdu.com olarak e-mail akışlarımız nasıldı, eski akışlarda ne sorunlarla karşılaştık ve bu sorunları nasıl aştık bunlardan bahsedeceğim.

Başlamadan önce..

E-mail akışlarımızı üç ana kategoride değerlendiriyoruz. Siz de e-mail konusuyla ilgileniyorsanız bu kategoriler sıkça karşınıza çıkacaktır. Fakat biz iç akışımızda bazı kırılımlarını değiştirdik.

• Transactional
• Promotional (Newsletter, Fırsatlar, …)
• Internal

Transactional mailler, bilgilendirme amacı ile atılan maillerdir. Örneğin sıkça gördüğümüz aramıza hoş geldiniz, üyeliğiniz alındı, sipariş kargo/fatura bilgileri gibi yapılan bir işin sonunda atılan e-mailler transactional maillere örnektir. Biz de akışlarımızın büyük bir çoğunluğunda transactional mailleri kullanıyoruz. Örneğin müşterimiz kredi kullanımı yaptığında, sigorta poliçesi kestiğinde, kredi ödeme planı almak istediğinde ve benzeri birçok durumda otomatik olarak bilgilendirme maillerimizi atıyoruz.

Promotional mailler; tanıtım, kampanya ve kutlama amacı ile atılan maillerdir. Ancak biz promotional mailleri gerek yapıları, gerekse kullanım yerleri açısından farklı alt kırılımlarda değerlendiriyoruz. Örneğin, attığımız kampanya mailleri, sitemizdeki hesaplama araçlarını tanıttığımız maillerimiz, müşterilerimiz için yayınladığımız faydalı içerik yazılarımız, kutlama maillerimiz newsletter kategorisine giriyor.

Internal mailler ise şirket içi attığımız maillerdir. Hata, uyarı, raporlama gibi tüm şirket içi maillerimizi bu kategoriye alıyoruz.

Peki, maillerimizle alakalı sorunlarımız nasıl başladı?

Mail akışlarındaki sorunlarımızın fark edilmesi, maillerimizin spam’e düşmesi ile başladı. E-mail marketing yapan herkesin kabusu olan spam’in iyi takip edilmesi ve kontrol altına alınması gerekiyor. Zira işin ucunu kaçırdıktan sonra geri dönüşü zorlayıcı oluyor.

Niçin spam’e düşüyoruz?

Mail içeriğinden tutun da, mailin çok fazla renklendirilmesi, kullanılan kelimeler, maillerin içine konmayan abonelikten çıkma linkleri ve benzeri örnekler mailinizin spam olarak algılanma sebepleridir. Ancak bizim spam’e düşme sebebimizi bulmak için bu detaylardan önce gözümüze çarpan kocaman bir gerçek vardı: E-mail reputation!

E-mail reputation, kısaca sizin itibarınız. Bizim gibi itibarınız poor seviyeye geldiğinde spam zaten kaçınılmaz bir son oluyor. Nasıl bu seviyeye düştük diye baktığımızda, hard bounce-soft bounce terimleri karşımıza çıktı. Kısaca özetlemek gerekirse bu iki terim de maillerin karşıya iletilememe durumları için kullanılıyor. Soft bounce, geçici sebeplerle iletilememe durumudur. Örneğin alıcının mail kutusunun dolu olması, mail sunucusu sorunları, mail büyüklüğü ve benzeri iletilememe durumları soft bounce sayılıyor. Hard bounce ise bizim özellikle önlem almamız gereken durumlar. Örneğin alıcının mail adresinin veya domain’in olmaması, gönderici mailin kara listeye alınması/bloklanması vs. durumları.

Hard bounce sayımızın çokluğuna bakınca repütasyonumuzun düşüklüğünü çok rahat anlayabiliyorduk. (Bu arada reputation, hard bounce-soft bounce raporlarımıza mail provider’ımız üzerinden ulaştık.)

Neden bu kadar hard bounce aldık?

Eski yapımızda mail validation’ı basit bir regex kontrolü ile yapılıyordu. Bu regex kontrolü sayesinde en azından müşterilerimizden gerçek mail formatını alabiliyorduk. Ancak mailin formatı yetersiz kalıyor, aynı zamanda atılacak mail adresinin geçerli olması da gerekiyordu. Bunun için de mail validation api’si kullanılıyordu.

Validation api’leri ile kontrol etmek istediğiniz mail adresini api’ye yollayarak adresin geçerliliğini öğrenebiliyorsunuz. Bu hizmeti alabileceğiniz birçok api mevcut. Bazı mail provider’ları da ekstradan validation api’si sağlıyor. Biz, kullandığımız mail provider’ının sunduğu validation api’sini kullanıyorduk. Kısaca Regex kontrolünün üstüne bir de validation api’sine bütçe ayırarak ikinci bir kontrol sağlıyor, buna rağmen bir sürü hard bounce alıyorduk.

İşte burada, gözden kaçan ve dilimizi yakan kısma geliyoruz. Validation api’leri size çok önemli iki parametre yolluyor. Bunlardan biri mailin valid olup olmadığını gösteren parametre. Burada mail formatının doğruluğu kontrol edilerek size cevabı yollanıyor. Diğer önemli parametre ise atılacak mail adresinin geçerliliği. Atılacak mail adresi mevcut mu ve bu mail adresine mail atılabilir mi sorularının cevabı bu parametre ile alınıyor. Bu kontrol SMTP validation olarak geçiyor. Örnek vermek gerekirse random@random.com adresi mail formatı olarak geçerli olabilir fakat böyle bir mail adresi yoksa mail atılamayacaktır. Böylece bu adres format olarak uygun, ancak geçerli değildir.

Eski yapımızda dikkat edilmeyen nokta şuydu: Smtp check parametresi default olarak her response’ta dönmüyordu. Request’te belirli bir parametreyi yollayıp smtp check istersek bu parametre dönüyordu. Yani geçerli yapıda kontrol edilen tek şey mail formatıydı. Eh, bu dikkatsizliğin sonucu boşuna ödenen validation api parası + poor e-mail reputation olarak karşımıza çıkmıştı.

Hard bounce sorununu nasıl çözdük?

Office365, Mailgun, Mandrill, Amazon Simple E-mail Service gibi kullanabileceğiniz birçok transactional mail provider’ı mevcut. Bunlara ek olarak Mailboxvalidator, Neverbounce, Mailboxlayer, Quickemailverification gibi mail validation api’leri de var. Temiz bir başlangıç olarak yeni bir mail provider’ına ve ayrı bir mail validation api’sine geçtik. Entegrasyonları tamamladığımızda spam’e düşmüyorduk.

Elbette ki mail validation apileri %100 doğru kontrol garantisi sunmuyor. Hala arada validation’dan kaçan mailler olabiliyor (Hatta kullandığımız api’de şirket içinden bir arkadaşımızın mail adresinin valid olmadığı söyleniyordu. Bu konuda ilgili şirkete mail atarak sorunu çözebiliyorsunuz.). Yine de hata oranımız bu yolla yüksek oranda düşmüştü. Düzenli olarak reputation’ımıza ve bounce sayılarımıza bakıyorduk. Mail raporlarında işler yoluna girmişti.

Newsletter — Transactional yönetimi

Bu noktada dikkat ettiğimiz bir konuya daha değinmek istiyorum. Newsletter — transactional maillerin yönetiminin ayrılması.

Transactional maillerimizi projemiz üzerinden otomatize ederek yönetiyoruz ancak newsletter maillerimizi ayrı bir ara yüzden atıyoruz. Bunun birinci sebebi newsletter mailleri çok geniş bir kitleye gidiyor ve açılma oranları transactional maillere göre düşük. Bu yüzden bu durumun reputation’ımızı etkilemesini istemiyoruz. İkinci sebep ise newsletter maillerin çoğu otomatik olarak gitmiyor. Mail atılmadan önce template düzenlenmesi, atılacak kitle seçilmesi, zamanlama gibi işlemlerden geçiyor.

Piyasada bunu kolayca yönetebileceğiniz birçok provider mevcut. Maillerinizi istediğiniz template ile, istediğiniz müşterilere, istediğiniz zaman yollayabiliyorsunuz. Ayrıca isterseniz newsletter maillerinizi otomatize edebiliyorsunuz. Mailin açılma ve tıklanma oranları, ulaşma sayıları, en çok hangi bölgelere mail atılmış, atılan maile hangi client’lardan girilmiş gibi raporlara kolayca erişebiliyorsunuz. Ayrıca bu provider’ların sundukları api’lerle projenize entegre olup liste, template gibi yönetimleri yapabiliyorsunuz. İyi bir yapı kurmaya vaktiniz yoksa bu provider’ları araştırıp değerlendirebilirsiniz.

İşte biz de, newsletter mailleri bu provider’lardan gönderiyoruz ancak transactional mailleri kendi projemizde yönetiyoruz. Promotional maillerimizin newsletter, price-watch vs. olarak ayrılma sebebi de bir bakıma bu. Fırsat ve benzeri maillerimizi newsletterdan farklı olarak kendi akışımız içerisinde yönetiyoruz. Haftalık en uygun kredi oranlarını hesaplayarak istediğimiz müşteri kitlesine otomatize ederek yolluyoruz.

Senkron akış sorunu

Bu adımları uyguladığımızda reputation ve spam’i kontrol altına aldık ancak bu sefer de proje akış sorunlarımız ortaya çıktı.

Müşterilerimiz maillerini girdiğinde front end’de basit bir regex kontrolü oluyordu. Bu kontrolden geçen mail adresleri back end’de validation api’sine gidip kontrol ediliyordu ve gelen cevaba göre akış devam ederek müşteriye mail atılıyordu. Ancak üzülerek belirtmek gerekirse bütün bu işlem senkron ilerliyordu. Validation api’sinin cevap verme süresinin arttığı zamanlarda müşteriyi bekletmemek için mail adresi geçerli kabul edilerek akış devam ediyordu.

Bir süre bu durumu izlediğimizde çok fazla aradan kaçan geçersiz mail olduğunu ve reputation’ımızın Excellent’tan Good’a düştüğünü gördük. Bu senkron yapının cevap verme süresi arttıkça kullanıcı deneyimi kötüye gitmeye başladı. Aynı zamanda hangi mailin kontrol edilip edilmediği tutulmuyordu. Bir mail adresine birçok farklı mail atılabileceğini düşünürseniz, aynı adresi her mail atılmadan önce kontrol etmek için api’ye gönderiyorduk. Bu hem boşuna request sayısı (validation api’sine yolladığınız request sayısına göre ücretlendiriliyorsunuz), hem de zaman kaybıydı. Kısaca, mailin senkron gittiği bu akış başlı başına bir hataydı.

Asenkron akışa geçiş

Sonuçta bütün yapıyı olması gerektiği gibi asenkron olarak tasarladık. Bu yapıda en büyük kurtarıcımız ise Hangfire oldu. Hangfire, background job’ları yönetmede büyük bir yardımcı. Fire and forget, delayed, recurring, continuations gibi bir çok farklı job’ı çok kolay bir şekilde Hangfire ile yönetebilirsiniz.

Bu yazımızda Hangfire ile ilgili detaya girmeyeceğiz, daha detaylı bilgi için sizi şu yazımıza alalım.

Hangfire sayesinde fire and forget kurgumuzla artık kafamız rahatlamıştı.

Bu yeni kurguda müşterilerimiz mail adreslerini girip ilerlemek istediğinde, akış müşteriyi bekletmeden devam ediyor ve mail atma isteği Hangfire’da queue’ya alınıyor. Aynı adresi boşu boşuna birçok kez kontrol etmemek için database’de isChecked ve isValid flagleri tutuluyor. isChecked ile bu adres daha önceden kontrol edilmiş mi, isValid ile de mail adresi geçerli mi yanıtı alınıyor.

Böylece Hangfire’da sıraya alınan mail atma job’ı çalışırken önce mail adresi check edilmiş mi diye kontrol ediliyor. Check edilmişse valid olup olmadığına bakılarak mail atıp atmama kararı veriliyor. Daha önceden check edilmeyen bir adres ise bu adres validation api’sine yollanarak check ediliyor ve valid durumuna göre mail atılıyor. En sonunda check ve valid değerlerine uygun olarak database kayıtlarımız güncelleniyor.

Ancak bu zamana kadar database’imizde check edilmemiş birçok mail adresi mevcut. Geriye dönük olarak belli saatlerde çalışan bir task ile check edilmemiş mail adreslerini api’ye yollayarak check ediyor, daha sonra flag’lerimizi güncelliyoruz.

Burada ufak bir uyarı yapayım. E-mail ve farklı background job akışlarımızı Hangfire üzerinden yönetiyoruz. Eğer bütün job’ları aynı queue’ya alırsanız, job’ların erime süresi uzuyor. Bu yüzden mail akışlarınızı ve diğer job’larızı Hangfire üzerinde farklı queue’lara bölerek yönetebilirsiniz. Bu da Hangfire’ın başka bir güzelliği.

Kısacası e-mail akış sorunlarımızı bu şekilde aştık. Gördüğünüz gibi çok ufak dikkatsizler, büyük sorunlara dönüşebiliyor. Bu yazıda anlattığımız yöntemler sayesinde şuan e-mail reputation’ınımızı excellent hale getirip sizlerle bu yazıyı paylaşıyoruz :)

Eğer mail sürecini Front-end tarafında nasıl yönettiğimizi merak ediyorsanız bu linkteki yazımızdan detayları öğrenebilirsiniz.

Bir sonraki yazımızda görüşmek üzere :)