प्रॉम्प्ट और लागू संदर्भ
एक उत्पाद प्रयोग कॉन्फ़िगर किए गए 50/50 विभाजन के साथ उपयोगकर्ता द्वारा स्थिर यादृच्छिक असाइनमेंट (stable random assignment) का उपयोग करता है। 100,000 योग्य उपयोगकर्ताओं के बाद, विश्लेषण में 51,000 कंट्रोल उपयोगकर्ता और 49,000 ट्रीटमेंट उपयोगकर्ता शामिल हैं। ट्रीटमेंट रूपांतरण 1.8% अधिक है, और सामान्य प्रभाव परीक्षण (effect test) 0.01 से कम p मान रिपोर्ट करता है। तय करें कि क्या परिणाम भरोसेमंद है और सैंपल रेशियो मिसमैच (Sample Ratio Mismatch या SRM) का पता लगाने, निदान करने, सुधारने और रोकने के लिए एक प्रक्रिया डिज़ाइन करें।
यह प्रश्न डेटा साइंस, उत्पाद एनालिटिक्स, बिजनेस इंटेलिजेंस और प्रयोग-प्लेटफ़ॉर्म (experimentation-platform) भूमिकाओं पर लागू होता है। Amazon का वर्तमान डेटा-रोल साक्षात्कार मार्गदर्शन स्पष्ट रूप से सांख्यिकी, अस्पष्ट डेटा के माध्यम से काम करने और विश्लेषण को कार्रवाई योग्य निर्णयों में बदलने की मांग करता है। Microsoft का प्रयोग अनुसंधान SRM को एक मुख्य विश्वसनीयता संकेत (trustworthiness signal) मानता है। प्राथमिक श्रेणी data है: केंद्रीय कार्य सांख्यिकीय परीक्षण और डेटा-वंशावली (data-lineage) निदान है, न कि संपूर्ण प्रयोग प्लेटफ़ॉर्म को डिज़ाइन करना।
100,000, 51,000, 49,000 और 1.8% के मान साक्षात्कार की मान्यताएँ हैं, उद्योग बेंचमार्क नहीं। समाधान यह मानता है कि उपयोगकर्ता रैंडमाइज़ेशन इकाई (randomization unit) है और प्रत्येक उपयोगकर्ता को केवल एक संस्करण (variant) में दिखना चाहिए। डिवाइस, खाता, कार्यस्थान (workspace), परिवार या क्षेत्र द्वारा यादृच्छिक किए गए वास्तविक प्रयोग को संबंधित इकाई का परीक्षण करना चाहिए।
साक्षात्कारकर्ता क्या मूल्यांकन करता है
पहला संकेत यह है कि उम्मीदवार व्यावसायिक प्रभाव (business impact) को पढ़ने से पहले प्रयोग की अखंडता की जांच करता है या नहीं। एक कमजोर उत्तर "p < 0.01 के साथ 1.8% लिफ्ट" देखता है और लॉन्च की सिफारिश करता है। एक मजबूत उत्तर पहले यह सत्यापित करता है कि देखी गई आबादी कॉन्फ़िगर किए गए असाइनमेंट से मेल खाती है। प्रभाव परीक्षण यह कह सकता है कि देखे गए दो परिणाम भिन्न हैं; यह यह साबित नहीं कर सकता कि उन समूहों में शेष उपयोगकर्ता अभी भी तुलनीय यादृच्छिक नमूने बनाते हैं।
दूसरा संकेत यह है कि क्या एक दृश्य अनुपात अंतर सांख्यिकीय परीक्षण में परिवर्तित होता है। वही 51/49 विभाजन 100,000 उपयोगकर्ताओं की तुलना में 1,000 उपयोगकर्ताओं के साथ बहुत भिन्न अर्थ रखता है। एक SRM परीक्षण कॉन्फ़िगर किए गए आवंटन द्वारा निहित गणनाओं के साथ देखे गए वेरिएंट की संख्या की तुलना करता है। अधिक डेटा छोटे व्यवस्थित विचलनों को संयोग से अलग पहचानना आसान बनाता है।
तीसरा संकेत नैदानिक कवरेज (diagnostic coverage) है। SRM आवंटन कॉन्फ़िगरेशन, अस्थिर पहचान (unstable identities), संस्करण निष्पादन, अनुपलब्ध टेलीमेट्री, बॉट फ़िल्टरिंग, डेटा जॉइन या उपचार के बाद परिभाषित विश्लेषण स्थिति के माध्यम से प्रवेश कर सकता है। प्रत्येक SRM को "खराब यादृच्छिकता (bad randomness)" कहना कई सामान्य निष्पादन और डेटा-प्रोसेसिंग विफलताओं को अनदेखा करता है।
अंत में, साक्षात्कारकर्ता निर्णय अनुशासन (decision discipline) की तलाश करता है। SRM एक लक्षण है, कोई हानिरहित शोर नहीं जिसे वेटिंग (weighting) स्वचालित रूप से हटा देती है। एक प्रकाशित मामले में, उपचार ने जुड़ाव (engagement) को इतना बदल दिया कि एक बॉट फ़िल्टर ने अधिक अत्यधिक व्यस्त उपयोगकर्ताओं को हटा दिया; दोष ठीक होने के बाद व्यावसायिक निष्कर्ष उलट गया। जब तक मूल कारण समझ में न आ जाए, तब तक शिप करने के निर्णय को रोकें, बजाय इसके कि किसी अन्य मीट्रिक की खोज की जाए जो महत्वपूर्ण बनी रहे।
उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न
- क्या 50/50 असाइनमेंट, एक्सपोज़र, ट्रिगरिंग या अंतिम विश्लेषण आबादी का वर्णन करता है? असाइनमेंट सही हो सकता है जबकि एक्सपोज़र, पात्रता या डाउनस्ट्रीम विश्लेषण में SRM विकसित हो सकता है। प्रत्येक चरण का परीक्षण करें।
- रैंडमाइज़ेशन इकाई क्या है? यदि असाइनमेंट कार्यस्थान द्वारा है, तो सदस्य संख्या स्वाभाविक रूप से भिन्न हो सकती है। पहले कार्यस्थान की संख्या का परीक्षण करें और क्लस्टर किए गए असाइनमेंट के लिए उपयुक्त विधियों के साथ परिणामों का विश्लेषण करें।
- क्या पहचान स्थिर और परस्पर अनन्य (mutually exclusive) है? क्रॉस-डिवाइस लॉगिन, कुकी विलोपन, अनाम-से-खाता विलय, और आईडी माइग्रेशन किसी व्यक्ति को पुन: असाइन या डुप्लिकेट कर सकते हैं।
- क्या रन के दौरान आवंटन बदल गया था? 10/90 से 50/50 तक के रैंप के लिए प्रत्येक अंतराल से अपेक्षित गणना की आवश्यकता होती है, न कि पूरे प्रयोग पर लागू अंतिम विभाजन की।
- एक "योग्य उपयोगकर्ता" को कैसे परिभाषित किया जाता है? उपचार से प्रभावित स्थिति, जैसे कि केवल नए उपचार वाले बटन पर क्लिक करना, उपचार के बाद का चयन (post-treatment selection) है और तुलनीयता को नष्ट कर सकता है।
- क्या एक संस्करण रीडायरेक्ट, विफल या भिन्न रूप से लॉग हो सकता है? धीमा लोड होना, क्रैश और संस्करण-विशिष्ट टेलीमेट्री निष्पादन और संग्रह के दौरान उपयोगकर्ताओं को हटा सकती है।
- कौन सी पाइपलाइन अंतिम गणना उत्पन्न करती हैं? असाइनमेंट, एक्सपोज़र, इवेंट संग्रह, डीडुप्लीकेशन, बॉट फ़िल्टरिंग, डायमेंशन जॉइन और मीट्रिक विंडो को अलग करें।
- क्या प्रयोग को फिर से चलाया जा सकता है? यदि रॉ लॉग्स से निष्पक्ष पुनर्निर्माण असंभव है, तो वर्तमान नमूने से निष्कर्ष निकालने के बजाय दोष को ठीक करना और फिर से चलाना अधिक उचित है।
30-सेकंड उत्तर रूपरेखा
"मैं शिप नहीं करूंगा। 50/50 आवंटन के साथ, अपेक्षित गणना प्रति समूह 50,000 है। काई-स्क्वायर सांख्यिकी (51,000 - 50,000)² / 50,000 + (49,000 - 50,000)² / 50,000 = 40 है; स्वतंत्रता की एक डिग्री (one degree of freedom) के साथ, p लगभग 2.54 × 10^-10 है। इसलिए अंतिम आबादी में गंभीर सैंपल-रेशियो मिसमैच है, इसलिए व्यावसायिक प्रभाव p-मान लॉन्च का प्रमाण नहीं है। मैं असाइनमेंट, एक्सपोज़र, ट्रिगर, लॉग-प्रोसेसिंग और अंतिम-विश्लेषण चरणों में गणना की तुलना करूंगा, फिर पहले विचलन का पता लगाने के लिए समय, प्लेटफ़ॉर्म, संस्करण और पहचान प्रकार द्वारा विभाजित (segment) करूंगा। कारण को ठीक करने के बाद, मैं SRM, टेलीमेट्री और A/A जांच को फिर से चलाऊंगा; यदि नमूने को पूर्वाग्रह के बिना पुनर्निर्मित नहीं किया जा सकता है, तो मैं प्रयोग को फिर से चलाऊंगा।"
चरण-दर-चरण गहन उत्तर
एक स्पष्ट निर्णय गेट के साथ शुरुआत करें: एक प्रयोग को यादृच्छिकरण, डेटा-अखंडता और व्यावसायिक-प्रभाव जांच पास करनी चाहिए। प्रभाव विश्लेषण से पहले SRM चलाएं और इसे प्रयोग प्लेटफ़ॉर्म पर प्रमुखता से प्रदर्शित करें। Microsoft का प्रकाशित अभ्यास प्लेटफ़ॉर्म पैमाने पर गलत सकारात्मकताओं (false positives) को कम करने के लिए एक रूढ़िवादी अलर्ट थ्रेशोल्ड के रूप में p < 0.0005 का उपयोग करता है। यह एक प्रलेखित उदाहरण है, कोई सार्वभौमिक स्थिरांक नहीं। एक टीम को परिणाम देखने के बाद के बजाय पहले ही अपनी गुणवत्ता सीमा चुननी चाहिए।
चरण 1: SRM की सही गणना करें।
100,000 कुल उपयोगकर्ताओं के साथ 50/50 पर कॉन्फ़िगर किए गए दो वेरिएंट के लिए, प्रत्येक अपेक्षित गणना 50,000 है। काई-स्क्वायर गुडनेस-ऑफ-फिट (goodness-of-fit) सांख्यिकी है:
χ² = Σ (observed - expected)² / expected = 40
दो समूहों और बिना किसी अतिरिक्त अनुमानित पैरामीटर के साथ, स्वतंत्रता की एक डिग्री है, जिससे p लगभग 2.54 × 10^-10 प्राप्त होता है। यह एक रूढ़िवादी अखंडता सीमा से बहुत नीचे है और यह सामान्य आवंटन शोर नहीं हो सकता। काई-स्क्वायर सन्निकटन के लिए पर्याप्त अपेक्षित गणना की आवश्यकता होती है; एक सामान्य NIST नियम प्रति समूह लगभग पाँच अपेक्षित अवलोकनों का है। बहुत छोटे नमूने, दुर्लभ आवंटन, या कई विरल (sparse) वेरिएंट के लिए एक सटीक द्विपद (exact binomial) या बहुपद (multinomial) परीक्षण की आवश्यकता होती है।
अनुपात की व्याख्या उसके नमूना आकार के साथ की जानी चाहिए। यदि कुल 1,000 था और संख्या 510/490 थी, तो अपेक्षित संख्या 500/500 होगी, χ² = 0.4, और p लगभग 0.527 होगा। दिखने वाला 51/49 अनुपात समान है, लेकिन सांख्यिकीय साक्ष्य समान नहीं है।
चरण 2: पहला चरण खोजें जहाँ गणना में विचलन होता है।
एक स्टेज फ़नल बनाएं जो संस्करण द्वारा अद्वितीय रैंडमाइज़ेशन-यूनिट गणना को सुरक्षित रखता है:
| चरण | प्रश्न | विशिष्ट कारण |
|---|---|---|
| असाइनमेंट | क्या हैशिंग और कॉन्फ़िगरेशन ने अपेक्षित विभाजन उत्पन्न किया? | गलत आवंटन, सॉल्ट परिवर्तन, अस्थिर आईडी, ओवरलैप |
| एक्सपोज़र | क्या असाइन किए गए उपयोगकर्ताओं को इच्छित संस्करण प्राप्त हुआ? | परिनियोजन (deployment) विफलता, कैश, रीडायरेक्ट, अनुपलब्ध क्लाइंट |
| ट्रिगर | क्या उपचार से पहले पात्रता जानी जा सकती थी? | केवल-संस्करण लॉगिंग, उपचार द्वारा ट्रिगर संभावना में परिवर्तन |
| लॉग प्रोसेसिंग | क्या दोनों वेरिएंट फैक्ट टेबल में समान रूप से दर्ज हुए? | अनुपलब्ध इवेंट्स, खराब डीडुप, बॉट फ़िल्टर, ड्रॉप हुए जॉइन |
| विश्लेषण | क्या क्वेरी असाइनमेंट सिमेंटिक्स को सुरक्षित रखती है? | पोस्ट-ट्रीटमेंट फ़िल्टर, असमान विंडो, असंगत बहिष्करण (exclusions) |
यदि असाइनमेंट पहले से ही असंतुलित है, तो प्रयोग कॉन्फ़िगरेशन, बकेटिंग कोड और रैंडमाइज़ेशन आईडी का निरीक्षण करें। यदि असाइनमेंट सही है लेकिन एक्सपोज़र में विचलन है, तो संस्करण-विशिष्ट लोड विफलताओं, क्रैश और रीडायरेक्ट का निरीक्षण करें। यदि गैर-ट्रिगर की गई आबादी सही है लेकिन "उपयोगकर्ता जिन्होंने चेकआउट का दौरा किया" सही नहीं है, तो निर्धारित करें कि क्या ट्रिगर उपचार से प्रभावित है या कंट्रोल में गायब है। यदि केवल अंतिम फैक्ट टेबल में विचलन है, तो फ़िल्टरिंग, डीडुप्लीकेशन और जॉइन पर ध्यान केंद्रित करें।
चरण 3: समय और सेगमेंट के साथ कारण का स्थानीयकरण करें।
प्रति घंटे संचयी देखे गए और अपेक्षित गणनाओं को प्लॉट करें और पता लगाएं कि अंतर कब शुरू होता है। एक अचानक विच्छेदन (discontinuity) कॉन्फ़िगरेशन, परिनियोजन या पाइपलाइन परिवर्तन की ओर इशारा करता है। प्रयोग की शुरुआत से एक स्थिर विचलन बकेटिंग या ट्रिगर दोष के साथ अधिक सुसंगत है। प्लेटफ़ॉर्म, ब्राउज़र, ऐप संस्करण, भूगोल, लॉगिन स्थिति, पहचान प्रकार और ट्रैफ़िक स्रोत द्वारा विभाजित करें, जबकि सेगमेंट का आकार, दिशा और पहला असामान्य समय दिखाएं।
विभाजन एक नैदानिक उपकरण है, न कि ऐसे उपसमूह की खोज जो संयोगवश SRM पास कर लेता है। कई स्लाइस स्वाभाविक रूप से कुछ छोटे p-मान उत्पन्न करते हैं। एक उपयोगी स्लाइस एक तंत्र का समर्थन करता है। यदि SRM एक पुराने iOS संस्करण में केंद्रित है और उस संस्करण में उपचार एक्सपोज़र लॉग गायब हैं, तो क्लाइंट डिलीवरी और टेलीमेट्री का निरीक्षण करें; केवल iOS को बाहर न करें और शेष प्रयोग को भरोसेमंद घोषित न करें।
चरण 4: यादृच्छिकरण और पहचान सिमेंटिक्स सत्यापित करें।
बकेटिंग एक स्थिर रैंडमाइज़ेशन आईडी, प्रयोग आईडी और निश्चित सॉल्ट का नियतात्मक फलन (deterministic function) होना चाहिए। एक ही इकाई को पूरे प्रयोग के दौरान एक ही संस्करण में रहना चाहिए। जांचें:
- क्या एक रैंडमाइज़ेशन इकाई कई वेरिएंट में दिखाई देती है।
- क्या खाता आईडी में मर्ज किए जाने पर अनाम आईडी को पुन: असाइन किया जाता है।
- क्या कुकी साफ़ करने या क्रॉस-डिवाइस उपयोग से बार-बार "नए उपयोगकर्ता" बनते हैं।
- क्या कर्मचारी, बॉट और बहिष्करण नियम असाइनमेंट के आसपास लगातार लागू होते हैं।
- क्या प्रत्येक रैंप कॉन्फ़िगरेशन में एक ऑडिट योग्य प्रभावी टाइमस्टैम्प है।
कार्यस्थान या घरेलू यादृच्छिकीकरण के लिए, पहले क्लस्टर गणना का परीक्षण करें। एक उपचार संस्करण यादृच्छिक रूप से कई बड़े कार्यस्थान प्राप्त कर सकता है और बिना किसी बकेटिंग दोष के 51/49 सदस्य-पंक्ति अनुपात दिखा सकता है। सदस्य पंक्तियों को स्वतंत्र यादृच्छिक नमूनों के रूप में मानने से गलत अलार्म उत्पन्न होगा।
चरण 5: उपचार के बाद के चयन और अनुपलब्धता का ऑडिट करें।
जब भी संभव हो उपचार से पहले उपलब्ध जानकारी से एक मान्य ट्रिगर निर्धारित किया जाना चाहिए। "चेकआउट तक पहुंचे" को दोनों वेरिएंट में रिकॉर्ड किए गए पेज एक्सपोज़र के माध्यम से परिभाषित किया जा सकता है। "नए उपचार कूपन बटन पर क्लिक किया" का कंट्रोल में कोई समान अवलोकन नहीं है और स्वाभाविक रूप से अधिक उपचार उपयोगकर्ताओं का चयन करता है। उपचार प्रदर्शन टेलीमेट्री पूर्णता को भी बदल सकता है; बॉट, टाइमआउट और त्रुटि फ़िल्टर उन उपयोगकर्ताओं को हटा सकते हैं जो परिवर्तन से सबसे अधिक प्रभावित हैं।
यह न मानें कि गायब उपयोगकर्ता यादृच्छिक हैं। प्रत्येक डाउनस्ट्रीम तालिका के साथ अपरिवर्तनीय असाइनमेंट लॉग की तुलना करें, गायब आईडी का नमूना लें, और उनके प्लेटफ़ॉर्म, समय, संस्करण और व्यवहार का निरीक्षण करें। यदि उपचार किसी उपयोगकर्ता के विश्लेषण तालिका में प्रवेश करने की संभावना को प्रभावित करता है, तो देखा गया रूपांतरण अंतर चयन पूर्वाग्रह (selection bias) को शामिल करता है।
चरण 6: सुधार, पुनर्निर्माण, या पुन: चलाने में से चुनें।
- गलत आवंटन या क्रॉस-वेरिएंट उपयोगकर्ता: रोकें, असाइनमेंट सुधारें, फिर से यादृच्छिक करें, और फिर से चलाएं।
- प्रतिवर्ती ईटीएल ड्रॉप के साथ पूर्ण असाइनमेंट और एक्सपोज़र: जॉब की मरम्मत करें, निष्पक्ष रॉ इवेंट्स से पुनर्निर्माण करें, और SRM को फिर से चलाएं।
- उपचार-निर्भर ट्रिगर: उपचार-पूर्व स्थिति का उपयोग करें या गैर-ट्रिगर की गई इंटेंट-टू-ट्रीट आबादी पर वापस लौटें।
- बिना बैकफ़िल वाले क्लाइंट संस्करण में आवश्यक टेलीमेट्री गायब होना: इंस्ट्रूमेंटेशन को ठीक करें और उस लक्षित आबादी के लिए फिर से चलाएं।
- नियोजित आवंटन रैंप: प्रत्येक कॉन्फ़िगरेशन अंतराल से अपेक्षित गणनाओं का योग करें और कॉन्फ़िगरेशन इतिहास को सुरक्षित रखें।
वेटिंग केवल तभी उचित है जब चयन तंत्र ज्ञात, अनुमान लगाने योग्य और स्वतंत्र रूप से मान्य हो। अधिकांश SRM संकेत देते हैं कि अनुपलब्धता तंत्र अज्ञात है। 49,000 उपचार उपयोगकर्ताओं को एक वजन से तब तक गुणा करना जब तक कि कुल 50,000 जैसा न दिखे, गायब उपयोगकर्ताओं के व्यवहार को पुनर्स्थापित नहीं करता है या रैंडमाइज़ेशन को पुनर्प्राप्त नहीं करता है।
चरण 7: प्रयोग प्लेटफ़ॉर्म में रोकथाम का निर्माण करें।
अपरिवर्तनीय असाइनमेंट रिकॉर्ड, कॉन्फ़िगर किए गए अनुपात और प्रभावी टाइमस्टैम्प रखें। असाइनमेंट, एक्सपोज़र, ट्रिगर और विश्लेषण की गई आबादी के लिए अलग से SRM की गणना करें। व्यावसायिक परिणामों को तब तक शिप निर्णय नहीं चलाना चाहिए जब तक कि अखंडता जांच पास न हो जाए। यह सत्यापित करने के लिए नियमित A/A परीक्षण चलाएं कि उत्पाद में कोई अंतर न होने पर बकेटिंग, टेलीमेट्री और विश्लेषण साफ रहें।
एक अलर्ट में कुल आकार, देखे गए और अपेक्षित गणना, p-मान, दिशा, पहला असामान्य समय और प्रमुख सेगमेंट शामिल होने चाहिए। परिनियोजन, पहचान, बॉट पहचान या ईटीएल में परिवर्तन के बाद जांच बढ़ाएं। किसी प्रयोग के समाप्त होने के बाद केवल एक डैशबोर्ड छवि को संरक्षित करने के बजाय ऐतिहासिक कॉन्फ़िगरेशन से अपेक्षित गणनाओं को पुन: उत्पन्न करने के लिए पर्याप्त वंशावली (lineage) बनाए रखें।
उच्च गुणवत्ता वाला नमूना उत्तर
"मैं शिप नहीं करूंगा क्योंकि रिपोर्ट किया गया 1.8% लिफ्ट तुलनीय यादृच्छिक नमूनों को मानता है। कॉन्फ़िगर किए गए 50/50 विभाजन के तहत, 51,000 कंट्रोल और 49,000 उपचार उपयोगकर्ताओं की अपेक्षित गणना प्रत्येक 50,000 है। स्वतंत्रता की एक डिग्री के साथ काई-स्क्वायर सांख्यिकी 40 है, इसलिए p लगभग 2.54 × 10^-10 है। प्रयोग में SRM है, और मैं व्यावसायिक निष्कर्ष को फ्रीज कर दूंगा।
पहले मैं सत्यापित करूंगा कि उपयोगकर्ता वास्तविक रैंडमाइज़ेशन इकाई है और पूरे रन के लिए 50/50 लागू था। फिर मैं असाइनमेंट, वास्तविक एक्सपोज़र, ट्रिगर पात्रता, इवेंट फैक्ट-टेबल समावेशन और अंतिम विश्लेषण के माध्यम से गणना की तुलना करूंगा। पहला भिन्न चरण जांच का निर्धारण करता है। असाइनमेंट SRM कॉन्फ़िगरेशन, स्थिर आईडी, सॉल्ट या क्रॉस-वेरिएंट सदस्यता की ओर इशारा करता है। स्वच्छ असाइनमेंट लेकिन असंतुलित एक्सपोज़र परिनियोजन, प्रदर्शन, क्रैश या रीडायरेक्ट की ओर इशारा करता है। केवल-ट्रिगर SRM एक उपचार-निर्भर स्थिति की ओर इशारा करता है। अंतिम-तालिका SRM टेलीमेट्री, बॉट फ़िल्टरिंग, डीडुप्लीकेशन या जॉइन की ओर इशारा करता है।
मैं एक तंत्र के सबूत खोजने के लिए समय, प्लेटफ़ॉर्म, ऐप संस्करण, भूगोल, लॉगिन स्थिति और आईडी प्रकार द्वारा विभाजित करूंगा, न कि किसी स्वच्छ उपसमूह को चेरी-पिक करने के लिए। यदि निष्पक्ष रॉ इवेंट आबादी का पुनर्निर्माण कर सकते हैं, तो मैं पाइपलाइन की मरम्मत करूंगा और प्रत्येक अखंडता जांच को फिर से चलाऊंगा। यदि उपयोगकर्ता वेरिएंट पार कर गए, ट्रिगर उपचार पर निर्भर करता है, या आवश्यक टेलीमेट्री पुनर्प्राप्त नहीं की जा सकती है, तो मैं सिस्टम की मरम्मत करूंगा और प्रयोग को फिर से चलाऊंगा।
रोकथाम के लिए, प्लेटफ़ॉर्म को व्यावसायिक परिणामों को प्रकट करने से पहले SRM चलाना चाहिए, अपरिवर्तनीय असाइनमेंट और आवंटन इतिहास बनाए रखना चाहिए, और असाइनमेंट, एक्सपोज़र, ट्रिगर और विश्लेषण गणनाओं की अलग से निगरानी करनी चाहिए। A/A परीक्षण, स्थिर बकेटिंग और प्री-ट्रीटमेंट ट्रिगर पथ को सत्यापित करते हैं। मूल कारण स्पष्ट होने और सुधारी गई आबादी द्वारा SRM पास करने के बाद ही मैं 1.8% लिफ्ट और इसके गार्डराइल पर पुनर्विचार करूंगा।"
सामान्य गलतियाँ
- शिप करना क्योंकि परिणाम p-मान छोटा है → प्रभाव अनुमान तुलनीय नमूनों को मानता है → पहले SRM और डेटा-अखंडता जांच पास करें।
- केवल 51/49 प्रतिशत को देखना → समान अनुपात अलग-अलग नमूना आकारों में अलग-अलग साक्ष्य रखता है → अपेक्षित गणनाओं और एक सांख्यिकीय परीक्षण का उपयोग करें।
- SRM को केवल एक यादृच्छिक-संख्या समस्या मानना → निष्पादन, लॉग और फ़िल्टर भी उपयोगकर्ताओं को हटाते हैं → पूर्ण पथ के माध्यम से पहले विचलन को ट्रेस करें।
- गणना के करीब दिखने की प्रतीक्षा करना → अधिक पक्षपाती डेटा रैंडमाइज़ेशन को पुनर्स्थापित नहीं करता है → निर्णय को फ्रीज करें और तुरंत निदान करें।
- सीधे 50/50 पर रीवेटिंग करना → भार व्यवस्थित रूप से गायब व्यवहार को पुनर्प्राप्त नहीं करते हैं → केवल एक मान्य अनुपलब्धता मॉडल के तहत सही करें।
- केवल अंतिम विश्लेषण तालिका की जाँच करना → यह छुपाता है कि क्या असाइनमेंट या डाउनस्ट्रीम प्रोसेसिंग विफल रही → हर चरण में गणना बनाए रखें।
- केवल-उपचार व्यवहार पर ट्रिगर करना → कंट्रोल में नमूने में प्रवेश करने का समान मौका नहीं होता है → एक सममित प्री-ट्रीटमेंट स्थिति का उपयोग करें।
- क्लस्टर प्रयोग में सदस्य पंक्तियों का परीक्षण करना → क्लस्टर-आकार भिन्नता गलत SRM बनाती है → पहले वास्तविक रैंडमाइज़ेशन इकाई का परीक्षण करें।
- परिणाम देखने के बाद एक खराब प्लेटफ़ॉर्म को छोड़ना → पोस्ट-हॉक आबादी चयन पूर्वाग्रह जोड़ता है → निदान के लिए स्लाइस का उपयोग करें और नियोजित आबादी को फिर से चलाएं।
- मरम्मत के बाद पुरानी प्रभाव रिपोर्ट का पुन: उपयोग करना → इसकी गणना दोषपूर्ण नमूने से की गई थी → अखंडता, प्रभाव और गार्डराइल विश्लेषण को पुन: उत्पन्न करें।
अनुवर्ती प्रश्न और प्रतिक्रियाएं
अनुवर्ती 1: क्या होगा यदि विभाजन अभी भी 51/49 है लेकिन कुल नमूना केवल 1,000 है?
अपेक्षित गणना प्रत्येक 500 है और देखी गई गणना 510 और 490 है। काई-स्क्वायर सांख्यिकी (510 - 500)² / 500 + (490 - 500)² / 500 = 0.4 है, जो स्वतंत्रता की एक डिग्री के साथ लगभग 0.527 का p मान देती है। यह SRM के लिए अपर्याप्त साक्ष्य है। यही कारण है कि एक निश्चित "एक प्रतिशत से अधिक" नियम एक सांख्यिकीय परीक्षण को प्रतिस्थापित नहीं कर सकता है, हालांकि एक ज्ञात इंजीनियरिंग दोष की अभी भी जांच की जानी चाहिए।
अनुवर्ती 2: समग्र असाइनमेंट SRM पास करता है, लेकिन iOS उपयोगकर्ता विफल हो जाते हैं। क्या प्रयोग का अभी भी उपयोग किया जा सकता है?
स्लाइस की संख्या, iOS नमूना आकार और क्या एक तंत्र विसंगति की व्याख्या करता है, इस पर विचार करें। यदि SRM एक पूर्व-निर्दिष्ट, वास्तविक iOS संस्करण में केंद्रित है और एक्सपोज़र हानि इसकी व्याख्या करती है, तो उस आबादी का परिणाम अविश्वसनीय है। क्या अन्य आबादी प्रयोग करने योग्य रहती है यह विश्लेषण योजना और कारण के सही अलगाव पर निर्भर करता है। केवल परिणाम देखने के बाद iOS को न छोड़ें; क्लाइंट की मरम्मत करना और नियोजित लक्षित आबादी को फिर से चलाना अधिक सुरक्षित है।
अनुवर्ती 3: गैर-ट्रिगर आबादी साफ है, लेकिन ट्रिगर विश्लेषण में SRM है। सबसे अधिक संभावना क्या गलत है?
पहले ट्रिगर का निरीक्षण करें। यह केवल एक संस्करण में लॉग हो सकता है या उपचार के कारण होने वाले व्यवहार पर निर्भर हो सकता है। इसे एक ऐसी स्थिति से बदलें जिसे दोनों समूह उपचार से पहले संतुष्ट कर सकें, जैसे कि नए घटक पर क्लिक करने के बजाय किसी पृष्ठ पर पहुंचना। ट्रिगर टेलीमेट्री कवरेज की भी तुलना करें। स्वच्छ गैर-ट्रिगर गणना बताती है कि आधार असाइनमेंट सही हो सकता है, लेकिन वे ट्रिगर किए गए प्रभाव विश्लेषण को मान्य नहीं करते हैं।
अनुवर्ती 4: समूहों को उनके देखे गए आकारों द्वारा पुन: भारित (reweight) क्यों नहीं किया जाता है?
SRM यह पहचान नहीं करता है कि कौन गायब है। यदि उपचार ने सबसे सक्रिय, उच्चतम-रूपांतरण वाले, या सबसे अधिक क्रैश-प्रवण उपयोगकर्ताओं को खो दिया है, तो एक संख्या भार केवल कुल को पुनर्स्थापित करता है, व्यवहार वितरण को नहीं। सुधार तब संभव हो सकता है जब चयन संभावना पूरी तरह से पूर्व-उपचार चर द्वारा समझाई जाती है और मॉडल मान्य होता है, लेकिन यह एक अतिरिक्त धारणा है, डिफ़ॉल्ट उपाय नहीं।
अनुवर्ती 5: कार्यस्थानों को 50/50 यादृच्छिक किया गया था, लेकिन उपयोगकर्ता गणना 55/45 है। क्या वह SRM है?
पहले कार्यस्थान की संख्या की जाँच करें। यदि कार्यस्थान असाइनमेंट 50/50 है लेकिन उपचार को यादृच्छिक रूप से कई बड़े कार्यस्थान मिले हैं, तो सदस्य असंतुलन बकेटिंग विफलता के बजाय सामान्य क्लस्टर-आकार भिन्नता हो सकता है। परिणाम विश्लेषण में कार्यस्थान के भीतर निर्भरता का भी ध्यान रखना चाहिए। यदि संतुलित सदस्य ट्रैफ़िक की आवश्यकता है, तो बाद में सदस्य पंक्तियों को स्वतंत्र असाइनमेंट के रूप में मानने के बजाय प्रयोग डिज़ाइन में आकार स्तरीकरण (size stratification) या मिलान किए गए रैंडमाइज़ेशन का उपयोग करें।
अनुवर्ती 6: प्रयोग 10/90 से 50/50 तक बढ़ा। आप अपेक्षित गणनाओं की गणना कैसे करते हैं?
प्रत्येक आवंटन अंतराल के भीतर अपेक्षित गणनाओं की गणना करें और उनका योग करें। यदि 20,000 उपयोगकर्ता 10/90 के तहत और 80,000 उपयोगकर्ता 50/50 के तहत आए, तो कुल अपेक्षित गणना 42,000 और 58,000 है, न कि प्रत्येक 50,000। असाइनमेंट के समय सक्रिय कॉन्फ़िगरेशन और प्रभावी समय का उपयोग करें; कभी भी पूरे रन पर पूर्वव्यापी रूप से अंतिम विभाजन लागू न करें।