ट्रैफ़िक के बिना A/B परीक्षण: दिशात्मक प्लेबुक

सारांश

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

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

उन परीक्षणों का जाल जिन्हें आप पढ़ नहीं सकते

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

Optimizely शब्दावली के अनुसार, A/B परीक्षण किसी वेबपेज या ऐप के दो संस्करणों की तुलना करने की एक विधि है जिससे यह पता चलता है कि कौन सा बेहतर प्रदर्शन करता है। जोर "निर्धारित करने" पर है। बहुत छोटे नमूने के आकार के साथ, आप कुछ भी निर्धारित नहीं कर रहे हैं। आप अनुमान लगा रहे हैं जिसके साथ एक विश्वास स्कोर जुड़ा है।

यहाँ असहज पहला कदम है: उन A/B परीक्षणों को चलाना बंद करें जिन्हें आप पढ़ नहीं सकते। यह कोई रियायत नहीं है। यह एक रीडायरेक्ट है। जो परीक्षण विश्वसनीय महत्व तक नहीं पहुँचेगा, वह समय, ट्रैफ़िक और ध्यान की बर्बादी है। अपना परीक्षण बजट तब तक बचाएं जब तक आपके पास पर्याप्त डेटा न हो। फिलहाल, एक अलग प्लेबुक का उपयोग करें।

जाइए और देखिए कि लोग क्यों जाते हैं

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

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

यहाँ एक ठोस उदाहरण है। एक प्रोजेक्ट मैनेजमेंट टूल के लिए लैंडिंग पेज की कल्पना करें। पेज को एक लोकप्रिय ब्लॉग पोस्ट से विज़िट की एक स्थिर धारा मिलती है। CTA कहता है "मुफ्त ट्रायल शुरू करें।" आप सत्र रिकॉर्डिंग खोलते हैं और देखते हैं कि आगंतुक मूल्य निर्धारण अनुभाग तक स्क्रॉल करते हैं, फिर चले जाते हैं। मूल्य निर्धारण तालिका में "टीम" नाम की एक योजना है, लेकिन कुछ भी यह स्पष्ट नहीं करता कि "टीम" का क्या मतलब है। वह अस्पष्टता रुकावट है। आप योजना का नाम बदलकर "छोटी टीम (10 तक)" करते हैं और कॉपी समायोजित करते हैं। कोई स्प्लिट टेस्ट नहीं। कोई प्रतीक्षा अवधि नहीं। केवल एक दृश्य बाधा पर लक्षित समाधान।

क्या यह एक गारंटीकृत जीत है? नहीं। यह प्रत्यक्ष अवलोकन पर आधारित एक उच्च-विश्वास समाधान है। जब परित्याग का कारण दिखाई देता है, तो आपको यह बताने के लिए नियंत्रण समूह की आवश्यकता नहीं है कि यह एक समस्या है। आपको इसे हटाने का साहस चाहिए।

छोटा होने का यह मुख्य लाभ है। आप अपने उपयोगकर्ताओं से बात कर सकते हैं, उन्हें वास्तविक दुनिया में देख सकते हैं, और वह पकड़ सकते हैं जो डैशबोर्ड माप नहीं सकता। अपने धन्यवाद पृष्ठ पर एक छोटा सर्वेक्षण चलाएं। उन उपयोगकर्ताओं से पूछें जिन्होंने कन्वर्ट नहीं किया कि उन्हें लगभग किस चीज़ ने जाने के लिए प्रेरित किया। उत्तर पढ़ें। आपको ऐसे पैटर्न मिलेंगे जो कोई भी A/B परीक्षण सतह पर नहीं लाएगा। लोग यह वर्णन करने में बहुत अच्छे होते हैं कि समस्या कहाँ है, भले ही वे आपको यह नहीं बता सकते कि इसे कैसे ठीक किया जाए। उनके व्यवहार को पेज तत्व की ओर आपका मार्गदर्शन करने दें, और शब्दों को ठीक करने के लिए अपने विवेक का उपयोग करें।

इसे एक उचित कार्य की तरह मानें। दो घंटे ब्लॉक करें, अपना ईमेल बंद करें, और एक-एक करके कच्ची सत्र रिकॉर्डिंग पढ़ें। तेज़ी से आगे न बढ़ें। दूसरी बार जब आप वही रुकावट, वही स्क्रॉल, वही हिचकिचाता कर्सर देखते हैं, तो आपको एक पैटर्न मिल गया है। पैटर्न आपके साक्ष्य हैं। एक आगंतुक का मार्ग एक उपाख्यान है; कई आगंतुकों का एक ही काम करना एक सुराग है। वह सुराग एकत्रित डेटा की एक हज़ार पंक्तियों से अधिक मूल्यवान है।

परीक्षण वहाँ लगाएं जहाँ आपका ट्रैफ़िक है

कम-ट्रैफ़िक साइट पर लगभग हमेशा उच्च-ट्रैफ़िक क्षण होते हैं। आपको अपने पतले होमपेज पर परीक्षण करने की आवश्यकता नहीं है। वह पेज या चैनल खोजें जहाँ लोग वास्तव में केंद्रित होते हैं और वहाँ अपना प्रयोग चलाएं।

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

प्रयोग को ट्रैफ़िक घनत्व के साथ मिलाएं। मजबूत ओपन रेट वाला एक स्वागत ईमेल शायद ही कभी विज़िट पाने वाले "अबाउट" पेज की तुलना में बेहतर परीक्षण वातावरण है। खोज ट्रैफ़िक द्वारा संचालित उत्पाद पेज ऐसे होमपेज से बेहतर है जिस पर कोई नहीं उतरता।

शुरू करने से पहले, सत्यापित करें कि आपका स्प्लिट वास्तव में यादृच्छिक है। कुछ उपकरण या मैन्युअल कार्य-साधन गलती से सभी मोबाइल उपयोगकर्ताओं को एक संस्करण में भेज सकते हैं। यह शुरू होने से पहले ही परीक्षण को बर्बाद कर देता है। यदि आपका प्रयोग मंच यादृच्छिकरण संभालता है, तो उस पर भरोसा करें लेकिन एक दिन बाद आवंटन का निरीक्षण करें। यदि आप इसे मैन्युअल रूप से कर रहे हैं, तो आगंतुक प्रकार के बजाय वैरिएंट को घंटे या दिन के अनुसार घुमाएं। स्थिरता यादृच्छिकता से कम महत्वपूर्ण है।

और परिकल्पना को संकीर्ण रखें। "बेहतर डिज़ाइन" का परीक्षण न करें। एक चर का परीक्षण करें: एक हेडलाइन, एक प्रस्ताव, एक फ़ील्ड संख्या। परिवर्तन जितना संकीर्ण होगा, मध्यम ट्रैफ़िक के साथ भी पढ़ना उतना आसान होगा। क्या परीक्षण करना है यह तय करते समय, उस चर के लिए जाएं जिसका आपकी मुख्य कार्रवाई पर सबसे बड़ा संभावित प्रभाव हो, न कि जिसे बदलना सबसे आसान हो। A/B परीक्षणों को प्राथमिकता देने के लिए इस मार्गदर्शिका में सटीक गणना दी गई है।

परिणामों को निर्णायक नहीं, दिशात्मक मानें

यहाँ वह समझौता है जिसे कोई स्टिकी नोट पर नहीं लिखता: सांख्यिकीय कठोरता और गति सीधे संघर्ष में हैं। अधिकांश सर्वोत्तम-अभ्यास लेख मानते हैं कि आप दोनों खर्च कर सकते हैं। आप नहीं कर सकते। इसलिए आपको एक निर्णय नियम की आवश्यकता है जो आपके पैमाने पर काम करे।

95% विश्वास की मांग करना बंद करें। वह सीमा उन टीमों के लिए डिज़ाइन की गई थी जिनके पास उस तक पहुँचने के लिए पर्याप्त ट्रैफ़िक है। इसके बजाय, अपने कम-ट्रैफ़िक परीक्षण को एक दिशात्मक संकेत के रूप में मानें। यदि एक संस्करण स्पष्ट रूप से आगे है और निष्कर्ष रिकॉर्डिंग और सर्वेक्षणों में आपने जो देखा है उससे मेल खाता है, तो आप उस पर कार्य कर सकते हैं—सावधानी से। इसे एक मजबूत परिकल्पना कहें, सिद्ध विजेता नहीं। फिर बाद में सत्यापित करें।

यहाँ अगल-बगल मानसिकता बदलाव है:

	क्लासिक A/B परीक्षण	कम-ट्रैफ़िक प्रयोग
प्रारंभिक बिंदु	"मैं साबित करूँगा कि कौन सा संस्करण जीतता है।"	"मैं सुराग इकट्ठा करूँगा कि क्या मायने रखता है।"
निर्णय सीमा	95% या उससे अधिक पर विश्वास	बड़ा दिशात्मक अंतर और गुणात्मक सहमति
कार्रवाई करने का समय	हफ्ते या महीने	दिन
जोखिम स्तर	कम, क्योंकि आप प्रतीक्षा करते हैं	उच्च, इसलिए आप बाद में सत्यापित करते हैं

क्या इसका मतलब है कि आप कभी-कभी गलत सकारात्मक पर कार्य करेंगे? हाँ। यही ईमानदार लागत है। आप तेज़ी से सीखने के बदले शोर पर कार्य करने का एक छोटा जोखिम स्वीकार करते हैं। विकल्प—जब तक आपके पास पर्याप्त ट्रैफ़िक न हो—इंतज़ार करना, तिमाही के लिए कुछ भी नहीं बदलना है।

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

"महत्वपूर्ण" शब्द का एक तकनीकी अर्थ है। कम-ट्रैफ़िक सेटिंग में, आप उस प्रमाण तक नहीं पहुँचे हैं। इसलिए अपनी भाषा बदलें। कहें "यह दिशा आशाजनक लग रही है" या "डेटा धीरे से सुझाव देता है।" यह भाषा आपको अपने और काम की समीक्षा करने वाले किसी और के साथ ईमानदार रखती है। जब परिणाम वास्तव में भरोसेमंद हो तो गहराई से देखने के लिए, बिना शोर के A/B परीक्षण परिणामों की व्याख्या कैसे करें पढ़ें।

ऑफ़र का परीक्षण करें, रंग-रोगन का नहीं

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

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

उच्च-प्रभाव वाले चर की पहचान करने का एक तरीका यह पूछना है: "यदि कोई आगंतुक इस पेज पर केवल एक पंक्ति पढ़ता है, तो वह क्या होनी चाहिए?" वह पंक्ति आपकी हेडलाइन है। बटन को छूने से पहले वहाँ अपनी परीक्षण ऊर्जा खर्च करें। अगला सवाल: "आगंतुक सबसे अधिक क्या आपत्ति उठाते हैं?" वह आपत्ति आपकी गारंटी है। ऐसी लिखें जो सीधे उसका समाधान करे। ये डिज़ाइन निर्णय नहीं हैं; ये मूल्य निर्णय हैं।

इसे इस तरह सोचें: A/B परीक्षण किसी ऐसी चीज़ को अनुकूलित करने के लिए है जो पहले से काम कर रही है। यदि आपके पेज में आपके द्वारा पेश की जाने वाली चीज़ और आगंतुक की चाहत के बीच मूलभूत बेमेल है, तो कोई भी परीक्षण इसे ठीक नहीं करेगा। पहले ऑफ़र को ठीक करें। फिर परीक्षण करें।

यह छोटी टीमों की क्लासिक गलती है: बुनियादी रूपांतरण लीक को ठीक करने से पहले परीक्षण में कूदना। सबसे आम A/B परीक्षण गलतियों की मार्गदर्शिका बाकी जालों को कवर करती है ताकि आप उन्हें छोड़ सकें।

आपके अगले 30 दिन

यहाँ योजना है, किसी दस-चरणीय ढाँचे की आवश्यकता नहीं।

पहला सप्ताह, ऑडिट। एनालिटिक्स खोलें और अपने सबसे अधिक ट्रैफ़िक वाले पेजों और सबसे तेज़ गिरावट की पहचान करें। सत्र रिकॉर्डिंग देखें। उन सभी को एक सर्वेक्षण भेजें जिन्होंने नहीं खरीदा। हर उस बाधा को सूचीबद्ध करें जो आप देख सकते हैं, आकार के क्रम में।

दूसरा सप्ताह, शीर्ष तीन बाधाओं को सीधे ठीक करें। कोई परीक्षण नहीं। बस कॉपी, लेआउट, फ़ॉर्म या ऑफ़र में सुधार करें। उस रुकावट को हटा दें जिसकी आपने अपनी आँखों से पुष्टि की है।

तीसरा सप्ताह, एकल सबसे अधिक ट्रैफ़िक वाला स्थान चुनें और वहाँ एक नियंत्रित परीक्षण चलाएं। एक चर। देखने से पहले अपना निर्णय नियम परिभाषित करें। इसे तब तक चलने दें जब तक अंतर स्पष्ट न हो या समय समाप्त न हो।

चौथा सप्ताह, निर्णय लें। यदि परिणाम दिशात्मक है और आपके गुणात्मक साक्ष्य से मेल खाता है, तो इसे लागू करें। यदि यह सीमा रेखा है, तो सीख को अगले पुनरावृत्ति में शामिल करें। फिर अगला परीक्षण सेट करें।

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

जब आपका ट्रैफ़िक बढ़ता है—और यह बढ़ेगा—आप पहले से ही जानते होंगे कि क्या परीक्षण करना है, कहाँ करना है, और परिणाम कैसे पढ़ना है। कम-ट्रैफ़िक अवधि बाहर बैठने का समय नहीं है। यह एक अलग खेल चलाने का समय है। उस खेल को अच्छी तरह से खेलें, और बड़ा खेल वहाँ इंतज़ार कर रहा होगा।