Mesaj Kimliği ve Konuşma Zinciri: Yanıtlar Neden Ayrı Görünüyor?
Müşteriyle e-posta üzerinden yazışıyorsunuz ama her yanıt gelen kutusunda ayrı bir ileti olarak duruyor. Konuşmayı takip etmek imkânsız hâle geliyor. Bu, e-posta istemcisinin değil, iletilerinizin taşıdığı başlıkların sorunudur.
Bu yazı, konuşma zincirini oluşturan başlıkları ele alıyor.
Her İletinin Bir Kimliği Var
- Gönderen sistem benzersiz bir kimlik üretir.
- Bu kimlik iletiyle birlikte taşınır.
- Yanıtlar bu kimliğe atıfta bulunur.
Üçüncü adım zincirin temelidir: bir yanıt, hangi iletiye cevap verdiğini konu satırıyla değil, atıf başlıklarındaki mesaj kimliğiyle bildirir — istemciler konuşmaları bu bilgiye göre gruplar.
Konu satırı benzerliği yalnızca yardımcı bir ipucudur.
Bazı istemciler ona da bakar ama esas ölçüt kimliktir.
Kimlik eksikse gruplama yapılamaz.
Kimlik Üretilmezse
| Durum | Sonuç |
|---|---|
| Kimlik hiç yok | Sunucu kendi üretir |
| Kimlik geçersiz biçimde | Şüpheli sayılır |
| Aynı kimlik tekrar kullanılır | İleti yok sayılabilir |
Üçüncü satır ciddi bir teslimat sorunu üretir: aynı mesaj kimliğini birden fazla iletide kullanmak, alıcı sistemin bunu daha önce teslim edilmiş bir kopya sanıp sessizce atmasına yol açar — ileti kaybolur ve hiçbir hata görünmez.
Bu, şablon sistemlerinde sabit kimlik yazıldığında yaşanır.
İkinci satır ise istenmeyen posta puanını artırır.
Kimlik, alan adınızı içeren geçerli bir biçimde olmalıdır.
İki Atıf Başlığı
- Doğrudan yanıtlanan iletinin kimliği.
- Zincirdeki tüm kimliklerin listesi.
İkinci madde uzun konuşmalarda belirleyicidir: yalnızca son iletiye atıf yapmak, zincirin ortasından bir ileti kaybolduğunda konuşmanın ikiye bölünmesine yol açar — tüm kimlikleri listeleyen başlık bu riski ortadan kaldırır.
Liste, konuşma büyüdükçe uzar.
Çok uzadığında ortadaki kimlikler kısaltılabilir.
Başlangıç ve son kimlikler her zaman korunmalıdır.
Otomatik İletilerde
- Bildirimler genellikle zincirsiz gönderilir.
- Her biri ayrı görünür.
- Zincirleme daha okunaklıdır.
Üçüncü madde kullanıcı deneyimini belirgin biçimde iyileştirir: aynı siparişe ait onay, kargo ve teslimat bildirimlerini aynı zincirde göndermek, kullanıcının tüm süreci tek bir konuşma altında görmesini sağlar — gelen kutusu üç ayrı iletiyle dolmaz.
Bunun için ilk iletinin kimliği saklanmalıdır.
Sonraki bildirimler ona atıf yapar.
Bu, sipariş kaydında tutulan basit bir alandır.
Destek Sisteminde
| Yöntem | Güvenilirlik |
|---|---|
| Konu satırındaki numara | Düşük |
| Atıf başlıkları | Yüksek |
| Benzersiz yanıt adresi | Çok yüksek |
İkinci ve üçüncü satırların birlikte kullanımı en sağlam çözümdür: atıf başlıkları çoğu istemcide korunur ama bazı web arayüzleri yeni bir ileti başlatıldığında bunları taşımaz — benzersiz yanıt adresi bu boşluğu kapatır.
İki yöntem birbirini tamamlar.
Birinci satır ise yalnızca son çare olarak kullanılmalıdır.
Konu satırı kullanıcı tarafından değiştirilebilir.
Konu Satırı Ön Ekleri
- Yanıt ön eki dilden dile değişir.
- Üst üste birikebilir.
- Temizlik gerekir.
İkinci madde uzun yazışmalarda görünür bir soruna dönüşür: farklı dillerdeki istemciler farklı yanıt ön ekleri eklediği için konu satırı zamanla üst üste yığılmış ön eklerle dolar ve gerçek konu görünmez hâle gelir.
Bu, uluslararası yazışmalarda sık yaşanır.
Ayrıştırma yaparken bu ön ekler temizlenmelidir.
Yalnızca tek bir ön ek korunmalıdır.
Kopya Alıcılar
- Yanıtla ve tümünü yanıtla farklıdır.
- Gizli kopya yanıtlarda görünmez.
- Zincir kopabilir.
İkinci madde beklenmedik kopukluk üretir: gizli kopya olarak eklenen bir alıcı, sonraki yanıtları hiç görmez çünkü yanıtlayan kişi onun varlığından haberdar değildir — konuşma o kişi için ilk iletide donar.
Bu nedenle takip edilmesi gereken adresler gizli kopyaya konmamalıdır.
Üçüncü madde ise farklı istemcilerin davranış farkından doğar.
Yanıt adresini açıkça belirtmek bu riski azaltır.
Doğrulama
- Kendinize bir zincir kurun.
- Farklı istemcilerde bakın.
- Başlıkları inceleyin.
İkinci madde zorunludur çünkü davranış tek tip değildir: bir istemcide düzgün gruplanan konuşma, başka bir istemcide ayrı ayrı görünebilir — gruplama kuralları istemciden istemciye değişir ve tek bir testle sonuca varılamaz.
En yaygın üç istemcide test etmek yeterlidir.
Üçüncü madde ise başlıkların gerçekten yazıldığını doğrular.
Kodda tanımlanan bir başlık, gönderim sırasında düşebilir.
Bildirim akışlarınızın okunabilir bir konuşma oluşturması teslimat kadar önemlidir; smarthost barındırma hizmeti ile gönderim başlıklarınızı tam denetimde tutabilirsiniz.
Sonuç
Yanıtların ayrı görünmesinin nedeni konu satırı değildir: bir yanıt, hangi iletiye cevap verdiğini atıf başlıklarındaki mesaj kimliğiyle bildirir. Her ileti için benzersiz kimlik üretin — aynı kimliği tekrar kullanmak, alıcı sistemin iletiyi kopya sanıp sessizce atmasına yol açar — zincirdeki tüm kimlikleri listeleyin ve ilgili bildirimleri aynı zincirde gönderin.
Sıkça Sorulan Sorular (SSS)
Yanıtlar neden ayrı ileti olarak görünüyor?
Atıf başlıkları eksik veya yanlış. Bir yanıt, hangi iletiye cevap verdiğini konu satırıyla değil mesaj kimliğiyle bildirir; istemciler konuşmaları bu bilgiye göre gruplar. Konu benzerliği yalnızca yardımcı bir ipucudur.
Aynı mesaj kimliğini kullanmak sorun mu?
Ciddi sorun. Alıcı sistem bunu daha önce teslim edilmiş bir kopya sanıp sessizce atabilir; ileti kaybolur ve hiçbir hata görünmez. Bu, şablon sistemlerinde sabit kimlik yazıldığında yaşanır.
Sipariş bildirimlerini zincirlemeli miyim?
Zincirlemek okunabilirliği artırır. Onay, kargo ve teslimat bildirimlerini aynı zincirde göndermek kullanıcının tüm süreci tek konuşmada görmesini sağlar. Bunun için ilk iletinin kimliğini sipariş kaydında saklayıp sonrakilerde ona atıf yapın.
Gizli kopya alıcılar neden yanıtları görmüyor?
Yanıtlayan kişi onların varlığından haberdar değildir, bu yüzden yanıt onlara gitmez ve konuşma o kişiler için ilk iletide donar. Takip edilmesi gereken adresleri gizli kopyaya koymayın.
