E-posta, SMS ve Telegram için şablonlar, teslim durumu, yeniden denemeler ve kullanıcı tercihleriyle tutarlı çok kanallı bir bildirim sistemi tasarlayın.
E-posta, SMS ve Telegram ayrı özellikler olarak inşa edildiğinde çatlaklar çabuk ortaya çıkar. "Aynı" uyarı farklı bir dilde, farklı zamanlamayla ve farklı alıcı kurallarıyla sonuçlanır. Destek ekipleri sonra üç farklı gerçeğin peşinden koşar: bir tane e-posta sağlayıcısında, bir tane SMS ağ geçidinde ve bir tane bot kaydında.
Çok kanallı bir bildirim sistemi bunu bildirimleri üç entegrasyon değil tek bir ürün olarak ele alarak düzeltir. Bir olay olur (parola sıfırlama, fatura ödendi, sunucu kapandı) ve sistem şablonlar, kullanıcı tercihleri ve teslim kurallarına göre hangi kanallardan iletileceğine karar verir. Mesaj kanal başına farklı biçimlendirilebilir, ama anlamı, verisi ve takibi tutarlı kalır.
Çoğu ekip, hangi kanaldan başlanmış olursa olsun aynı temele ihtiyaç duyar: değişkenli, versiyonlu şablonlar; teslimat durumu takibi ("gönderildi, teslim edildi, başarısız, neden"); mantıklı yeniden denemeler ve yedekler; onay ve sessiz saatlerle kullanıcı tercihleri; ve destek ekibinin ne olduğunu tahmin etmeden görebilmesi için bir denetim izi.
Başarı iyi anlamda sıkıcı görünür. Mesajlar öngörülebilir: doğru kişi doğru içeriği doğru zamanda ve izin verdiği kanallarla alır. Bir şey ters gittiğinde, her denemeye açık bir durum ve neden kodu kaydedildiği için sorun giderme basittir.
"Yeni giriş" uyarısı iyi bir örnektir. Bunu bir kez oluşturursunuz, aynı kullanıcı, cihaz ve konum verileriyle doldurursunuz, sonra ayrıntı için e-posta, aciliyet için SMS ve hızlı onay için Telegram olarak iletirsiniz. SMS sağlayıcısı zaman aşımına uğrarsa, sistem zamanlamaya göre yeniden dener, zaman aşımını kaydeder ve uyarıyı bırakmak yerine başka bir kanala yedekleyebilir.
Çok kanallı bir bildirim sistemi, "neden bildirim gönderiyoruz" ile "nasıl gönderiyoruz"u ayırdığınızda yönetilebilir kalır. Bu, küçük bir ortak nesne seti ve gerçekten farklı olduklarında yalnızca kanal-spesifik detaylar anlamına gelir.
Bir olay ile başlayın. Olay order_shipped veya password_reset gibi isimlendirilmiş bir tetikleyicidir. İsimleri tutarlı tutun: küçük harf, alt çizgi ve uygun olduğunda geçmiş zaman. Olayı şablonlar ve tercih kurallarının dayandığı sabit sözleşme olarak ele alın.
Bir olaydan bir bildirim kaydı oluşturun. Bu, kullanıcıya yönelik niyettir: kim için, ne oldu ve içeriği oluşturmak için hangi verilere ihtiyaç var (sipariş numarası, teslimat tarihi, sıfırlama kodu). Burada user_id, event_name, locale, priority ve scheduled_at gibi paylaşılan alanları saklayın.
Sonra kanala göre mesajlara bölün. Bir bildirim 0 ila 3 mesaj üretebilir (e-posta, SMS, Telegram). Mesajlar varış yeri (e-posta adresi, telefon, Telegram chat_id), template_id ve render edilmiş içerik (e-posta için konu/gövde, SMS için kısa metin) gibi kanal-spesifik alanları tutar.
Son olarak, her gönderimi bir teslim denemesi olarak izleyin. Denemeler provider request_id, zaman damgaları, yanıt kodları ve normalize edilmiş bir durum içerir. Kullanıcı "Hiç almadım" dediğinde inceleyeceğiniz şey budur.
Basit bir model genellikle dört tablo veya koleksiyona sığar:
Erken idempotentlik planlayın. Her bildirim için (event_name, user_id, external_ref) gibi deterministik bir anahtar verin, böylece yukarı akış sistemlerinden gelen yeniden çalıştırmalar çoğaltma yaratmaz. Bir iş akışı adımı yeniden çalıştırılırsa, idempotency anahtarı kullanıcının iki SMS almamasını sağlar.
Uzun vadede yalnızca denetim için gerekenleri saklayın (olay, bildirim, nihai durum, zaman damgaları). Kısa vadeli teslim kuyruklarını ve ham sağlayıcı yüklerini yalnızca işletmek ve sorun gidermek için gerektiği kadar tutun.
Çok kanallı bir bildirim sistemi, "ne göndereceğine karar verme"yi "gönderme"den ayrı tuttuğunda en iyi sonucu verir. Bu, uygulamanızı hızlı tutar ve hataları ele almayı kolaylaştırır.
Pratik bir akış şöyle görünür:
Bir olay üreticisi bildirim isteği oluşturur. Bu "password reset", "invoice paid" veya "ticket updated" gibi olabilir. İstek bir kullanıcı ID'si, mesaj tipi ve bağlam verisi (sipariş numarası, tutar, destek temsilcisi adı) içerir. Denetim izi için isteği hemen saklayın.
Bir yönlendirici kullanıcı ve mesaj kurallarını yükler. Kullanıcı tercihlerini (izin verilen kanallar, opt-inler, sessiz saatler) ve mesaj kurallarını (örneğin: güvenlik uyarıları önce e-posta denenmeli) kontrol eder. Yönlendirici Telegram, sonra SMS, sonra e-posta gibi bir kanal planı belirler.
Sistem kanal başına gönderim işleri kuyruğa alır. Her iş bir şablon anahtarı, kanal ve değişkenler içerir. İşler kuyruğa gider, böylece kullanıcı işlemi gönderimle engellenmez.
Kanal çalışanları sağlayıcılar üzerinden teslim eder. E-posta SMTP veya bir e-posta API'sine, SMS bir SMS ağ geçidine, Telegram ise botunuza gider. Çalışanların idempotent olması gerekir, böylece aynı işi yeniden denemek kopya gönderimler yaratmaz.
Durum güncellemeleri tek bir yere akar. Çalışanlar kuyruklandı, gönderildi, başarısız gibi durumları ve varsa teslim edildi bilgisini kaydeder. Bir sağlayıcı sadece "accepted" doğruluyorsa, bunu da kaydedin ve teslim edildiyle ayrı değerlendirin.
Yedekler ve yeniden denemeler aynı durumdan yürütülür. Telegram başarısız olursa, yönlendirici (veya bir retry çalışanı) SMS'i sıraya alabilir; bağlam kaybolmaz.
Örnek: bir kullanıcı parolasını değiştirir. Backend tek bir istek yayınlar; yönlendirici kullanıcının Telegram'ı tercih ettiğini görür ama sessiz saatler gece gönderimi engellediği için e-postayı şimdi, Telegram'ı sabah için planlar; bunların hepsini aynı bildirim kaydı altında izler.
Bunu AppMaster içinde uyguluyorsanız, istek, işler ve durum tablolarını Data Designer'da tutun ve yönlendirme ile yeniden deneme mantığını Business Process Editor'da ifade edin; gönderimler asenkron yürütülür ki UI duyarlı kalsın.
İyi bir şablon sistemi şu fikirle başlar: bir olay hakkında bildiriyorsunuz, "e-posta gönderiyorsunuz" veya "SMS gönderiyorsunuz" değil. Her olay için bir şablon oluşturun (Password reset, Order shipped, Payment failed) ve sonra aynı olay altında kanal-spesifik varyantları saklayın.
Tüm kanal varyantları boyunca aynı değişkenleri tutun. E-posta first_name ve order_id kullanıyorsa, SMS ve Telegram da aynı isimleri kullanmalı. Bu, bir kanalda doldurulmuş görünürken diğerinde boş alanlar çıkmasını engeller.
Her olay için kanal başına küçük bir alan seti tanımlayın:
Kanallar arasında değişen tek şey biçimlendirmedir, anlam değil.
SMS kısa olduğu için özel kurallar gerekir. İçerik çok uzun olduğunda ne olacağını önceden belirleyin ve tutarlı yapın: karakter limiti belirleyin, bir kısaltma kuralı seçin (kes ve ... ekle ya da ilk önce opsiyonel satırları bırak), uzun URL ve gereksiz noktalama işaretlerinden kaçının, ve ana işlemi erken koyun (kod, son tarih, sonraki adım).
Dili bir parametre olarak ele alın, ayrı bir iş akışı olarak değil. Olay ve kanal başına çevirileri saklayın, sonra aynı değişkenlerle render edin. "Order shipped" mantığı aynı kalırken konu ve gövde locale göre değişir.
Önizleme modu kendini öder. Örnek verilerle (uzun isim gibi uç durumlar dahil) şablonları render edin ki destek e-posta, SMS ve Telegram varyantlarını yayına almadan önce doğrulayabilsin.
Bir bildirim, sonra ne olduğunu cevaplayabiliyorsanız kullanışlıdır. Çok kanallı bir bildirim sistemi, göndermek istediğiniz mesajı her teslim denemesiyle ayırır.
E-posta, SMS ve Telegram arasında aynı anlama gelen küçük bir durum seti ile başlayın:
Bu durumları ana mesaj kaydında tutun, ancak her denemeyi bir geçmiş tablosunda izleyin. O geçmiş, hata ayıklamayı kolaylaştırır: deneme #1 zaman aşımı verdi, deneme #2 başarılı oldu; ya da SMS gönderildi ama e-posta sürekli sekmeye düşüyor.
Sağlayıcı yanıtlarını normalize edin ki farklı sağlayıcılar farklı kelimeler kullansa bile sorunları arayıp gruplayabilesiniz.
Kısmi başarıya hazırlıklı olun. Bir bildirim üç kanal mesajı üretebilir; bunlar aynı parent_id ve iş bağlamını (order_id, ticket_id, alert_type) paylaşır. SMS gönderilip e-posta başarısız olursa, tam hikâyeyi tek bir yerde görmek istersiniz, ayrı üç olay yerine.
"Gönderildi" "teslim edildi" değildir. Telegram için API'nin mesajı kabul ettiğini bilebilirsiniz. SMS ve e-posta için teslimat genellikle webhook veya sağlayıcı geri çağrısına bağlıdır ve her sağlayıcı eşit güvenilirlikte değildir.
Kanala göre "teslim edildi" tanımını baştan yapın. Kullanılabiliyorsa webhook onaylı teslimatı kullanın; aksi halde teslim edildi bilinmiyor olarak ele alın ve raporlamada gönderildi olarak gösterin. Bu, raporlarınızı dürüst tutar ve destek yanıtlarını tutarlı kılar.
Yeniden denemeler bildirim sistemlerinin sıkça yanlış yaptığı yerdir. Çok hızlı yeniden denerseniz fırtınalar yaratırsınız. Sonsuza dek denerseniz kopya ve destek baş ağrılarına yol açarsınız. Amaç basit: gerçekten işe girme şansı olduğunda tekrar dene, işe yaramayacağına karar verdiğinde dur.
Önce hataları sınıflandırın. Bir e-posta sağlayıcısından zaman aşımı, bir SMS ağ geçidinden 502 ya da geçici bir Telegram API hatası genelde yeniden denenebilir. Yanlış biçimli bir e-posta adresi, doğrulama hatası veren bir telefon numarası veya botunuzu engelleyen bir Telegram sohbeti ise denenmemeli. Bunları aynı şekilde ele almak para israfı ve log taşkını olur.
Pratik, sınırlandırılmış ve geriye çekimli bir yeniden deneme planı şöyledir:
Durma, veri modelinizde gerçek bir yer gerektirir. Mesaj retry limitlerini aştığında dead-letter (veya permanently failed) olarak işaretleyin. Son hata kodunu ve kısa bir hata mesajını saklayın ki destek tahmin etmeden aksiyon alabilsin.
Başarı sonrası tekrar gönderimleri idempotency ile önleyin. Mantıksal her mesaj için (genellikle notification_id + user_id + channel) bir idempotency anahtarı oluşturun. Bir sağlayıcı geç yanıt verip siz yeniden denerseniz, ikinci deneme bir kopya olarak tanınmalı ve atlanmalıdır.
Yedeklemeler panik değil kasıtlı olmalı. Ciddiyet ve zamana göre yükseltme kuralları tanımlayın. Örneğin: parola sıfırlama başka kanala yedeklenmemeli (gizlilik riski), ama bir üretim olayı iki başarısız Telegram denemesinden sonra SMS'i deneyebilir, sonra 10 dakika sonra e-postaya geçebilir.
Bir bildirim sistemi insanlara saygı duyduğunda "akıllı" hissi verir. Bunun en basit yolu kullanıcılara bildirim türü başına kanal seçme hakkı vermektir. Birçok ekip kuralları ve yasal gereksinimleri farklı olduğu için türleri güvenlik, hesap, ürün ve pazarlama gibi kovalar halinde ayırır.
Bir kanal mevcut olmadığında bile çalışan bir tercih modeli ile başlayın. Bir kullanıcının e-postası olabilir ama telefon numarası yok; veya Telegram bağlantısı henüz yapılmamış olabilir. Sistem bunu normal kabul etmeli, hata olarak değil.
Çoğu sistem şu kompakt alan setine ihtiyaç duyar: bildirim tipi (security, marketing, billing), tipe göre izin verilen kanallar (email, SMS, Telegram), kanal başına onay (tarih/saat, kaynak ve gerekirse kanıt), kanal başına opt-out nedeni (kullanıcı seçimi, sekme yapan e-posta, "STOP" yanıtı) ve sessiz saat kuralı (başlangıç/bitiş artı kullanıcı saat dilimi).
Sessiz saatler sistemlerin sık kırıldığı yerdir. Kullanıcının saat dilimini (sadece offset değil) saklayın ki yaz saati uygulamaları sürpriz yaratmasın. Bir mesaj sessiz saat içinde planlanırsa, onu başarısız saymayın. Ertelenmiş olarak işaretleyin ve bir sonraki izin verilen gönderim zamanını seçin.
Varsayılanlar önemlidir, özellikle kritik uyarılar için. Yaygın bir yaklaşım: güvenlik bildirimleri sessiz saatleri yok sayar (ancak gerekli durumlarda sert opt-outlara saygı gösterir), kritik olmayan güncellemeler sessiz saatlere ve kanal tercihlerine uyar.
Örnek: parola sıfırlama en hızlı izin verilen kanala hemen gitmeli. Haftalık özet sabaha kadar beklemeli ve kullanıcı açıkça etkinleştirmedikçe SMS'i atlamalı.
Bildirimler e-posta, SMS ve Telegram'a dokunduğunda, destek ekiplerinin hızlıca cevaplara ihtiyacı olur: Gönderdik mi, ulaştı mı ve ne başarısız oldu? Çok kanallı bir bildirim sistemi, arka planda birkaç sağlayıcı kullanıyor olsa bile araştırma için tek bir yer sunmalı.
Herkesin kullanabileceği basit bir yönetici görünümü ile başlayın. Kullanıcı, olay türü, durum ve zaman penceresine göre aranabilir olsun; en son deneme ilk gösterilsin. Her satır kanal, sağlayıcı yanıtı ve bir sonraki planlanan eylemi (yeniden deneme, yedek, veya durduruldu) göstermeli.
Kesintiler nadiren tek bir temiz hatayla görünür. Küçük bir metrik setini takip edin ve düzenli gözden geçirin:
Her şeyi ilişkilendirin. Olay olduğunda bir korelasyon ID'si oluşturun (ör. "invoice overdue") ve bunu şablonlama, kuyruğa alma, sağlayıcı çağrıları ve durum güncellemeleri boyunca geçirin. Loglarda o ID, bir olayın birçok kanala yayılışını takip etmek için iplik olacaktır.
Yeniden oynatmalar gerekli ama insanlara spam atmamaları veya iki kez ücretlendirmeleri için korumalarla gelmeli. Güvenli bir yeniden oynatma akışı genellikle şöyledir: yalnızca belirli bir mesaj ID'sini yeniden gönder (tüm olay yığınını değil), gönderilmeden önce tam şablon versiyonunu ve render edilmiş içeriği göster, bir neden iste ve yeniden oynatmayı kim başlattığını sakla, mesaj zaten teslim edildiyse yeniden oynatmayı engelle (açıkça zorlanmadıkça), ve kullanıcı/kanal başına oran limitleri uygula.
Çok kanallı bir bildirim sistemi kişisel verilere (e-posta, telefon numarası, chat ID'leri) dokunur ve genellikle hassas anları (girişler, ödemeler, destek) kapsar. Her mesaj gövdesi ve her log satırının daha sonra görülebileceğini varsayın; sonra ne sakladığınızı ve kimlerin görebileceğini sınırlayacak şekilde tasarlayın.
Mümkün olduğunca hassas verileri şablonların dışında tutun. Bir şablon yeniden kullanılabilir ve sade olmalı: "Your code is {{code}}" gibi bir ifade uygundur, ancak hesap detayları, uzun tokenlar veya hesabı ele geçirebilecek şeyler eklemeyin. Bir mesaj tek kullanımlık kod veya sıfırlama tokeni içermek zorundaysa, doğrulamak için yalnızca gerekeni (örneğin bir hash ve son kullanım zamanı) saklayın, ham değeri değil.
Bildirim olaylarını saklarken veya loglarken, agresifçe maskeleyin. Bir destek görevlisinin genellikle bilmesi gereken gönderilen bir kodun varlığıdır, kodun kendisi değil. Telefon numaraları ve e-posta için de aynı: teslimat için tam değeri saklayın ama ekranlarda çoğunlukla maskelenmiş gösterin.
Pratik bir örnek: parola sıfırlama SMS'i başarısız olursa ve Telegram'a yedeklenirse, denemeyi, sağlayıcı durumunu ve maskelenmiş alıcıyı saklayın; ancak sıfırlama bağlantısını veya kodun ham halini veritabanınızda veya loglarda saklamamaya çalışın.
Müşteri Maya'nın iki bildirim türü etkin: Password reset ve New login. Tercihi önce Telegram, sonra e-posta. Parola sıfırlamalarında yalnızca SMS'i yedek olarak ister.
Bir akşam, Maya parola sıfırlama ister. Sistem tek bir bildirim kaydı oluşturur ve mevcut tercihleri temel alarak kanal denemelerine genişletir.
Maya'nın gördüğü basittir: birkaç saniye içinde Telegram mesajı gelir; kısa bir sıfırlama kodu ve son kullanım süresi vardır. Telegram başarılı olduğu için başka bir şey gelmez.
Sistemin kaydettiği daha ayrıntılıdır:
Haftanın ilerleyen bir gününde, yeni cihazdan bir New login uyarısı tetiklenir. Maya'nın giriş uyarıları için tercihleri yalnızca Telegram. Sistem Telegram gönderir ama sağlayıcı geçici bir hata döner. Sistem iki kez arka plan beklemesiyle tekrar dener, sonra denemeyi BAŞARISIZ olarak işaretler ve durur (bu uyarı tipi için yedek yok).
Gerçek bir hata durumu: Maya seyahat ederken tekrar parola sıfırlama ister. Telegram gönderilir, ancak 60 saniye içinde teslim edilmezse SMS yedeği yapılandırılmıştır. SMS sağlayıcısı zaman aşımı verir. Sistem zaman aşımını kaydeder, bir kez daha dener ve ikinci deneme başarılı olur. Maya SMS kodunu yaklaşık bir dakika sonra alır.
Maya desteğe başvurduğunda, kullanıcı ve zaman penceresine göre arama yaparlar ve hızlıca deneme geçmişini görürler: zaman damgaları, sağlayıcı yanıt kodları, yeniden deneme sayısı ve nihai sonuç.
Çok kanallı bir bildirim sistemi, iki soruyu hızlı yanıtlayabildiğinizde yönetimi kolaydır: "Tam olarak ne göndermeye çalıştık?" ve "Bundan sonra ne oldu?". Kanal veya olayı eklemeden önce bu kontrol listesini kullanın.
invoice.overdue faturalar tarafından yönetilir)Eğer tek bir şey yapacaksanız, "gönderildi" ile "teslim edildi" arasındaki farkı açıkça yazın. Gönderildi sisteminizin yaptığı iştir. Teslim edildi sağlayıcının raporu olup (gecikebilir veya eksik olabilir) bunları karıştırmak destek ekiplerini ve paydaşları yanıltır.
Bir olay ve bir birincil kanal ile başlayın, sonra ikinci kanalı yedek olarak ekleyin (paralel patlama değil). Akış stabil hale geldikçe olay bazında genişleyin; şablonları ve değişkenleri paylaşmaya devam edin ki mesajlar tutarlı kalsın.
Eğer bunu her parçayı elle kodlamadan kurmak istiyorsanız, AppMaster (appmaster.io) çekirdek parçalar için pratik bir uyum sağlar: olayları, şablonları ve teslim denemelerini Data Designer'da modelleyin, yönlendirme ve yeniden denemeleri Business Process Editor'da uygulayın ve e-posta, SMS ile Telegram'ı entegrasyon olarak bağlarken durum takibini tek yerde tutun.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
