डेटा का अच्छा विश्लेषण

लेखक: पैट्रिक रिले

विशेष धन्यवाद: डायने टंग, रेहान खान, एलिज़ाबेथ टकर, अमिर नजमी, हिलेरी हचिंसन, जोएल डार्नॉयर, डेल नील, एनर बेन-आर्ट्ज़ी, सैंडर्स क्लाइनफ़ेल्ड, डेविड वेस्टब्रूक, और बैरी रोज़नबर्ग.

इतिहास

खास जानकारी

डेटा के ढेर से सच और अहम जानकारी पाना, एक कारगर काम है. इसमें गड़बड़ी का खतरा हमेशा बना रहता है. सबसे अच्छे डेटा एनालिस्ट और डेटा पर सोच-विचार करने वाले इंजीनियर, डेटा से सही उच्चारण करने के लिए अपनी पहचान बना लेते हैं. लेकिन वे ऐसा क्या करते हैं जिससे उनमें भरोसा बढ़ता है? मैं अक्सर सावधानी से और मैथडिकल जैसे विशेषण सुनता हूं, लेकिन सबसे ज़्यादा सावधानी बरतने वाले और व्यवस्थित विश्लेषक, असल में क्या करते हैं?

खास तौर पर, Google में हम जिस तरह का डेटा इकट्ठा करते हैं उसे ध्यान में रखते हुए, यह कोई आसान सवाल नहीं है. हम न सिर्फ़ बहुत बड़े डेटा सेट के साथ काम करते हैं, बल्कि वे डेटा सेट बहुत ज़्यादा समृद्ध होते हैं. इसका मतलब है कि आम तौर पर डेटा की हर लाइन में कई, कई एट्रिब्यूट होते हैं. जब किसी उपयोगकर्ता के लिए इसे इवेंट के अस्थायी क्रम के साथ जोड़ा जाता है, तो डेटा को बड़े पैमाने पर देखा जा सकता है. इसके उलट, अकादमिक मनोविज्ञान के एक आम प्रयोग से करें, जहां शोधकर्ता के लिए हर डेटा पॉइंट को देखना काफ़ी आसान होता है. हमारे बड़े, हाई-डाइमेंशन वाले डेटा सेट की वजह से आने वाली समस्याएं, वैज्ञानिक गतिविधियों के इतिहास के ज़्यादातर दौर में आने वाली समस्याओं से काफ़ी अलग हैं.

इस दस्तावेज़ में उन आइडिया और तकनीकों के बारे में खास जानकारी दी गई है जिनका इस्तेमाल, व्यवस्थित तरीके से काम करने वाले विश्लेषक, बड़े और हाई-डाइमेंशन वाले डेटा सेट पर करते हैं. हालांकि, इस दस्तावेज़ में लॉग और प्रयोग के तौर पर किए गए विश्लेषण के डेटा पर फ़ोकस किया गया है, लेकिन इनमें से कई तकनीकें ज़्यादा उपयोगी हैं.

दस्तावेज़ के बाकी हिस्से में तीन सेक्शन हैं, जिनमें डेटा के अलग-अलग विश्लेषण से जुड़े पहलुओं की जानकारी दी गई है:

  • तकनीकी: आपके डेटा में बदलाव करने और उसकी जांच करने के आइडिया और तकनीक.
  • प्रोसेस: इस बारे में सुझाव कि आपको अपने डेटा का इस्तेमाल कैसे करना है, कौनसे सवाल पूछने हैं, और किन चीज़ों की जांच करनी है.
  • Mindset: दूसरों के साथ काम करने और अहम जानकारी शेयर करने का तरीका.

टेक्निकल

आइए, आपके डेटा की जांच करने की कुछ तकनीकों पर नज़र डालें.

अपने डिस्ट्रिब्यूशन देखें

ज़्यादातर पेशेवर, डिस्ट्रिब्यूशन के बारे में बताने के लिए खास जानकारी वाली मेट्रिक (उदाहरण के लिए, माध्य, मीडियन, स्टैंडर्ड डेविएशन वगैरह) का इस्तेमाल करते हैं. हालांकि, आपको आम तौर पर हिस्टोग्राम, क्यूमुलेटिव डिस्ट्रिब्यूशन फ़ंक्शन (सीडीएफ़), क्वांटाइल-क्वांटाइल (Q-Q) प्लॉट वगैरह जनरेट करके, डिस्ट्रिब्यूशन को बेहतर तरीके से दिखाना चाहिए. इन बेहतर तरीकों से, आपको डेटा की अहम सुविधाओं, जैसे कि मल्टीमोडल बिहेवियर या आउटलेयर की एक बड़ी क्लास का पता लगाने में मदद मिलती है.

अलग परफ़ॉर्मेंस देने वाले कॉन्टेंट की पहचान करें

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

उदाहरण के लिए, सबसे कम क्लिक वाली क्वेरी देखने पर, आपको उन एलिमेंट पर किए गए क्लिक का पता चल सकता है जिनकी गिनती नहीं की जा पा रही है. सबसे ज़्यादा क्लिक वाली क्वेरी देखने पर हो सकता है कि आपको उन क्लिक का भी पता चले जिनकी गिनती नहीं की जानी चाहिए. दूसरी तरफ़, कुछ ऐसी चीज़ें हो सकती हैं जिनके बारे में आप कभी भी नहीं बता सकते. इसलिए, आपको इस बात का ध्यान रखना होगा कि इस काम के लिए आपको कितना समय देना है.

ग़ैर-ज़रूरी डेटा का ध्यान रखें

ऐसी हरकतें मौजूद होती हैं और हमें बेवकूफ़ बनाना पड़ता है. कुछ लोगों को लगता है, “Google के पास बहुत सारा डेटा है; ग़ैर-ज़रूरी आवाज़ें कम हो जाती हैं.” यह सच नहीं है. आपके दिए गए डेटा की हर संख्या या खास जानकारी के साथ-साथ इस अनुमान पर आपका भरोसा भी होना चाहिए (कॉन्फ़िडेंस इंटरवल और p-values जैसे तरीकों की मदद से).

उदाहरण देखें

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

इन उदाहरणों को सैंपल के तौर पर दिखाने का तरीका अहम है:

  • अगर दिए गए डेटा को कैटगरी में बांटा जा रहा है, तो हर क्लास से जुड़े उदाहरण देखें.
  • अगर यह क्लास बड़ी है, तो और सैंपल देखें.
  • अगर आप एक संख्या (उदाहरण के लिए, पेज लोड होने में लगने वाला समय) का पता लगा रहे हैं, तो पक्का करें कि आप सबसे ज़्यादा उदाहरण (जैसे कि सबसे तेज़ और सबसे धीमी 5%; आप जानते हैं कि आपका डिस्ट्रिब्यूशन कैसा दिखता है?) और मेज़रमेंट की पूरी जगह पर पॉइंट देखना न भूलें.

अपने डेटा में काट-छांट करना

स्लाइस करने का मतलब है कि अपने डेटा को सबग्रुप में अलग-अलग करना और हर सबग्रुप के लिए मेट्रिक की वैल्यू को अलग-अलग देखना. हम आम तौर पर ब्राउज़र, स्थान-भाषा, डोमेन, डिवाइस टाइप वगैरह जैसे डाइमेंशन को बांटते हैं. अगर सब-ग्रुप में मुख्य घटना के अलग तरह से काम करने की संभावना है, तो आपको डेटा को अलग-अलग हिस्सों में बांटना चाहिए, ताकि इस बात की पुष्टि हो सके कि क्या वाकई ऐसा ही है. भले ही आपको स्लाइस से अलग नतीजे मिलने की उम्मीद न हो, संगठन में काम करने के तरीके को एक जैसा रखने के लिए कुछ स्लाइस पर नज़र डालें. इससे आपको यह भरोसा होगा कि आप सही चीज़ को मेज़र कर रहे हैं. कुछ मामलों में, किसी विशेष स्लाइस में खराब डेटा, टूटा उपयोगकर्ता इंटरैक्शन या किसी भी रूप में बुनियादी रूप से अलग हो सकता है.

दो ग्रुप (जैसे कि प्रयोग बनाम कंट्रोल या यहां तक कि “समय A” बनाम “समय B” भी) की तुलना करने के लिए जब भी डेटा को अलग-अलग किया जाएगा, तो आपको मिक्स बदलावों की जानकारी होनी चाहिए. मिक्स शिफ़्ट तब होता है, जब हर ग्रुप के स्लाइस में मौजूद डेटा की मात्रा अलग-अलग होती है. सिम्पसन का विरोधाभास और अन्य भ्रम पैदा हो सकते हैं. आम तौर पर, अगर आपके दोनों ग्रुप में मौजूद किसी स्लाइस में मौजूद डेटा की संख्या एक जैसी है, तो सुरक्षित तरीके से तुलना की जा सकती है.

प्रॉडक्ट के महत्व को समझें

बहुत ज़्यादा डेटा होने पर, सिर्फ़ आंकड़ों के महत्व पर फ़ोकस करना या हर तरह के डेटा को बेहतर तरीके से समझना, इसके लिए ज़रूरी हो सकता है. हालांकि, आपको खुद से यह पूछना होगा कि, "भले ही यह सच हो कि X की वैल्यू Y से 0.1% ज़्यादा है, क्या इससे कोई फ़र्क़ पड़ता है?" यह खास तौर पर तब अहम हो सकता है, जब आप अपने डेटा के किसी हिस्से को समझने/समझने में असमर्थ हों. अगर आपको अपने लॉग में कुछ उपयोगकर्ता-एजेंट स्ट्रिंग को समझ में नहीं आ रहा है, तो चाहे वह डेटा 0.1% हो या 10%, इस बात से बहुत फ़र्क़ पड़ता है कि आपको उन मामलों की कितनी जांच करनी चाहिए.

इसके अलावा, कभी-कभी आपके पास कम डेटा होता है. कई बदलाव आंकड़ों के हिसाब से अहम नहीं दिखेंगे, लेकिन यह इन बदलावों के “न्यूट्रल” होने का दावा करने से अलग है. आपको खुद से यह सवाल पूछना चाहिए, “इस बात की कितनी संभावना है कि अब भी व्यावहारिक तौर पर अहम बदलाव हुआ है?”

समय के साथ अनुकूलता की जांच करें

आपको हमेशा समय की इकाई के हिसाब से डेटा को बांटने की कोशिश करनी चाहिए, क्योंकि समय के साथ हमारे सिस्टम में बदलाव होने के साथ-साथ, बुनियादी डेटा में कई समस्याएं होती हैं. (हम अक्सर दिनों का इस्तेमाल करते हैं, लेकिन समय की दूसरी इकाइयां भी मददगार हो सकती हैं.) किसी सुविधा या नए डेटा कलेक्शन के शुरुआती लॉन्च के दौरान, पेशेवर लोग अक्सर सावधानी से जांच करते हैं कि सब कुछ उम्मीद के मुताबिक काम कर रहा है या नहीं. हालांकि, समय के साथ कई रुकावटें या अनचाहे व्यवहार पैदा हो सकते हैं.

अगर कोई खास दिन या दिनों का सेट बाहरी है, तो इसका मतलब यह नहीं है कि आपको उससे जुड़ा डेटा खारिज करना चाहिए. डेटा को हुक की तरह इस्तेमाल करें, ताकि उसे छोड़ने से पहले यह पता लगाया जा सके कि वह दिन या दिन अलग क्यों है.

दिन-दर-दिन का डेटा देखने से आपको डेटा में होने वाले बदलावों के बारे में भी पता चलता है. इससे आपको कॉन्फ़िडेंस इंटरवल या आंकड़ों के हिसाब से अहम होने के दावे करने में मदद मिलती है. आम तौर पर, इसे कॉन्फ़िडेंस-इंटरवल कैलकुलेशन की जगह इस्तेमाल नहीं किया जाना चाहिए. हालांकि, आम तौर पर बड़े बदलावों के साथ यह देखा जा सकता है कि वे सिर्फ़ दिन-दर-दिन के ग्राफ़ से जुड़े आंकड़ों के हिसाब से अहम हैं.

अपने फ़िल्टर को स्वीकार करें और गिनें

करीब-करीब हर बड़े डेटा के विश्लेषण की शुरुआत, डेटा को अलग-अलग चरणों में फ़िल्टर करने से होती है. हो सकता है कि आप सिर्फ़ अमेरिकन उपयोगकर्ताओं या वेब खोजों या विज्ञापनों वाली खोजों को ध्यान में रखना चाहें. जो भी हो, आपको ये ज़रूरी शर्तें पूरी करनी होंगी:

  • स्वीकार करें और साफ़ तौर पर बताएं कि आपको क्या फ़िल्टर करना है.
  • हर चरण में फ़िल्टर किए जा रहे डेटा की गिनती करें.

आम तौर पर, मेट्रिक का पता लगाने का सबसे अच्छा तरीका यह है कि आप सभी मेट्रिक का हिसाब लगाएं. भले ही, आप बाहर रखी गई जनसंख्या के लिए भी क्यों न हों. इसके बाद, उस डेटा को देखकर ऐसे सवालों के जवाब पाएं जैसे, "स्पैम फ़िल्टर ने कितनी क्वेरी को हटाया है?" (आप फ़िल्टर क्यों कर रहे हैं, इस आधार पर हो सकता है कि उस तरह का विश्लेषण हमेशा मुमकिन न हो.)

अनुपात के अंश और हर में साफ़ तौर पर जानकारी होनी चाहिए

सबसे दिलचस्प मेट्रिक, बुनियादी मापों के अनुपात हैं. अक्सर, दिलचस्प फ़िल्टर या डेटा के दूसरे विकल्प, न्यूमरेटर और डिनॉमिनेटर की सटीक डेफ़िनिशन में छिपे होते हैं. उदाहरण के लिए, इनमें से “क्वेरी / उपयोगकर्ता” का असल में क्या मतलब है?

  • क्वेरी / क्वेरी वाले उपयोगकर्ता
  • क्वेरी / ऐसे उपयोगकर्ता जो आज Google पर गए
  • ऐसी क्वेरी / उपयोगकर्ता जिनका खाता चालू है (हां, मुझे यह बताना होगा कि ऐक्टिव है)

यहां सच में साफ़ रहने से, खुद के और दूसरों के लिए भ्रम की स्थिति से बचा जा सकता है.

एक और खास मामला ऐसी मेट्रिक का है जिनका हिसाब सिर्फ़ आपके कुछ डेटा से लगाया जा सकता है. उदाहरण के लिए, "क्लिक करने का समय" का मतलब आम तौर पर "क्लिक मिलने के समय से है, क्योंकि उस समय एक क्लिक मिला था." इस तरह की मेट्रिक को देखते समय, आपको यह स्वीकार करना होगा कि फ़िल्टर करने की प्रोसेस में बदलाव हुआ है. साथ ही, तुलना किए जा रहे ग्रुप के बीच डेटा को फ़िल्टर करने की प्रोसेस में भी बदलाव होगा.

प्रोसेस

इस सेक्शन में बताया गया है कि अपने डेटा को कैसे इस्तेमाल किया जाए, अपने डेटा के बारे में क्या सवाल पूछे जाएं, और उसकी जांच कैसे की जाए.

अलग-अलग पुष्टि, ब्यौरा, और आकलन

मेरे हिसाब से डेटा का विश्लेषण, एक-दूसरे से जुड़े तीन स्टेज के तौर पर होता है:

  1. पुष्टि करना1: क्या मुझे लगता है कि डेटा अपने-आप एक जैसा है, उसे सही तरीके से इकट्ठा किया गया है, और यह उस जानकारी को दिखाता है जो मेरे हिसाब से होती है?
  2. ब्यौरा: इस डेटा का मकसद क्या है? उदाहरण के लिए, "उपयोगकर्ता, X के तौर पर कम क्वेरी करते हैं," "एक्सपेरिमेंट ग्रुप में, X और Y के बीच समय 1% ज़्यादा होता है", और "कम उपयोगकर्ता, नतीजों के अगले पेज पर जाते हैं."
  3. आकलन: ब्यौरे को देखते हुए, क्या डेटा से हमें यह पता चलता है कि उपयोगकर्ता के लिए, Google के लिए या दुनिया के लिए कुछ अच्छा हो रहा है?

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

ये चरण एक-एक करके आगे नहीं बढ़ते. डेटा को देखते-देखते, ऐसा हो सकता है कि आप अलग-अलग स्टेज पर आ जाएं. हालांकि, किसी भी समय यह देखा जा सकता है कि आप किस स्टेज पर हैं.

एक्सपेरिमेंट और डेटा कलेक्शन को सेटअप करने की पुष्टि करें

किसी भी डेटा को देखने से पहले, पक्का करें कि आपने उस कॉन्टेक्स्ट को समझ लिया हो जिसमें डेटा इकट्ठा किया गया था. अगर डेटा किसी प्रयोग से आता है, तो प्रयोग के कॉन्फ़िगरेशन पर नज़र डालें. अगर यह किसी नए क्लाइंट इंस्ट्रुमेंटेशन से लिया गया है, तो पक्का करें कि आपको डेटा इकट्ठा करने के तरीक़ों की कम से कम समझ हो. आपको असामान्य/खराब कॉन्फ़िगरेशन या जनसंख्या से जुड़ी पाबंदियां दिख सकती हैं (जैसे, सिर्फ़ Chrome के लिए मान्य डेटा). यहां दी गई कोई भी अहम जानकारी, बाद में सिद्धांत बनाने और उनकी पुष्टि करने में आपकी मदद कर सकती है. इन बातों का ध्यान रखें:

  • अगर एक्सपेरिमेंट चल रहा है, तो खुद आज़माकर देखें. अगर ऐसा नहीं हो पा रहा है, तो कम से कम स्क्रीनशॉट/व्यवहार के ब्यौरे देखें.
  • यह जांच करें कि प्रयोग चलाए जाने की समयसीमा (छुट्टी, बड़े लॉन्च वगैरह) में कोई असामान्य बात तो नहीं थी.
  • पता लगाएं कि कौनसे उपयोगकर्ता, इस प्रयोग में शामिल थे.

यह देखें कि क्या नहीं बदलना चाहिए

"पुष्टि" के चरण के हिस्से के तौर पर, अपनी दिलचस्पी के सवाल का जवाब देने से पहले (उदाहरण के लिए, "क्या किसी चेहरे की तस्वीर जोड़ने से क्लिक में बढ़ोतरी या कमी हुई है?"), डेटा में मौजूद किसी भी ऐसे बदलाव को खारिज करें जिसकी वजह से प्रयोग पर असर पड़ सकता है. उदाहरण के लिए:

  • क्या उपयोगकर्ताओं की संख्या में बदलाव हुआ है?
  • क्या मेरे सभी सबग्रुप में, उन क्वेरी की सही संख्या दिख रही है जिन पर असर पड़ा है?
  • क्या गड़बड़ी की दरों में बदलाव हुआ है?

ये सवाल, प्रयोग/कंट्रोल की तुलना करने और समय के साथ रुझानों की जांच करते समय, दोनों के लिए काम के हैं.

स्टैंडर्ड मैसेज पहले, पसंद के मुताबिक दूसरा,

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

कस्टम मेट्रिक की तुलना में स्टैंडर्ड मेट्रिक की पुष्टि ज़्यादा बेहतर तरीके से की जाती है और उनके सही होने की संभावना ज़्यादा होती है. अगर आपकी कस्टम मेट्रिक और आपकी स्टैंडर्ड मेट्रिक का कोई मतलब नहीं है, तो हो सकता है कि आपकी कस्टम मेट्रिक गलत हों.

एक या उससे ज़्यादा बार मापें

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

देखें कि वीडियो रीप्रॉड्यूसिबिलिटी का इस्तेमाल किया गया है या नहीं

समय के साथ स्लाइसिंग और कंसिस्टेंसी, दोनों ही रीप्रॉड्यूसिबिलिटी की जांच करने के खास उदाहरण हैं. अगर कोई घटना अहम और अर्थपूर्ण है, तो आपको उसे अलग-अलग उपयोगकर्ता जनसंख्या और समय के हिसाब से देखना चाहिए. हालांकि, इन दोनों तरह की जांचों के बजाय, यह पुष्टि करने का मतलब है कि यह पुष्टि करने से कहीं ज़्यादा फ़ायदा होगा. अगर डेटा के मॉडल बनाए जा रहे हैं, तो आपको चाहिए कि ये मॉडल डेटा की छोटी-छोटी गड़बड़ियों के बीच एक जैसे हों. अलग-अलग समय सीमाओं या अपने डेटा के रैंडम सब-सैंपल का इस्तेमाल करने पर, यह भी पता चलेगा कि यह मॉडल कितना भरोसेमंद/रीजनेबल है.

अगर किसी मॉडल को दोबारा नहीं बनाया जा सकता, तो हो सकता है कि आपने डेटा बनाने वाली प्रोसेस के बारे में बुनियादी जानकारी न दी हो.

देखें कि पिछले मापों के साथ एक जैसा अनुभव मिला है या नहीं

अक्सर ऐसी मेट्रिक का कैलकुलेशन किया जाता है जो पहले गिनी गई चीज़ों से मिलती-जुलती है. आपको अपनी मेट्रिक की तुलना पहले रिपोर्ट की गई मेट्रिक से करनी चाहिए, भले ही ये मेज़रमेंट अलग-अलग लोगों की संख्या पर भी हों.

उदाहरण के लिए, अगर किसी खास लोगों से जुड़ी क्वेरी का ट्रैफ़िक देखा जा रहा है और आपको यह पता है कि पेज लोड होने में लगने वाला औसत समय पांच सेकंड है, लेकिन सभी उपयोगकर्ताओं के पिछले विश्लेषण से, पेज लोड होने में लगने वाला औसत समय दो सेकंड है, तो आपको इसकी जांच करनी होगी. आपका नंबर इस जनसंख्या के लिए सही हो सकता है, लेकिन अब इसकी पुष्टि करने के लिए आपको बहुत कुछ करना होगा.

आपको सटीक समझौता करने की ज़रूरत नहीं है, लेकिन आपको उसी बॉलपार्क में होना चाहिए. अगर ऐसा नहीं है, तो यह मानें कि आप गलत हैं. ऐसा तब तक करें, जब तक आप खुद को पूरी तरह से ठीक न कर पाएं. सबसे ज़्यादा चौंकाने वाला डेटा गड़बड़ी की वजह से दिखेगा, न कि कोई नई अहम जानकारी.

नई मेट्रिक पहले, पुराने डेटा/सुविधाओं पर लागू होनी चाहिए

अगर नई मेट्रिक बनाई जाती हैं (शायद नया डेटा सोर्स इकट्ठा करके) और कुछ नया सीखने की कोशिश करें, तो आपको यह पता नहीं चलेगा कि आपकी नई मेट्रिक सही है या नहीं. नई मेट्रिक के साथ, आपको पहले उन्हें किसी जानी-पहचानी सुविधा या डेटा पर लागू करना चाहिए. उदाहरण के लिए, अगर आपके पास उपयोगकर्ता की संतुष्टि के लिए कोई नई मेट्रिक है, तो आपको यह पक्का करना चाहिए कि उसमें आपकी उन बेहतरीन सुविधाओं के बारे में बताया गया हो जिनसे उपयोगकर्ताओं को संतुष्टि मिलती है. अगर आपके पास इस बारे में कोई नई मेट्रिक है कि उपयोगकर्ता, पेज पर अपना ध्यान कहां ले जा रहे हैं, तो पक्का करें कि यह मेट्रिक, आंखों का विश्लेषण करने वाले या रेटिंग देने वाले लोगों के अध्ययन से मिली जानकारी से मेल खाती हो. ऐसा करने से, उस समय पुष्टि मिलती है जब आपको कुछ नया सीखने को मिलता है.

अनुमान लगाना और साक्ष्य खोजना

आम तौर पर, किसी जटिल समस्या के लिए डेटा का विश्लेषण बार-बार किया जाता है.2 आपको डेटा की अनियमितताएं, रुझान या अन्य सुविधाएं मिलेंगी. ज़ाहिर है कि इस डेटा के बारे में आपको अलग-अलग सिद्धांत मिलेंगे. न सिर्फ़ कोई सिद्धांत बनाएँ, बल्कि उसे सच करने का दावा भी न करें. इस सिद्धांत की पुष्टि/अस्वीकार करने के लिए, सबूत देखें (डेटा के अंदर या बाहर). उदाहरण के लिए:

  • अगर आपको कुछ सीखने के ट्रेंड जैसा कुछ दिखता है, तो देखें कि क्या इसका ज़्यादा फ़्रीक्वेंसी इस्तेमाल करने वाले उपयोगकर्ताओं को पता चलता है.
  • अगर आपको लगता है कि कुछ सुविधाओं के लॉन्च की वजह से कोई गड़बड़ी हुई है, तो पक्का करें कि सुविधा सिर्फ़ उन लोगों के लिए है जिन पर इस गड़बड़ी का असर पड़ा है. इसके अलावा, पक्का करें कि बदलाव का दायरा, लॉन्च की उम्मीदों के मुताबिक हो.
  • अगर आपको किसी स्थान-भाषा के उपयोगकर्ताओं की बढ़ोतरी की दरों में बदलाव दिखता है, तो कोई ऐसा बाहरी सोर्स ढूंढें जो उपयोगकर्ता की जनसंख्या में बदलाव की दर की पुष्टि करता हो.

डेटा के अच्छे विश्लेषण से आपको एक कहानी पता चलती है. यह पक्का करने के लिए कि यह सही कहानी है, आपको वह कहानी खुद को बतानी होगी, फिर इस बात का सबूत देखना होगा कि यह गलत है. ऐसा करने का एक तरीका यह है कि आप खुद से पूछें, “मैं ऐसे कौनसे प्रयोग करूं जो मेरी बताई गई कहानी की पुष्टि/अमान्य कर देंगे?” भले ही आप ये प्रयोग न कर पाएं या न कर पाएं, लेकिन इससे आपको अपने डेटा की पुष्टि करने के तरीकों के बारे में पता चल सकता है.

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

एंड-टू-एंड एन्क्रिप्शन (E2EE) की मदद से, एक्सप्लोरेशन (विश्लेषण के तरीके) का विश्लेषण करने पर मिलने वाले फ़ायदे

एक्सप्लोरेट्री विश्लेषण करते समय, पूरे विश्लेषण को जितना हो सके ज़्यादा से ज़्यादा बार-बार दोहराएं. आम तौर पर, आपको सिग्नल इकट्ठा करने, प्रोसेस करने, मॉडलिंग वगैरह के कई चरण होते हैं. अगर आपको शुरुआती सिग्नल के पहले चरण को पूरा करने में बहुत ज़्यादा समय लगता है, तो एक ही समय में बार-बार कई बार करने के अवसर नहीं छूट रहे हैं. इसके अलावा, आखिर में जब आप अपने डेटा पर नज़र डालते हैं, तो आपको ऐसी खोजें मिल सकती हैं जो आपकी दिशा बदल सकती हैं. इसलिए, शुरुआत में आपका फ़ोकस सटीक होने पर नहीं, बल्कि कुछ सही करने पर होना चाहिए. खुद के लिए नोट छोड़ें और फ़िल्टर करने के चरणों और पार्स न किए जा सकने वाले या असामान्य अनुरोधों जैसी चीज़ों को स्वीकार करें, लेकिन एक्सप्लोरेट्री विश्लेषण की शुरुआत में ही उन सभी से छुटकारा पाने में समय बर्बाद न करें.

सुझाव, शिकायत या राय के लिए तैयार रहें

आम तौर पर, हम उपयोगकर्ता की सफलता से जुड़ी कई मेट्रिक तय करते हैं. उदाहरण के लिए, क्या उपयोगकर्ताओं ने किसी नतीजे पर क्लिक किया? अगर उस डेटा को सिस्टम में वापस फ़ीड कर दिया जाता है (जैसा कि हम कई जगहों पर करते हैं), तो आकलन करने में भ्रम की स्थिति पैदा हो सकती है.

अपने बदलाव का आकलन करने के लिए, सिस्टम को दी गई मेट्रिक का इस्तेमाल नहीं किया जा सकता. अगर ज़्यादा क्लिक पाने वाले विज्ञापन दिखाए जाते हैं, तो “ज़्यादा क्लिक” का इस्तेमाल यह तय करने के लिए नहीं किया जा सकता कि उपयोगकर्ता खुश हैं. हालांकि, “ज़्यादा क्लिक” का मतलब “ज़्यादा खुश” होता है. इसके अलावा, आपको उन वैरिएबल को भी नहीं काटना चाहिए.

माइंडसेट

इस सेक्शन में बताया गया है कि दूसरों के साथ काम कैसे किया जाए और अहम जानकारी कैसे शेयर की जाए.

डेटा का विश्लेषण सवालों से शुरू होता है, डेटा या तकनीक से नहीं

डेटा का विश्लेषण करने की वजह हमेशा से रहती है. अपनी ज़रूरतों को सवालों या अनुमान के तौर पर पूरा करने से यह पक्का करने में मदद मिलती है कि आपको वही डेटा इकट्ठा करना है जो आपको इकट्ठा करना है. साथ ही, यह भी पक्का किया जा सकेगा कि डेटा में क्या अंतर हो सकता है. बेशक, डेटा देखते समय आपके पूछे गए सवाल भी बदलते रहने चाहिए. हालांकि, बिना सवाल किए किए गए विश्लेषण का कोई नतीजा नहीं होगा.

कुछ पसंदीदा तकनीक ढूंढने के जाल से बचें और फिर समस्याओं के सिर्फ़ उन हिस्सों को ढूंढें जिन पर यह तकनीक काम करती है. फिर से, साफ़ सवाल पूछने से आपको इस जाल से बचने में मदद मिलेगी.

संशयवादी और चैंपियन, दोनों बनें

डेटा पर काम करते समय, आपको उस इनसाइट के चैंपियन होना चाहिए जो आपको मिल रहा हो. साथ ही, आपको उन इनसाइट को लेकर भी शक होना चाहिए. उम्मीद है कि आपने डेटा में कुछ दिलचस्प तथ्य देखे होंगे. किसी दिलचस्प घटना का पता चलने पर, खुद से ये सवाल पूछें:

  • यह कितना शानदार है, यह दिखाने के लिए कौनसा डेटा इकट्ठा किया जा सकता है?
  • मुझे ऐसा क्या मिल सकता है जिससे यह जानकारी अमान्य हो जाए?”

खास तौर पर, उन मामलों में जहां आप किसी ऐसे व्यक्ति के लिए विश्लेषण कर रहे हैं जिसे कोई खास जवाब चाहिए (उदाहरण के लिए, "मेरी सुविधा शानदार है!"), आपको गड़बड़ी होने से बचने के लिए संदेह को खेलना चाहिए.

कोरिलेशन != कॉज़ेशन

डेटा के बारे में सिद्धांत बनाते समय, हम अक्सर यह दावा करना चाहते हैं कि "X की वजह Y है"—उदाहरण के लिए, "पेज धीमा होने की वजह से, उपयोगकर्ता कम क्लिक करते हैं." यहां तक कि xkcd भी पता है कि सिर्फ़ कोरिलेशन की वजह से वजह नहीं बनाई जा सकती. काम की वजह बताने वाले सिद्धांत की पुष्टि करने के तरीके को अपनाकर, आम तौर पर यह अच्छी तरह से समझा जा सकता है कि वजह-आधारित सिद्धांत कितना भरोसेमंद है.

कभी-कभी, लोग यह दावा करके किसी कोरिलेशन को बनाए रखने की कोशिश करते हैं कि A और B के बीच कोई खास संबंध न होने पर भी, संयोग के पीछे कुछ ऐसा ज़रूर होगा कि कोई एक सिग्नल दूसरे के लिए अच्छा इंडिकेटर या प्रॉक्सी हो. यह इलाका, कई परिकल्पनाओं की जांच करने से जुड़ी समस्याओं के लिए खतरनाक है. जैसा कि xkcd भी पता है, काफ़ी प्रयोग और काफ़ी डाइमेंशन को देखते हुए, कुछ सिग्नल किसी खास प्रयोग के लिए अलाइन होंगे. इसका मतलब यह नहीं है कि आने वाले समय में इसी तरह के सिग्नल मिलेंगे. इसलिए, आप पर भी काम से जुड़े सिद्धांत पर ध्यान देने की जवाबदेही है. जैसे, “ छिपे हुए असर C की वजह से A और B, दोनों पर असर पड़ता है”, ताकि आप इस बात की पुष्टि करने की कोशिश कर सकें कि यह कितना सही है.

डेटा एनालिस्ट अक्सर उन लोगों के लिए आम सवालों पर नेविगेट करता है, जो डेटा का इस्तेमाल करना चाहते हैं. आपको उन उपभोक्ताओं को साफ़ तौर पर समझना चाहिए कि काम के बारे में क्या कहा जा सकता है और क्या नहीं.

मिलते-जुलते ऐप्लिकेशन के साथ शेयर करें, फिर बाहरी उपयोगकर्ताओं के साथ शेयर करें

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

आम तौर पर, आपको किसी ऐसे साथी से सुझाव लेना चाहिए जिसे उस डेटा के बारे में कुछ जानकारी हो जिसे आप देख रहे हैं. हालांकि, सामान्य डेटा-विश्लेषण अनुभव वाला साथी भी बहुत ज़रूरी है.

अनजाने में और गलतियों को करने की उम्मीद करना और उन्हें स्वीकार करना

हम डेटा से क्या सीख सकते हैं, इसकी कई सीमाएं होती हैं. नेट सिल्वर ने सिग्नल और शोर में अपनी पकड़ बनाई है. अपनी खासियत की सीमा को स्वीकार करके ही हम अनुमान को बेहतर बना सकते हैं. अनजाने में होने वाली बात को स्वीकार करना ही एक ताकत है, लेकिन आम तौर पर तुरंत इनाम नहीं मिलता. उस समय इतना अच्छा नहीं लगता, लेकिन लंबे समय में इससे आपको और आपकी टीम के लिए बहुत फ़ायदा होगा. तब और भी बुरा लगता है, जब कोई गलती हो जाती है और उसे बाद में पता चल जाता है (या बहुत देर से!), लेकिन अपनी गलतियों को पूरी तरह समझ लेने पर आपको इज़्ज़त मिलती है. वह सम्मान विश्वसनीयता और प्रभाव डालता है.

विचार बंद करना

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

आपके डेटा में इन सभी बदलावों और एक्सप्लोरेशन (विश्लेषण के तरीके) की ज़रूरत, डेटा के अच्छे विश्लेषण की भाषा और एनवायरमेंट की शर्तों को भी तय करती है. डेटा की जांच करने के लिए, हमारे पास कई टूल उपलब्ध हैं. ऊपर बताई गई तकनीकों के हिसाब से, अलग-अलग टूल और भाषाएँ बेहतर होती हैं. किसी विश्लेषक के लिए सही टूल चुनना ज़रूरी होता है. ध्यान रखें कि आपको जिस टूल का इस्तेमाल करना है उसकी क्षमताओं को सीमित न करें. आपका काम, किसी टूल का इस्तेमाल करने के बजाय, सही जानकारी देना है.

 

  1. इसे कभी-कभी “शुरुआती डेटा का विश्लेषण” कहा जाता है. डेटा के विश्लेषण से जुड़ा Wikipedia का लेख ↩ देखें

  2. तकनीकी रूप से, अगर आपको सिर्फ़ एक्सप्लोरेशन (विश्लेषण का तरीका) विश्लेषण करना हो, न कि पुष्टि करने वाला विश्लेषण.↩