Bir Yapay Zekâ Sohbet Ürününde Yavaş Yanıtlar ile Kullanıcı Kaybı (Churn) Nasıl Ayırt Edilir?
İnsanlar kendi hızlarında yanıt veriyorsa, bir yapay zekâ sohbetindeki uzun bir ara, onların ayrıldığını göstermek için yeterli değildir. Tercih edilen yavaş bir yanıt ritmini bir iletim sorunundan veya tamamlanmamış bir görevden ayırt etmek için, kişinin açık yanıt tercihini mesaj iletiminden ve görev durumundan ayrı olarak kaydedin. Tek başına sessizliği terk edilme kanıtı olarak değil, bilinmeyen bir durum olarak değerlendirin.
Geçen süre tek başına kullanıcıları neden yanlış sınıflandırır?
Bir zaman aralığını ölçmek kolaydır, ancak bu süre boyunca ne olduğunu açıklamaz. Birisi daha sonra dönmeyi seçmiş olabilir; bir bildirim cihaza ulaşmamış olabilir; uygulama tamamlanmış bir görevi kaydetmemiş olabilir veya gözlemlenecek yeni bir işlem olmayabilir. Bu olasılıklar farklı ürün yanıtları gerektirir; dolayısıyla bunları tek bir "etkin değil" etiketi altında birleştirmek, altta yatan verilerin yorumlanmasını zorlaştırır.
Mesajlaşma sistemlerinin kendileri de iletim aşamalarını birbirinden ayırır. Firebase Cloud Messaging gönderimleri, Android uygulaması alımlarını, bildirim gösterimlerini ve açılmaları ayrı metrikler olarak raporlar; bir gönderim, bir kişinin mesajı gördüğü anlamına gelmek yerine, mesajın kuyruğa alındığı veya APNs gibi bir servise iletildiği anlamına gelebilir. Firebase ayrıca bazı raporlamaların gecikmeli olduğunu ve toplu iletim verilerinin kapsam sınırları bulunduğunu belirtir. Firebase: Understanding message delivery
Bu ayrım, analitik için faydalı bir kural önerir: Bir kişinin yanıt verme temposunu asla gönderim isteği gibi yukarı akış (upstream) bir olaydan çıkarmayın ve eksik bir açılmayı veya yanıtı asla başarısız bir iletimin kanıtı olarak görmeyin. Ürünün gözlemleyebildiği şeyleri yakalayın ve gözlemlenmeyen sonuçları bilinmiyor olarak bırakın.
Kullanıcıların tercih ettikleri yanıt temposunu belirtmelerine izin verin
Pratik bir soruyu yanıtlayan basit, isteğe bağlı bir tercih sunun: Kullanıcı, ürünün ne zaman bir yanıt istemesini veya takip etmesini ister? Ürüne uygunsa "hazır olduğumda", "bugün ilerleyen saatlerde" veya "belirlediğim bir günde hatırlat" gibi anlaşılır seçenekler kullanın. Kesin seçenekler bir tasarım kararıdır, herhangi bir kullanıcının neyi tercih ettiğine dair bir iddia değildir.
Seçimi, güncelleme zamanıyla ve geçerliyse bir sona erme veya bitiş koşuluyla birlikte bir kullanıcı tercihi olarak saklayın. Bir tercih, o kişinin ürünü seçtiği kullanım biçimi hakkında kalıcı bir bağlamdır; bir yanıt aralığı ise tek bir konuşma veya mesaj hakkındaki bir olgudur. Analitik platformları da kullanıcıyı tanımlayan kullanıcı özellikleri ile belirli bir eylemi tanımlayan olay özellikleri arasında benzer bir ayrım yapar. Amplitude: User properties and event properties
Tercihin değiştirilmesini veya temizlenmesini kolaylaştırın. Gözlemlenen ortalama yanıt sürelerini varsayılan tercihlere dönüştürmekten kaçının: Geçmiş bir model geçmişteki davranışı tanımlamaya yardımcı olabilir, ancak yalnızca açık bir seçim belirtilen bir tercihi gösterebilir. Kayıtlı bir tercih yoksa, kişi adına varsayılan bir tempo atamak yerine değeri bilinmiyor olarak kaydedin.
Konuşma görevlerini gözlemlenebilir durumlar olarak takip edin
Sistemin doğrulayabileceği eylemler etrafında küçük bir görev durumları kümesi tanımlayın. Örneğin: waiting_for_user, waiting_for_service, ready_for_user, completed ve cancelled. Bir durumu yalnızca bir olay veya sistem yanıtı bunu desteklediğinde kullanın. Bir kullanıcının mesaj göndermesi bir görevi waiting_for_service durumuna taşıyabilir; başarılı bir yanıt onu ready_for_user haline getirebilir; açık bir tamamlama eylemi onu completed olarak işaretleyebilir. Bir yanıt veya durum güncellemesi başarısız olursa, hatayı kaydedin ve sonraki bir olay netleştirene kadar görevi çözümlenmemiş olarak tutun.
Bir analistin dizilimi yeniden oluşturabilmesi için bu olaylara bir konuşma veya görev tanımlayıcısı ekleyin. Olay zamanını, olay türünü, mevcut görev durumunu ve ilgili teknik sonucu kaydedin. Kullanıcı düzeyindeki tercihi görev bazındaki ayrıntılardan ayrı tutun: "hazır olduğunda yanıt vermeyi tercih eder" konuşmalar genelinde geçerli olabilirken, "bu görev bir kullanıcı eylemi bekliyor" ifadesi mevcut tek bir etkileşimi tanımlar. Olay tabanlı analitikte, olay özellikleri bir eylem anındaki bağlamı yakalarken, kullanıcı özellikleri zaman içinde değişebilen nitelikleri tanımlar. Amplitude: User properties and event properties
Bu ayrım geçmişe dönük yorumlamayı da korur. Biri bir tercihi değiştirdiğinde, önceki olaylarda eski değeri koruyun ve sonraki olaylar için yeni değeri kullanın; geçmişi sanki yeni tercih her zaman geçerliymiş gibi yeniden yazmayın. Amplitude'un belgeleri, kullanıcı özellikleri için zamana duyarlı bu davranışı açıklar. Amplitude: User properties and event properties
İletim sağlığını kullanıcının eylemlerinden ayırın
Giden her sohbet mesajı veya bildirim için entegrasyonun gerçekten sunduğu aşamaları kaydedin: gönderim denendi, mesajlaşma servisi tarafından kabul edildi, varsa uygulamaya iletildi, varsa görüntülendi, varsa açıldı ve bilinen herhangi bir hata. Platformun sağlamadığı bir iletim makbuzu uydurmayın. Apple platformlarında APNs, bir kullanıcının cihazlarına uzaktan bildirim iletimini yönetir; bu sistem rolü, kişinin bildirimi açtığına dair bir kayıttan farklıdır. Apple: User Notifications
Altyapı sonuçlarını altyapı sinyalleri olarak kullanın. Örneğin, başarısız bir istek, sağlayıcı reddi, zaman aşımı veya gecikmiş bir kuyruk, iletim veya servis sağlığının araştırılmasını gerektirmelidir. Başarılı bir gönderim isteği yalnızca o aşamanın kanıtıdır. Firebase, gönderim istatistiğinin iletim için kuyruğa alınan veya başka bir servise aktarılan bir mesajı temsil edebileceğini ve toplu Android aktarım verilerinin her bir mesajı değil genel eğilimleri tanımladığını açıklar. Firebase: Understanding message delivery
Dahili mesaj işleme için onayların (acknowledgments) da dikkatle okunması gerekir. Google Cloud Pub/Sub, mesajları onaylanana kadar beklemede (outstanding) olarak tanımlar ve onaylanmamış mesajların bir son tarihten sonra yeniden iletilebileceğini belirtir; mesajlar birden fazla kez de iletilebilir. Bu, olay işlemeyi kopyalara karşı toleranslı hale getirmek ve eksik bir işleme onayını bir kullanıcının eksik yanıtından ayırt etmek için faydalı bir hatırlatmadır. Google Cloud: Subscription overview
İhtiyatlı bir sınıflandırma kuralı kullanın
Pratik bir karar desteği, etiketlerin kapsamını dar ve kanıta dayalı tutabilir:
Gözlemlenen kanıt: Kişi bir yanıt zamanlama tercihi seçti ve daha yeni bir eylem gözlemlenmedi; Uygun analitik etiketi: Tercih kaydedildi; yanıt henüz gözlemlenmedi; Neyi kanıtlamaz: Kişinin ayrıldığını veya iletimin başarısız olduğunu
Gözlemlenen kanıt: Bir servis isteği veya mesaj iletim aşaması başarısız oldu ya da zaman aşımına uğradı; Uygun analitik etiketi: Kaydedilen aşamada teknik sorun; Neyi kanıtlamaz: Kişinin neden yanıt vermediğini
Gözlemlenen kanıt: Ürünün bir kullanıcı eylemini bekleyen onaylanmış bir sonraki adımı var; Uygun analitik etiketi: Görev kullanıcı eylemini bekliyor; Neyi kanıtlamaz: Görevin terk edildiğini
Gözlemlenen kanıt: Bir tamamlama, iptal veya başka bir nihai eylem kaydedildi; Uygun analitik etiketi: Gözlemlendiği gibi tamamlandı veya iptal edildi; Neyi kanıtlamaz: Gelecekteki kullanıma dair daha geniş kapsamlı bir yargıyı
Gözlemlenen kanıt: Kanıt eksik, gecikmiş veya çelişkili; Uygun analitik etiketi: Bilinmiyor veya uzlaştırma gerektiriyor; Neyi kanıtlamaz: Herhangi bir kesin davranışsal açıklamayı
"Kullanıcı kaybı (churn)" etiketi, tanımlanmış bir ürün düzeyi kural ve bu kural için yeterli kanıt gerektirmelidir; mesajlar arasındaki uzun bir aralığın eşanlamlısı olmamalıdır. Bir gösterge paneli kanıtlar tamamlanmadan önce bir duruma ihtiyaç duyuyorsa, "yakın zamanda gözlemlenen yanıt yok" ifadesi, kişinin neden orada olmadığına dair bir iddiadan daha kesindir. Bu durumu geçici olarak değerlendirin ve gecikmiş olaylar geldiğinde revize edin.
Analizi tercih ve görev durumu etrafında oluşturun
Faydalı bir kohort analizi, açıkça daha yavaş bir tempoyu seçen kişilerin belirtilen görevlerini bu tercihle tutarlı bir zaman diliminde tamamlayıp tamamlamadığını sorgular. Benzeri benzerle karşılaştırın: seçilen tercih ve görev türüne göre gruplayın; iletim hatalarını, çözümlenmemiş servis isteklerini ve tamamlama olaylarını ayrı ayrı inceleyin. Bir kişinin sessiz kaldığı dönemi ürün genelinde bir başarısızlık sinyaline dönüştürmeyin; karşılaştırılabilir görevler ve iletim koşulları genelinde modeller arayın.
Örneğin, bir kişi "hazır olduğumda" seçeneğini belirlerse, bir konuşma açık kalırsa ve üründe kaydedilmiş bir iletim hatası ya da yeni bir kullanıcı eylemi yoksa, savunulabilir durum "yanıt gözlemlenmedi; tercih kayıtlı; görev hâlâ açık" şeklindedir. Giden yanıtta kayıtlı bir servis hatası varsa, kişinin tercihi bilinse bile durum bu hatayı yansıtmalıdır. Bu, yukarıdaki olay modeline dayalı örnek bir sınıflandırmadır, ölçülmüş bir ürün sonucu değildir.
Bir metriği kararlar için kullanmadan önce, olayların geç gelip gelmediğini, yinelenip yinelenmediğini veya belirli platformlarda eksik olup olmadığını kontrol edin. Firebase, bazı iletim raporlamalarının geciktiğini ve toplu metriklerin sonuçları atlayabileceğini veya yuvarlayabileceğini belirtir; Pub/Sub en az bir kez iletimi ve olası yeniden iletimi belgeler. Olayları kararlı mesaj veya görev tanımlayıcılarıyla uzlaştırın ve bir yeniden denemeyi ikinci bir kullanıcı eylemi olarak saymaktan kaçının. Firebase: Understanding message delivery, Google Cloud: Subscription overview
Takip sürecini kişinin seçimine göre tasarlayın
Takip ürünün bir parçasıysa, kişinin seçtiği tercihi yansıtmasını sağlayın. Seçilen bir hatırlatma zamanı bir hatırlatmayı yönetebilir; "hazır olduğumda" ise zamana dayalı bir dürtme (nudge) olmaması anlamına gelebilir. Kişiye bu seçimi değiştirmesi için net bir yol sunun ve mevcut durumu konuşmada görünür kılın, böylece ürünün kendilerini mi beklediğini, bir servisi mi beklediğini yoksa işlemin bittiğini mi anlayabilsinler.
Analitiği teknik kusurları bulmak ve görev tamamlamayı anlamak için kullanın, sessizlikten kesinlik üretmek için değil. Açık tercihler bağlam sağlar, görev durumları hangi işin kaldığını gösterir ve iletim olayları hangi teknik aşamaların bilindiğini ortaya koyar. Bu parçalardan biri eksik olduğunda, etiketteki belirsizliği koruyun. Bu, ne zaman döneceğinin kontrolünü kullanıcıya bırakırken, yavaş yanıtların daha faydalı bir açıklamasını sunar.