Gönderim panelinizde geri dönme ve şikayet sayılarını görüyorsunuz. Ancak bu bilgiyi elle okuyup listenizi elle temizlemek, ölçek büyüdüğünde sürdürülemez hâle gelir — ve yoğun bir dönemde ertelenip bir daha yapılmaz.
Webhook entegrasyonu bu döngüyü otomatikleştirir: gönderim altyapısı olayları anlık olarak sisteminize bildirir, sisteminiz otomatik tepki verir.
Bu rehber, e-posta olay takibinin nasıl kurulacağını ve hangi olaylara nasıl tepki verilmesi gerektiğini anlatıyor.
Takip Edilebilecek Olaylar
| Olay | Anlamı | Öncelik |
|---|---|---|
| Teslim edildi | Alıcı sunucu kabul etti | Bilgi |
| Kalıcı geri dönme | Adres geçersiz | Kritik |
| Geçici geri dönme | Şimdilik teslim edilemedi | İzle |
| Şikayet | Spam olarak işaretlendi | Kritik |
| Abonelikten çıkma | Çıkış bağlantısı tıklandı | Kritik |
| Açılma | İleti görüntülendi | Bilgi |
| Tıklama | Bağlantıya tıklandı | Bilgi |
"Kritik" işaretli üç olay, otomatik tepki gerektirir ve elle yönetilemez. Diğerleri analiz içindir.
Otomatik Tepki Kuralları
Kalıcı Geri Dönme
Adresi anında ve kalıcı olarak tüm listelerden çıkarın. Geçersiz bir adrese ikinci kez göndermek, listenizin bakımsız olduğunu gösteren en net sinyaldir.
Dikkat: kalıcı geri dönme kodu iki farklı anlam taşıyabilir — adres yok veya politika reddi. İkincisinde adres geçerlidir ve sorun sizin yapılandırmanızdadır. Otomatik kuralınız bu ayrımı yapmalı, aksi hâlde geçerli adresleri silersiniz.
Şikayet
En ağır sinyal. Adresi anında tüm listelerden çıkarın ve engelli listesine ekleyin. Şikayet eden birine tekrar göndermek, yapılabilecek en zararlı hatadır — ikinci şikayet çok daha ağır değerlendirilir.
Abonelikten Çıkma
Anında işleyin. "48 saat içinde işleme alınacaktır" kabul edilebilir değildir; bu süre içinde gönderilen bir ileti şikayete dönüşür.
Geçici Geri Dönme
Hemen çıkarmayın; yeniden deneme mekanizması genellikle çözer. Ancak aynı adres üst üste birkaç kampanyada geçici geri dönüyorsa, pratikte ölü bir adrestir — pasife alın.
Webhook Güvenliği
Webhook uç noktası internete açık bir adrestir ve sisteminizde veri değiştiren işlemler yapar — abone siler, listeleri günceller. Korumasız bırakılırsa herkes sahte olaylar gönderip listenizi bozabilir.
Üç önlem:
- İmza doğrulaması. Sağlayıcılar genellikle her isteğe kriptografik bir imza ekler. Bu imzayı doğrulamadan hiçbir isteği işlemeyin. Bu, en önemli önlemdir.
- HTTPS zorunlu. Uç nokta yalnızca şifreli bağlantı kabul etmelidir.
- Tahmin edilemez adres. Uç nokta yolunu öngörülebilir tutmayın. Bu tek başına güvenlik değildir ama ek bir katmandır.
Dayanıklılık: Kaçırılan Olaylar
Webhook teslimatı garanti değildir. Sunucunuz kısa süreliğine erişilemez olursa olaylar kaybolabilir. Üç önlem:
- Hızlı yanıt verin. Uç noktanız isteği alır almaz başarı yanıtı dönmeli, işlemi arka planda yapmalıdır. Yavaş yanıt veren uç noktalar, sağlayıcı tarafında zaman aşımına uğrar ve olay kaçırılır.
- Tekrarlanan olaylara hazırlıklı olun. Sağlayıcı yanıt alamadığında aynı olayı tekrar gönderir. Aynı olayı iki kez işlemek zarar vermemelidir — her olayın benzersiz kimliğini kaydedip tekrarları yok sayın.
- Periyodik mutabakat yapın. Düzenli aralıklarla sağlayıcının kayıtlarıyla kendi kayıtlarınızı karşılaştırın. Kaçırılan olayları bu şekilde yakalarsınız.
Üçüncü madde sıkça atlanır ama webhook'a tek başına güvenmek, sessizce kaçırılan olaylara yol açar.
Sistem Entegrasyonu
E-posta olayları yalnızca liste yönetimini ilgilendirmez. Diğer sistemlerinize aktarıldığında değer üretir:
- CRM. Müşteri kaydında e-posta etkileşim geçmişi görünsün. Satış ekibi, müşterinin hangi iletileri açtığını bilsin.
- Destek sistemi. Müşteri "e-posta almadım" dediğinde, iletinin teslim edilip edilmediğini anında görebilin. Bu, destek süresini belirgin biçimde kısaltır.
- Uygulama içi bildirim. Kullanıcının e-posta adresi geri dönüyorsa, uygulama içinde uyarı gösterip güncellemesini isteyin.
- Analitik. Hangi kampanya hangi dönüşümü üretti?
İkinci ve üçüncü maddeler doğrudan operasyonel değer üretir: destek yükünü azaltır ve geçersiz adresleri kaynağında düzeltir.
Olay Akışını İzleyin
Webhook entegrasyonu kurulduktan sonra kendisi de izlenmelidir:
- Olay akışı devam ediyor mu? Uzun süre hiç olay gelmiyorsa entegrasyon bozulmuş olabilir.
- İşleme hataları var mı? Uç noktanız hata veriyorsa olaylar işlenmiyor demektir.
- Olay oranlarında anormallik var mı? Geri dönme veya şikayet olaylarında ani artış, uyarı üretmelidir.
Birinci madde özellikle sinsidir: bozulmuş bir entegrasyon hiçbir hata üretmez, sadece sessiz kalır — ve siz listenizin temizlendiğini sanmaya devam edersiniz. Bu yüzden sağlayıcı seçerken olay akışı sunup sunmadığına bakın; geri bildirim verisini aktaran bir e-posta gönderim altyapısı, otomatik hijyenin ön koşuludur.
Sonuç
E-posta olaylarına otomatik tepki vermek, liste hijyenini sürdürülebilir kılan tek yöntemdir — elle yapılan temizlik ölçek büyüdüğünde yapılmaz olur. Kurarken iki nokta kritiktir: webhook uç noktasında imza doğrulaması (bu uç nokta sisteminizde veri siliyor, korumasız bırakılamaz) ve aynı olayın iki kez işlenmesine dayanıklı bir tasarım. Ayrıca webhook'a tek başına güvenmeyin; periyodik mutabakat, kaçırılan olayları yakalar. Olay verisini CRM ve destek sisteminize aktarmak ise ek bir operasyonel kazanç sağlar.
Sıkça Sorulan Sorular (SSS)
Webhook entegrasyonu şart mı?
Düşük hacimde panelden elle takip mümkündür. Ancak ölçek büyüdükçe elle temizlik yapılmaz hâle gelir ve geri dönenlere göndermeye devam etmek itibarınızı zedeler. Kalıcı geri dönme, şikayet ve abonelikten çıkma olayları için otomasyon pratikte gereklidir.
Webhook uç noktam güvenli mi?
İmza doğrulaması yapıyorsa evet. Yapmıyorsa herkes sahte olaylar gönderip abonelerinizi silebilir veya listenizi bozabilir. Bu uç nokta sisteminizde veri değiştirdiği için imza doğrulaması olmadan yayınlanmamalıdır.
Olay kaçırırsam ne olur?
Örneğin bir şikayet olayını kaçırırsanız, şikayet eden kişiye göndermeye devam edersiniz — bu, itibarınıza ciddi zarar verir. Bu yüzden periyodik mutabakat yapmak, webhook'a tek başına güvenmekten daha güvenlidir.
Açılma takibi güvenilir mi?
Sınırlı. Açılma, iletiye gömülü küçük bir görselin yüklenmesiyle tespit edilir; görselleri engelleyen istemcilerde sayılmaz, gizlilik korumalı istemcilerde ise açılmadığı hâlde sayılabilir. Mutlak değere değil eğilime bakın — ani düşüş, teslimat sorununun erken göstergesidir.
