हम कुकीज़ का उपयोग करते हैं
हम आपके अनुभव को बेहतर बनाने, ट्रैफ़िक का विश्लेषण करने और सामग्री को वैयक्तिकृत करने के लिए कुकीज़ और समान तकनीकों का उपयोग करते हैं। आप सभी कुकीज़ स्वीकार कर सकते हैं या गैर-आवश्यक कुकीज़ को अस्वीकार कर सकते हैं।
19 Oct 2026
हर RevOps और CX लीडर ने यह प्रस्ताव सुना है: अपनी वेबसाइट को इंस्ट्रूमेंट करें, हर क्लिक को स्कोर करें, और एक साफ-सुथरा “इंटेंट स्कोर” निकल आता है जो सेल्स को बताता है कि कौन खरीदने वाला है और सपोर्ट को बताता है कि कौन चर्न करने वाला है। यह एक आकर्षक विचार है, और यह एक खास, अनुमानित तरीके से अधूरा भी है। व्यावहारिक डेटा (behavioural data) आपको बताता है कि किसी ने क्या किया। यह आपको नहीं बताता कि क्यों, और यह इस बारे में कुछ नहीं कहता कि उस ग्राहक के साथ आपके ऑर्डर सिस्टम, आपकी सपोर्ट क्यू, या आपके पिछले सर्वे में पहले ही क्या हो चुका है।
यह सुनने में जितना लगता है उससे कहीं ज्यादा मायने रखता है। एक व्यवहार-केंद्रित इंटेंट स्कोर उस ग्राहक को खुशी-खुशी “हॉट” के रूप में फ्लैग कर देगा जिसने इस हफ्ते आपका प्राइसिंग पेज पांच बार देखा है — भले ही उसकी बिलिंग शिकायत तीन दिनों से बिना सुलझे पड़ी हो। सिर्फ स्कोर के आधार पर कार्रवाई करें और आप किसी ऐसे व्यक्ति को सेल्स नज भेज देते हैं जो डबल-चार्ज को लेकर गुस्से में है। यह कोई काल्पनिक एज केस नहीं है; यह केवल-व्यवहार स्कोरिंग की डिफ़ॉल्ट विफलता की स्थिति है, और कुछ भी जोड़ने से पहले इसे समझना जरूरी है।
अपने मूल में, व्यावहारिक इंटेंट स्कोरिंग विज़िटर या लॉग-इन यूज़र द्वारा आपकी साइट या ऐप पर की गई क्रियाओं — पेज व्यू, विशिष्ट पेजों पर बार-बार विज़िट, एड-टू-कार्ट इवेंट, फीचर उपयोग, पेज पर बिताया गया समय — को वेटेज देती है, और इन वेटेड क्रियाओं को एक संख्या में समेट देती है जिससे निकट भविष्य की किसी क्रिया — खरीद, अपग्रेड, कैंसिलेशन, एस्केलेशन — का अनुमान लगाया जा सके।
तंत्र आमतौर पर सीधा होता है: इवेंट्स कैप्चर करें, उन्हें समय के साथ डिके करें, उन्हें एक स्कोर में जोड़ें, एक सीमा (threshold) सेट करें, सीमा पार होने पर एक कार्रवाई ट्रिगर करें। मुश्किल हिस्सा गणित नहीं है। यह है (1) सबसे पहले साफ-सुथरा, पहचान-समाधित (identity-resolved) व्यावहारिक डेटा प्राप्त करना, और (2) यह जानना कि कब अकेला व्यवहार कार्रवाई के लिए पर्याप्त सबूत नहीं है।
एक मिड-मार्केट ई-कॉमर्स व्यवसाय का उदाहरण लें जो हाई-इंटेंट शॉपर्स को छोड़ने से पहले पकड़ने और सही लोगों को डिस्काउंट नज की ओर रूट करने की कोशिश कर रहा है — बिना गलती से उस किसी को छूट दिए जिसका ऑर्डर पहले से ट्रांज़िट में है या जिसका रिटर्न विवाद खुला हुआ है।
Clickstream Publisher के Web SDK का उपयोग करते हुए, ऑटोमैटिक पेज व्यू के साथ-साथ इस उपयोग-मामले के लिए मायने रखने वाले कुछ कस्टम इवेंट्स ट्रैक करें: pricing_page_view, add_to_cart, compare_products। सब कुछ ट्रैक करने की इच्छा को रोकें — एक फूला हुआ इवेंट टैक्सोनॉमी साफ-सुथरे तरीके से स्कोर करना कठिन होता है और वेब, iOS, और Android स्रोतों में इसे बनाए रखना कठिन होता है, जिनमें से हर एक अपनी स्वतंत्र API key के साथ अपना अलग वर्कफ़्लो चलाता है।
लॉगिन से पहले, SDK एक स्थायी अनाम (anonymous) ID असाइन करता है। यहीं पर ज्यादातर व्यवहार-आधारित स्कोरिंग चुपचाप टूट जाती है: एक शॉपर लंच के समय अपने फोन पर ब्राउज़ करता है, फिर उस शाम एक लैपटॉप पर, और अंततः चेकआउट करने के लिए लॉगिन करता है। अगर लॉगिन के समय identify() सही तरीके से कॉल नहीं किया जाता, तो वे सेशन कभी मर्ज नहीं होते और आपका स्कोर वास्तविक इंटेंट को आधे से कम गिनता है। identify कॉल करने पर एक uid_transition इवेंट फायर होता है जो लॉगिन-पूर्व अनाम सेशन को ज्ञात कॉन्टैक्ट से जोड़ता है — यह पूरे पाइपलाइन का सबसे महत्वपूर्ण चरण है, और यह वह चरण है जिसे ज्यादातर टीमें छोड़ देती हैं या असंगत तरीके से लागू करती हैं।
ऐसे नियम सेट करें: पिछले 30 दिनों में कोई खरीद न होने पर 48 घंटों के भीतर तीन या अधिक pricing_page_view इवेंट्स 40 अंक जोड़ते हैं; दो घंटे के भीतर चेकआउट न होने पर add_to_cart इवेंट 25 अंक जोड़ता है। एक डिके विंडो लागू करें — व्यावहारिक इंटेंट नाशवान होता है। तीन हफ्ते पहले की विज़िट को तीन घंटे पहले की विज़िट जितना वजन नहीं मिलना चाहिए, लेकिन एक भोला-भाला संचयी स्कोर उन्हें एक जैसा मानेगा जब तक आप स्पष्ट रूप से विंडो को सीमित न करें।
यह वह चरण है जो केवल-व्यवहार टूल्स संरचनात्मक रूप से नहीं दे सकते, क्योंकि यह उनका डेटा नहीं है। डिस्काउंट नज भेजने से पहले, वर्कफ़्लो को यह जांचना चाहिए: क्या इस ग्राहक ने पिछले 24 घंटों में कोई ऑर्डर दिया है (ट्रांज़ैक्शन सिग्नल)? क्या इस कॉन्टैक्ट से जुड़ा कोई खुला सपोर्ट थ्रेड है (वॉइस/बातचीत सिग्नल)? अगर इनमें से कोई भी सच है, तो एक अलग पथ पर रूट करें — छूट रोकें, या सेल्स-फेसिंग कार्रवाई ट्रिगर करने के बजाय केस को एक सपोर्ट एजेंट के सामने लाएं। इसे एक वर्कफ़्लो के रूप में बनाएं जिसमें ट्रिगर के रूप में क्लिकस्ट्रीम इवेंट हो और अंतिम कार्रवाई फायर होने से पहले ऑर्डर और टिकट स्थिति जांचने वाली कंडीशनल ब्रांचें हों।
उच्च स्कोर, कोई खुला टिकट नहीं, कोई हालिया ऑर्डर नहीं: अपने खुद के Twilio या Telnyx नंबर के माध्यम से एक व्यक्तिगत SMS ट्रिगर करें, या सेल्स टीम के लिए ग्राहक के पूरे संदर्भ के साथ एक Collaboration थ्रेड में नोट डालें। खुली शिकायत के साथ मध्यम स्कोर: इसके बजाय एक Conversation थ्रेड में पोस्ट करें, ताकि अगला-सर्वश्रेष्ठ-कदम एक समाधान हो, न कि एक पिच।
ऊपर पहले ही बताया जा चुका है, लेकिन दोहराने लायक है क्योंकि यह सबसे आम मूक विफलता है। अगर identify आपके वेब और ऐप स्रोतों में देर से या असंगत रूप से फायर होता है, तो आपके इंटेंट स्कोर व्यवस्थित रूप से क्रॉस-डिवाइस शॉपर्स को कम गिनते हैं — अक्सर आपका सबसे मूल्यवान सेगमेंट, क्योंकि वे खरीदने से पहले वास्तविक शोध कर रहे होते हैं।
जैसे-जैसे अधिक लोग ट्रैकिंग कोड को छूते हैं — एक नया डेवलपर, एक रीडिज़ाइन, एक नया मोबाइल रिलीज़ — इवेंट नाम बदलने लगते हैं। नए iOS बिल्ड पर pricing_page_view, Pricing_Page बन जाता है, और आपका स्कोरिंग नियम चुपचाप एक पूरे चैनल के डेटा से मेल खाना बंद कर देता है। अपने इवेंट स्कीमा को एक रिव्यू स्टेप के साथ API कॉन्ट्रैक्ट की तरह मानें, न कि एक फ्री-फॉर-ऑल की तरह।
प्राइसिंग पेज पर शोध करने वाले प्रतिस्पर्धियों, स्क्रैपर्स, और सिर्फ जिज्ञासु मौजूदा ग्राहकों की भी हिट पड़ती है, जो खरीद नहीं रहे होते। ये सभी वास्तविक खरीद जोखिम या अवसर का प्रतिनिधित्व किए बिना केवल-व्यवहार स्कोर को बढ़ा देते हैं। यही सटीक कारण है कि अकेले क्लिकस्ट्रीम पर कार्रवाई करना जोखिम भरा है — एक वास्तविक प्रॉस्पेक्ट को शोर से अलग पहचानने के लिए आपको ट्रांज़ैक्शन और टिकट लेयर की जरूरत होती है।
बिना किसी समय-विंडो वाला स्कोर एक महीने पहले की विज़िट को एक घंटे पहले की विज़िट जैसा ही मानता है। हाई-इंटेंट ट्रिगर्स को छोटी विंडो (24–72 घंटे) पर चलना चाहिए; व्यापक एंगेजमेंट या हेल्थ स्कोरिंग लंबी विंडो का उपयोग कर सकती है, लेकिन दोनों को एक ही डिके कर्व साझा नहीं करना चाहिए।
जब कोई विज़िटर कुकी सहमति को अस्वीकार करता है, तो setConsent(false) तुरंत ट्रैकिंग रोक देता है और अनाम ID एसोसिएशन को साफ कर देता है — जो सही, GDPR-अनुरूप व्यवहार है। लेकिन इसका मतलब है कि आपकी व्यावहारिक कवरेज आपके ग्राहक आधार में संरचनात्मक रूप से असमान है: कुछ सेगमेंट हमेशा “कम इंटेंट” वाले दिखाई देंगे बस इसलिए क्योंकि उन्होंने ट्रैकिंग से बाहर निकलने का विकल्प चुना, न कि इसलिए कि वे संलग्न नहीं हैं। यदि आप सहमति-अस्वीकार करने वाले सेगमेंट के लिए ट्रांज़ैक्शन और सपोर्ट सिग्नल को अधिक भार देकर इसकी भरपाई नहीं करते, तो आप व्यवस्थित रूप से अपने ग्राहक आधार के एक हिस्से को कम सेवा देंगे।
बार-बार आपके कैंसिलेशन पेज पर जाने वाला ग्राहक चर्न करने वाला हो सकता है — या बिलिंग संबंधी किसी सवाल का समाधान ढूंढ रहा हो सकता है, या बस यह जानने के लिए उत्सुक हो सकता है कि प्रक्रिया कैसी दिखती है। क्लिकस्ट्रीम यह दिखाता है कि किसी ने क्या किया, न कि वह क्या चाहता है। यह वह ईमानदार सीमा है जिसे शुद्ध व्यावहारिक विश्लेषण बेचने वाले विक्रेताओं के पास नज़रअंदाज़ करने का व्यावसायिक-मॉडल कारण होता है: यह उनका पूरा उत्पाद है। समाधान एक अधिक स्मार्ट क्लिकस्ट्रीम मॉडल नहीं है। यह यह जांचना है कि क्या उसी कॉन्टैक्ट ID का कोई खुला सपोर्ट थ्रेड है, हाल ही में कम CSAT स्कोर है, या पहले से दर्ज कैंसिलेशन अनुरोध है — और कुछ भी ट्रिगर होने से पहले इन सिग्नलों को क्लिक डेटा को ओवरराइड या संदर्भित करने देना है।
एक B2B सॉफ्टवेयर या सेवा व्यवसाय के लिए, वही आर्किटेक्चर खरीद इंटेंट के बजाय रिन्यूअल जोखिम पर लागू होता है। एक “डाउनग्रेड” या “कैंसिल प्लान” हेल्प पेज पर बार-बार विज़िट को, उत्पाद उपयोग इवेंट्स में गिरावट के साथ मिलाकर, एक जोखिम सिग्नल के रूप में स्कोर करें। लेकिन अंतिम कार्रवाई को अकाउंट के ट्रांज़ैक्शन इतिहास (क्या वे इनवॉइस पर करंट हैं?) और उनके सबसे हालिया सर्वे प्रतिक्रिया (क्या उन्होंने अभी-अभी किसी विशिष्ट शिकायत के साथ कम CSAT या NPS स्कोर छोड़ा है?) पर गेट करें। एक जोखिम स्कोर जो किसी विशिष्ट बग के बारे में हाल की “डिट्रैक्टर” टिप्पणी को नज़रअंदाज़ करता है, वह एक सामान्य रिटेंशन ईमेल ट्रिगर करेगा जबकि अकाउंट को वास्तव में सपोर्ट से बग फिक्स की पुष्टि चाहिए होगी — यह एक बिल्कुल अलग अगला-सर्वश्रेष्ठ-कदम है, जो तभी दिखाई देता है जब व्यवहार को उसी ग्राहक ID पर वॉइस डेटा से जोड़ा जाता है।
SurveyAnalytica का Clickstream Publisher व्यावहारिक परत को कैप्चर करता है — पेज व्यू, कस्टम इवेंट्स, identify और uid_transition के माध्यम से अनाम-से-ज्ञात पहचान समाधान — और इसे सीधे उसी वर्कफ़्लो इंजन में रूट करता है जो पहले से ही ऑर्डर इवेंट्स, टिकट लाइफसाइकिल इवेंट्स, और सर्वे प्रतिक्रियाओं को प्रोसेस करता है। क्योंकि हर सिग्नल किसी थर्ड-पार्टी आइडेंटिटी ग्राफ के बजाय ग्राहक के अपने ID पर जुड़ा होता है, एक वर्कफ़्लो कंडीशन किसी कार्रवाई को ट्रिगर करने से पहले एक ही निर्णय पथ में क्लिकस्ट्रीम स्कोर, ऑर्डर स्थिति, और खुले थ्रेड की स्थिति की जांच कर सकती है।
एनालिटिक्स लेयर उस एग्रीगेशन का समर्थन करती है जिस पर ये स्कोर निर्भर करते हैं — KPI कार्ड, फ़िल्टर की गई गिनती, और प्रति-इंस्टेंस स्कोरिंग लॉजिक — ताकि आप डेटा को किसी अलग BI टूल में एक्सपोर्ट किए बिना सीमाएं बना और मॉनिटर कर सकें। और जब किसी हाई-इंटेंट या हाई-रिस्क स्कोर को एक स्वचालित नज नहीं बल्कि एक इंसान की जरूरत हो, तो Conversation थ्रेड्स पूरा संदर्भ ले जाते हैं — ट्रिगर करने वाला इवेंट, जुड़ा हुआ ऑर्डर, जुड़ा हुआ टिकट — ताकि जो कोई भी इसे उठाए वह एक खाली स्लेट से शुरुआत न करे।
Build surveys, run campaigns, and analyze responses with AI — free to start.
व्यावहारिक इंटेंट स्कोरिंग वास्तव में उपयोगी है, और जब इसे अपने आप में पर्याप्त बताकर बेचा जाता है तो वास्तव में इसे बढ़ा-चढ़ाकर पेश किया जाता है। क्लिक्स आपको बताते हैं कि क्या हुआ; वे आपको यह नहीं बताते कि क्या उस ग्राहक की पहले से कोई खुली शिकायत है, कोई लंबित ऑर्डर है, या इस हफ्ते उसे अकेला छोड़ देने का कोई कारण है। व्यावहारिक समाधान एक अधिक परिष्कृत स्कोरिंग फॉर्मूला नहीं है — यह सुनिश्चित करना है कि आपका वर्कफ़्लो पहले सिग्नल पर कार्रवाई करने से पहले अन्य तीन सिग्नल प्रकारों की जांच करे। स्कोर बनाएं, लेकिन कार्रवाई को गेट करें।
No comments yet. Be the first to comment!