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

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

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

इतिहास

खास जानकारी

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

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

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

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

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

टेक्निकल

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

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

डिस्ट्रिब्यूशन के बारे में बताने के लिए ज़्यादातर कारोबारी, खास जानकारी वाली मेट्रिक (उदाहरण के लिए, मीन, मीडियन, स्टैंडर्ड डेविएशन वगैरह) का इस्तेमाल करते हैं. हालांकि, आपको आम तौर पर हिस्टोग्राम, क्यूमुलेटिव डिस्ट्रिब्यूशन फ़ंक्शन (CDF), क्वांटाइल-क्वांटाइल (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 के लिए मान्य डेटा). यहां दी गई खास बातों से, आपको बाद में सिद्धांत बनाने और उनकी पुष्टि करने में मदद मिल सकती है. इन बातों का ध्यान रखें:

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

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

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

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

ये सवाल प्रयोग/कंट्रोल की तुलना करते समय और समय के साथ रुझानों की पड़ताल करते समय समझदार होते हैं.

मानक पहले, कस्टम सेकंड

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

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

दो बार या इससे ज़्यादा मापें

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

फिर से बनाने की क्षमता की जांच करना

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

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

देखें कि पिछले मेज़रमेंट के लिए आपने जो तरीका अपनाया है वह एक जैसा है

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

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

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

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

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

अनुमान लगाएं और सबूत ढूंढें

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

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

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

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

शुरू से अंत तक के चरणों को पूरा करने पर, एक्सप्लोरेट्री विश्लेषण के फ़ायदे

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

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

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

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

माइंडसेट

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

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

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

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

भ्रम की स्थिति में और चैंपियन बनें

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

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

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

कोरिलेशन != वजह

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

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

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

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

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

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

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

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

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

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

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

 

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

  2. तकनीकी तौर पर, इसे सिर्फ़ तब दोहराया जाना चाहिए, जब एक्सप्लोरेशन के तौर पर विश्लेषण किया जा रहा हो, न कि पुष्टि वाला विश्लेषण.↩