साइटच्या रूट लेआउटमधील (root layout) एका शेअर केलेल्या फंक्शनमुळे A/B-टेस्ट एक्सपोजर काउंटरचे रूपांतर पेज-व्ह्यू काउंटरमध्ये झाले, ज्यामुळे सॅम्पल साईज (sample size) वाढली आणि कन्वर्जन रेट्स (conversion rates) अर्थहीन झाले. होमपेजचे ५०/५० स्प्लिट असलेल्या या टेस्टमध्ये, एका व्हेरिएंटसाठी १७८ हिट्स आणि दुसऱ्यासाठी ५७ हिट्स नोंदवल्या गेल्या—जे अपेक्षित समान स्प्लिटपेक्षा खूपच वेगळे होते.

ही चूक रँडमायझरच्या (randomizer) नजरेतून कशी निसटली

डेव्हलपरने प्रथम व्हिजिटर्सना व्हेरिएंट नियुक्त करणाऱ्या रँडमायझरची पडताळणी केली. त्याने मिडलवेअर (middleware) वाचले, कुकी लॉजिकची (cookie logic) तपासणी केली आणि असा एक स्क्रिप्ट चालवला ज्याने असाइनमेंट फंक्शन १०,००० वेळा कॉल केले; त्यातून अचूक ५०/५० स्प्लिट प्राप्त झाला. रँडमायझर स्वतः व्यवस्थित काम करत होता; समस्या ही होती की एक्सपोजर कसे रेकॉर्ड केले जात होते.

एकाच फंक्शनद्वारे दोन कामे केली जात होती:

१. व्हेरिएंट सेट करणे (Set the variant) – व्हिजिटरचा अनुभव सुसंगत ठेवण्यासाठी प्रत्येक पेज लोडवर हे रन होते. २. एक्सपोजर इव्हेंट रेकॉर्ड करणे (Record the exposure event) – व्हेरिएंट पहिल्यांदा दिसताच, प्रत्येक व्हिजिटरसाठी हे फक्त एकदाच फायर (fire) झाले पाहिजे.

हे फंक्शन रूट लेआउटमध्ये होते, जो प्रत्येक नेव्हिगेशनवर रेंडर (render) होणारा एक घटक (component) आहे. एक्सपोजर-रेकॉर्डिंग कोड प्रत्येक वेळी लेआउट रेंडर होताना कार्यान्वित होत असल्यामुळे, प्रत्येक पेज-व्ह्यू एका नवीन एक्सपोजरप्रमाणे मोजला गेला. होमपेजच्या दोन्ही व्हेरिएंट्समध्ये लेआउट ट्रीज (layout trees) थोडे वेगळे होते, त्यामुळे त्यांचे पेज-व्ह्यू रेट्स वेगवेगळे आले आणि रँडमायझर खराब झाल्याचा आभास निर्माण झाला.

चुकीच्या मोजणीमुळे काय परिणाम झाले

कन्वर्जनचे आकडे—क्लिक-थ्रू, साइन-अप्स, खरेदी—योग्यरित्या नोंदवले गेले होते. परंतु छेदक (denominator - म्हणजेच एक्सपोजरची संख्या) चुकीचा होता. मोजलेले कन्वर्जन रेट्स वास्तवापेक्षा खूपच कमी वाटत होते आणि त्या रेट्सवर आधारित घेतलेले कोणतेही निर्णय अविश्वसनीय होते.

ही तफावत समोर येण्यापूर्वी टेस्ट दोन आठवडे चालली होती, ज्यामुळे टीमला संपूर्ण डेटा सेट फेकून द्यावा लागला.

उपाय

उपाय सोपा होता: जबाबदाऱ्या वेगवेगळ्या फंक्शन्समध्ये विभागणे. एक्सपोजर-रेकॉर्डिंग कोड आता व्हिजिटर आधीच मोजला गेला आहे का हे तपासतो आणि प्रत्येक युजरसाठी फक्त एकदाच फायर होतो. व्हेरिएंट-सेटिंग कोड त्याच्या जागीच राहतो आणि प्रत्येक नेव्हिगेशनवर रन होत राहतो.

प्रयोग करणाऱ्यांसाठी तीन महत्त्वाच्या गोष्टी

  • स्टेट-सेटिंग (state-setting) आणि वन-ऑफ इव्हेंट्स (one-off events) वेगळे ठेवा. जे फंक्शन व्हेरिएंट नियुक्त करते आणि एक्सपोजर देखील लॉग करते, त्यात संघर्ष होईल कारण पहिले वारंवार घडते तर दुसरे नाही.
  • रूट लेआउटमध्ये 'वन-शॉट लॉजिक' (one-shot logic) टाळा. अशा घटकात (component) ठेवलेली कोणतीही गोष्ट जो प्रत्येक पेज लोडवर रेंडर होतो, ती वारंवार कार्यान्वित होईल, ज्यामुळे "प्रत्येक व्हिजिटरसाठी एकदा" याचे रूपांतर "प्रत्येक पेज-व्ह्यूसाठी एकदा" मध्ये होईल.
  • जेव्हा दिसणारे स्प्लिट रँडमायझरच्या विरुद्ध असेल, तेव्हा प्रथम काउंटरची तपासणी करा. डेव्हलपर्स अनेकदा रँडमायझरच्या निष्पक्षतेची चाचणी घेतात, परंतु मोजण्याची यंत्रणा (counting mechanism) अचूक आहे की नाही याची क्वचितच पडताळणी करतात.

पुढे काय पाहावे

एक्सपोजरसाठी सिंगल काउंटरवर अवलंबून असलेल्या कोणत्याही प्रयोगाची, तो काउंटर कंपोनंट ट्रीमध्ये (component tree) कुठे आहे याची तपासणी केली पाहिजे. जर काउंटर ग्लोबल लेआउटमध्ये असेल, तर इव्हेंटला कुकी किंवा लोकल-स्टोरेज फ्लॅग सारख्या कायमस्वरूपी आयडेंटिफायरशी (persistent identifier) जोडणारी तपासणी समाविष्ट करा. टीमने त्यांच्या डॅशबोर्डमध्ये 'सॅनिटी चेक' (sanity check) देखील तयार केला पाहिजे: जर दिसणारे व्हेरिएंट वितरण एका लहान सांख्यिकीय मर्यादेपेक्षा (statistical margin) जास्त विचलित होत असेल, तर रँडमायझर खराब आहे असे मानण्यापूर्वी काउंटर ऑडिटसाठी टेस्टला फ्लॅग करा.

थोडक्यात सांगायचे तर, विश्वासार्ह एक्सपोजर काउंटशिवाय व्यवस्थित काम करणारा रँडमायझरही निरुपयोगी आहे. जबाबदाऱ्यांचे विभाजन करणे आणि वन-ऑफ इव्हेंट्सना नेहमी रेंडर होणाऱ्या कंपोनंट्सच्या बाहेर ठेवणे यामुळे A/B टेस्ट्स अचूक राहतात आणि आठवडेभर वाया जाणारे विश्लेषण वाचते.