किसी AI चैट प्रोडक्ट में धीमी प्रतिक्रियाओं और चर्न के बीच अंतर कैसे पहचानें

केवल बीता हुआ समय ही उपयोगकर्ताओं को गलत श्रेणी में क्यों डालता है

समय के अंतराल को मापना आसान है, लेकिन यह स्पष्ट नहीं करता कि उस दौरान क्या हुआ। हो सकता है किसी ने बाद में लौटने का विकल्प चुना हो; संभव है कि कोई सूचना (नोटिफिकेशन) डिवाइस तक न पहुंची हो; हो सकता है ऐप ने पूरा हुआ कार्य रिकॉर्ड न किया हो; या फिर देखने के लिए कोई नई गतिविधि ही न हो। इन सभी संभावनाओं के लिए अलग-अलग उत्पाद प्रतिक्रियाओं की आवश्यकता होती है, इसलिए उन्हें एक ही “निष्क्रिय” (inactive) लेबल में मिला देने से अंतर्निहित डेटा की व्याख्या करना कठिन हो जाता है।

मैसेजिंग सिस्टम स्वयं डिलीवरी के चरणों में अंतर करते हैं। Firebase Cloud Messaging सेंड्स, एंड्रॉइड ऐप रिसिप्ट, नोटिफिकेशन इम्प्रेशन्स और ओपन्स को अलग-अलग पैमानों के रूप में रिपोर्ट करता है; सेंड का अर्थ यह हो सकता है कि संदेश कतार (queue) में था या APNs जैसी सेवा को भेजा गया था, न कि यह कि किसी व्यक्ति ने इसे देखा ही है। Firebase यह भी नोट करता है कि कुछ रिपोर्टिंग में देरी होती है और इसके समग्र डिलीवरी डेटा की कवरेज सीमाएं हैं। Firebase: Understanding message delivery

यह अंतर एक उपयोगी एनालिटिक्स नियम का सुझाव देता है: किसी व्यक्ति के उत्तर देने की गति का अनुमान कभी भी सेंड रिक्वेस्ट जैसे अपस्ट्रीम इवेंट से न लगाएं, और खुले न होने या उत्तर न मिलने को कभी भी असफल डिलीवरी का प्रमाण न मानें। उत्पाद जो देख सकता है उसे कैप्चर करें, और जो परिणाम नहीं देखे जा सके उन्हें अज्ञात छोड़ दें।

लोगों को अपनी पसंदीदा उत्तर देने की गति बताने दें

एक सरल, वैकल्पिक वरीयता प्रदान करें जो एक व्यावहारिक प्रश्न का उत्तर देती हो: वह व्यक्ति कब चाहेगा कि उत्पाद उसे उत्तर देने या फॉलो-अप के लिए आमंत्रित करे? समझने में आसान विकल्पों का उपयोग करें जैसे "जब मैं तैयार होऊं," "आज बाद में," या "चुने गए दिन पर मुझे याद दिलाएं," यदि वे विकल्प उत्पाद के अनुकूल हों। सटीक विकल्प एक डिज़ाइन निर्णय हैं, न कि इस बात का दावा कि कोई विशेष उपयोगकर्ता क्या पसंद करता है।

इस चयन को उपयोगकर्ता की वरीयता के रूप में उसके अपडेट समय और, जहां लागू हो, समाप्ति या अंतिम स्थिति के साथ संग्रहीत करें। वरीयता उस व्यक्ति द्वारा उत्पाद के चुने गए उपयोग के बारे में एक स्थायी संदर्भ है; उत्तर का अंतराल किसी एक बातचीत या संदेश से जुड़ा तथ्य है। एनालिटिक्स प्लेटफ़ॉर्म यूज़र प्रॉपर्टीज (जो उपयोगकर्ता का वर्णन करती हैं) और इवेंट प्रॉपर्टीज (जो किसी विशिष्ट क्रिया का वर्णन करती हैं) के बीच ऐसा ही अंतर करते हैं। Amplitude: User properties and event properties

वरीयता को बदलना या हटाना आसान बनाएं। देखी गई औसत प्रतिक्रिया समय को अनुमानित प्राथमिकताओं में बदलने से बचें: एक ऐतिहासिक पैटर्न पिछले व्यवहार का वर्णन करने में मदद कर सकता है, लेकिन केवल एक स्पष्ट विकल्प ही व्यक्त वरीयता को इंगित कर सकता है। यदि कोई सहेजी गई वरीयता नहीं है, तो व्यक्ति की ओर से डिफ़ॉल्ट गति निर्दिष्ट करने के बजाय मान को अज्ञात के रूप में रिकॉर्ड करें।

बातचीत के कार्यों को अवलोकन योग्य स्थितियों (ऑब्जर्वेबल स्टेट्स) के रूप में ट्रैक करें

सिस्टम द्वारा सत्यापित की जा सकने वाली कार्रवाइयों के आधार पर कार्य स्थितियों (टास्क स्टेट्स) का एक छोटा सेट परिभाषित करें। उदाहरण के लिए: waiting_for_user, waiting_for_service, ready_for_user, completed, और cancelled। किसी स्थिति का उपयोग केवल तभी करें जब कोई इवेंट या सिस्टम रिस्पॉन्स उसका समर्थन करता हो। उपयोगकर्ता द्वारा संदेश भेजने पर कार्य waiting_for_service में जा सकता है; एक सफल प्रतिक्रिया इसे ready_for_user बना सकती है; स्पष्ट रूप से पूर्ण करने की कार्रवाई इसे completed चिह्नित कर सकती है। यदि कोई प्रतिक्रिया या स्थिति अपडेट विफल हो जाती है, तो विफलता को रिकॉर्ड करें और कार्य को तब तक अनसुलझा रखें जब तक कि बाद का कोई इवेंट इसे स्पष्ट न कर दे।

इन इवेंट्स के साथ एक बातचीत या टास्क आइडेंटिफायर जोड़ें ताकि एक विश्लेषक अनुक्रम को दोबारा बना सके। इवेंट का समय, इवेंट का प्रकार, वर्तमान कार्य स्थिति और प्रासंगिक तकनीकी परिणाम रिकॉर्ड करें। उपयोगकर्ता-स्तरीय वरीयता को प्रति-कार्य विवरणों से अलग रखें: “तैयार होने पर उत्तर देना पसंद करता है” बातचीत में लागू हो सकता है, जबकि “यह कार्य उपयोगकर्ता की कार्रवाई की प्रतीक्षा कर रहा है” एक वर्तमान बातचीत का वर्णन करता है। इवेंट-आधारित एनालिटिक्स में, इवेंट प्रॉपर्टीज किसी कार्रवाई के समय के संदर्भ को कैप्चर करती हैं, जबकि यूज़र प्रॉपर्टीज उन विशेषताओं का वर्णन करती हैं जो समय के साथ बदल सकती हैं। Amplitude: User properties and event properties

यह अलगाव ऐतिहासिक व्याख्या की भी रक्षा करता है। जब कोई वरीयता बदलता है, तो पुराने इवेंट्स पर पुराने मान को सुरक्षित रखें और बाद के इवेंट्स के लिए नए मान का उपयोग करें; अतीत को इस तरह से न लिखें जैसे कि नई वरीयता हमेशा लागू थी। Amplitude का दस्तावेज़ीकरण यूज़र प्रॉपर्टीज के लिए इस समय-जागरूक (time-aware) व्यवहार का वर्णन करता है। Amplitude: User properties and event properties

डिलीवरी की स्थिति को उपयोगकर्ता की कार्रवाइयों से अलग करें

प्रत्येक आउटबाउंड चैट संदेश या सूचना के लिए, उन चरणों को रिकॉर्ड करें जो एकीकरण वास्तव में प्रदर्शित करता है: सेंड का प्रयास किया गया, मैसेजिंग सेवा द्वारा स्वीकार किया गया, यदि उपलब्ध हो तो ऐप पर डिलीवर किया गया, यदि उपलब्ध हो तो प्रदर्शित किया गया, यदि उपलब्ध हो तो खोला गया, और कोई भी ज्ञात त्रुटि। ऐसा कोई डिलीवरी प्रमाण न बनाएं जो प्लेटफ़ॉर्म प्रदान नहीं करता है। Apple प्लेटफ़ॉर्म पर, APNs उपयोगकर्ता के उपकरणों पर रिमोट नोटिफिकेशन डिलीवरी को संभालता है; उस सिस्टम की भूमिका इस रिकॉर्ड से भिन्न होती है कि व्यक्ति ने सूचना को खोला है। Apple: User Notifications

इन्फ्रास्ट्रक्चर के परिणामों को इन्फ्रास्ट्रक्चर संकेतों के रूप में उपयोग करें। उदाहरण के लिए, एक विफल अनुरोध, प्रदाता द्वारा अस्वीकृति, टाइमआउट, या विलंबित कतार को डिलीवरी या सेवा की स्थिति की जांच शुरू करनी चाहिए। एक सफल सेंड रिक्वेस्ट केवल उसी चरण का प्रमाण है। Firebase बताता है कि इसका सेंड स्टैटिस्टिक डिलीवरी के लिए कतारबद्ध किए गए संदेश या किसी अन्य सेवा को भेजे गए संदेश का प्रतिनिधित्व कर सकता है, और इसका समग्र एंड्रॉइड ट्रांसपोर्ट डेटा हर व्यक्तिगत संदेश के बजाय व्यापक रुझानों का वर्णन करता है। Firebase: Understanding message delivery

आंतरिक संदेश प्रसंस्करण (इंटरनल मैसेज प्रोसेसिंग) के लिए, पावती (acknowledgments) को भी ध्यान से पढ़ने की आवश्यकता होती है। Google Cloud Pub/Sub संदेशों को तब तक बकाया (outstanding) बताता है जब तक कि उन्हें स्वीकार न कर लिया जाए और नोट करता है कि पावती न मिलने वाले संदेशों को समय सीमा के बाद फिर से डिलीवर किया जा सकता है; संदेश एक से अधिक बार भी डिलीवर किए जा सकते हैं। यह इवेंट प्रोसेसिंग को प्रतियों (डुप्लिकेट्स) के प्रति सहनशील बनाने और प्रोसेसिंग की अनुपस्थित पावती को उपयोगकर्ता के लापता उत्तर से अलग करने का एक उपयोगी स्मरण है। Google Cloud: Subscription overview

एक सतर्क वर्गीकरण नियम का उपयोग करें

एक व्यावहारिक निर्णय सहायता लेबलों को सीमित और साक्ष्य-आधारित रख सकती है:

देखा गया साक्ष्य: व्यक्ति ने उत्तर समय की वरीयता चुनी, और कोई नई कार्रवाई नहीं देखी गई; उपयुक्त एनालिटिक्स लेबल: वरीयता दर्ज की गई; उत्तर अभी तक नहीं देखा गया; यह क्या स्थापित नहीं करता है: कि व्यक्ति छोड़ चुका है, या डिलीवरी विफल रही

देखा गया साक्ष्य: सेवा अनुरोध या संदेश डिलीवरी चरण विफल रहा या समय समाप्त हो गया; उपयुक्त एनालिटिक्स लेबल: दर्ज किए गए चरण पर तकनीकी समस्या; यह क्या स्थापित नहीं करता है: व्यक्ति ने उत्तर क्यों नहीं दिया

देखा गया साक्ष्य: उत्पाद में उपयोगकर्ता की कार्रवाई की प्रतीक्षा में एक पुष्ट अगला कदम है; उपयुक्त एनालिटिक्स लेबल: कार्य उपयोगकर्ता की कार्रवाई की प्रतीक्षा कर रहा है; यह क्या स्थापित नहीं करता है: कि कार्य छोड़ दिया गया था

देखा गया साक्ष्य: पूर्णता, रद्दीकरण या अन्य अंतिम कार्रवाई दर्ज की गई है; उपयुक्त एनालिटिक्स लेबल: पूर्ण या रद्द, जैसा देखा गया; यह क्या स्थापित नहीं करता है: भविष्य के उपयोग के बारे में कोई व्यापक निर्णय

देखा गया साक्ष्य: साक्ष्य गायब है, विलंबित है, या विरोधाभासी है; उपयुक्त एनालिटिक्स लेबल: अज्ञात या समाधान की आवश्यकता है; यह क्या स्थापित नहीं करता है: कोई भी आश्वस्त व्यवहारिक स्पष्टीकरण

"चर्न" लेबल के लिए उत्पाद-स्तर पर एक निश्चित नियम और उस नियम के लिए पर्याप्त साक्ष्य की आवश्यकता होनी चाहिए; यह संदेशों के बीच लंबे अंतराल का पर्याय नहीं होना चाहिए। यदि किसी डैशबोर्ड को साक्ष्य पूरा होने से पहले किसी स्थिति की आवश्यकता होती है, तो व्यक्ति के अनुपस्थित होने के कारणों के दावे की तुलना में "हाल ही में कोई उत्तर नहीं देखा गया" अधिक सटीक है। उस स्थिति को अस्थायी मानें और विलंबित इवेंट्स के आने पर इसे संशोधित करें।

वरीयता और कार्य स्थिति के इर्द-गिर्द विश्लेषण तैयार करें

एक उपयोगी कोहोर्ट विश्लेषण यह पूछता है कि क्या वे लोग जो स्पष्ट रूप से धीमी गति चुनते हैं, उस वरीयता के अनुरूप समय सीमा में अपने बताए गए कार्यों को पूरा करते हैं। समान की तुलना समान से करें: चुनी गई वरीयता और कार्य प्रकार के आधार पर समूहीकृत करें, और डिलीवरी विफलताओं, अनसुलझे सेवा अनुरोधों और पूर्णता इवेंट्स का अलग से निरीक्षण करें। किसी एक व्यक्ति के शांत अंतराल को उत्पाद-व्यापी विफलता संकेत में न बदलें; तुलनीय कार्यों और वितरण स्थितियों में पैटर्न की तलाश करें।

उदाहरण के लिए, यदि कोई व्यक्ति "जब मैं तैयार होऊं" चुनता है, बातचीत खुली रहती है, और उत्पाद में कोई दर्ज डिलीवरी त्रुटि या नई उपयोगकर्ता कार्रवाई नहीं होती है, तो उचित स्थिति होगी "कोई उत्तर नहीं देखा गया; वरीयता दर्ज है; कार्य अभी भी खुला है।" यदि आउटबाउंड प्रतिक्रिया में कोई सेवा त्रुटि दर्ज है, तो स्थिति को उस त्रुटि को दर्शाना चाहिए, भले ही व्यक्ति की वरीयता भी ज्ञात हो। यह ऊपर दिए गए इवेंट मॉडल पर आधारित एक उदाहरणात्मक वर्गीकरण है, न कि कोई मापा गया उत्पाद परिणाम।

निर्णयों के लिए किसी मीट्रिक का उपयोग करने से पहले, जांच लें कि क्या इवेंट देर से आते हैं, डुप्लिकेट होते हैं, या विशेष प्लेटफ़ॉर्म पर अनुपस्थित होते हैं। Firebase का कहना है कि कुछ डिलीवरी रिपोर्टिंग में देरी होती है और समग्र मीट्रिक्स परिणामों को छोड़ सकते हैं या गोल कर सकते हैं; Pub/Sub कम से कम एक बार डिलीवरी (at-least-once delivery) और संभावित पुनः डिलीवरी का दस्तावेजीकरण करता है। स्थिर संदेश या कार्य पहचानकर्ताओं के साथ इवेंट्स का मिलान करें, और किसी पुनः प्रयास (retry) को दूसरी उपयोगकर्ता कार्रवाई के रूप में गिनने से बचें। Firebase: Understanding message delivery, Google Cloud: Subscription overview

व्यक्ति की पसंद के इर्द-गिर्द फॉलो-अप डिज़ाइन करें

यदि फॉलो-अप उत्पाद का हिस्सा है, तो इसे उस वरीयता को प्रतिबिंबित करना चाहिए जिसे व्यक्ति ने चुना है। एक चुना हुआ रिमाइंडर समय किसी रिमाइंडर को नियंत्रित कर सकता है; "जब मैं तैयार होऊं" का अर्थ समय-आधारित नज़ (नियत समय पर याद दिलाना) की अनुपस्थिति हो सकता है। व्यक्ति को उस पसंद को बदलने का एक स्पष्ट तरीका दें, और बातचीत में वर्तमान स्थिति को दृश्यमान बनाएं ताकि वे बता सकें कि उत्पाद उनकी प्रतीक्षा कर रहा है, किसी सेवा की प्रतीक्षा कर रहा है, या समाप्त हो गया है।

एनालिटिक्स का उपयोग तकनीकी खामियों को खोजने और कार्य पूरा होने को समझने के लिए करें, न कि मौन से जबरन निश्चितता गढ़ने के लिए। स्पष्ट प्राथमिकताएं संदर्भ प्रदान करती हैं, कार्य की स्थितियां दर्शाती हैं कि क्या काम बाकी है, और डिलीवरी इवेंट्स बताते हैं कि कौन से तकनीकी चरण ज्ञात हैं। जब उनमें से कोई एक हिस्सा गायब हो, तो लेबल में अनिश्चितता बनाए रखें। यह उपयोगकर्ता को कब वापस आना है इसका नियंत्रण सौंपते हुए धीमी प्रतिक्रियाओं का अधिक उपयोगी विवरण प्रस्तुत करता है।

इस विषय को आगे पढ़ें