क्लाइंट-प्रूफ ए/बी टेस्टिंग फ्रेमवर्क: 7 कदम जो किसी भी अकाउंट पर काम करते हैं

सारांश

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

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

यह टेस्टिंग की समस्या नहीं है। यह सिस्टम की समस्या है। यदि आपको हर क्लाइंट के लिए फिर से टेस्ट करने का तरीका खोजना पड़ता है, तो आप ऑप्टिमाइज़ेशन पार्टनर नहीं हैं — आप टेस्ट एक्सक्यूटर हैं। नीचे सात-चरणीय फ्रेमवर्क दिया गया है जो किसी भी क्लाइंट, किसी भी टूल, किसी भी ट्रैफ़िक स्तर पर काम करता है। इसका उपयोग करके तेज़, स्मार्ट टेस्ट चक्र पाएं जो अकाउंट दर अकाउंट बढ़ते हैं।

1. किसी भी वेरिएबल को छूने से पहले सफलता मेट्रिक तय करें

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

हर प्रोजेक्ट की शुरुआत 15-मिनट के गोल ऑडिट से करें। क्लाइंट से पूछें: "कौन सी एक क्रिया, यदि दोगुनी हो जाए, तो इस क्वार्टर को सफल बना देगी?" फिर उस उत्तर को प्राथमिक मेट्रिक में बदलें। इसे टेस्ट के सफलता मानदंड के रूप में उपयोग करें। बाकी सब कुछ — बाउंस रेट, पेज पर समय, द्वितीयक क्लिक — गार्डरेल मेट्रिक बन जाते हैं जिन्हें आप देखते हैं लेकिन ऑप्टिमाइज़ नहीं करते।

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

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

एक बार जब आपके पास प्राथमिक मेट्रिक हो, तो इसे टेस्ट ब्रीफ पर लिखें। ब्रीफ में एक वाक्य में कहा जाना चाहिए, "यह टेस्ट [मेट्रिक] के आधार पर आंका जाएगा।" इसे हर स्टेकहोल्डर के साथ साझा करें। जब बाद में कोई VP कहता है कि "ठीक है, एंगेजमेंट में सुधार हुआ," तो आप ब्रीफ की ओर इशारा करते हैं। आपने गोलपोस्ट नहीं हिलाए। आपने उन पर सहमति जताई थी।

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

2. पसंद के पीछे नहीं, फ्रिक्शन की तलाश करें

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

इन लीवर को खोजने के लिए देखें कि आपके क्लाइंट के उपयोगकर्ता कहाँ छोड़ देते हैं। यदि उनके पास पहले से नहीं है तो सेशन रिकॉर्डिंग या बेसिक इवेंट ट्रैकिंग सेट करें। प्रति क्लाइंट कम से कम पाँच वास्तविक उपयोगकर्ता सेशन देखें। क्लाइंट की राय पर भरोसा न करें कि "उपयोगकर्ताओं को क्या पसंद आएगा।" डेटा राय को हराता है।

ऑडिट करने के लिए सामान्य फ्रिक्शन स्रोत:

• बहुत अधिक या बहुत कम जानकारी मांगने वाले फॉर्म
• CTA जो अगली क्रिया को स्पष्ट रूप से नहीं बताते (जैसे, "और जानें" बनाम "फ्री ट्रायल शुरू करें")
• प्रतिबद्धता के बिंदु के पास विश्वास संकेतों की कमी (टेस्टिमोनियल, गारंटी, मनी-बैक ऑफ़र)
• मोबाइल पर धीमे लोड होने वाले पेज
• आश्चर्यजनक अतिरिक्त कदम वाली यात्राएँ (जैसे, बिना चेतावनी के "साइनअप" फिर "ईमेल सत्यापित करें")

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

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

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

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

3. ऐसी हाइपोथीसिस लिखें जो 'क्या' नहीं, बल्कि 'क्यों' का अनुमान लगाती है

एक अच्छा टेस्ट एक प्रश्न का उत्तर देता है: "यदि हम X करते हैं, तो Y होगा, क्योंकि Z।" "क्योंकि Z" हाइपोथीसिस है, और यही परिणाम को पोर्टेबल बनाता है। "क्यों" के बिना, जीतने वाला टेस्ट आपको अगले क्लाइंट के बारे में कुछ नहीं बताता।

हर टेस्ट को उस "यदि... तो... क्योंकि..." संरचना के साथ तैयार करें। यह आपको तंत्र के बारे में सोचने के लिए मजबूर करता है। "फॉर्म को 5 फील्ड से घटाकर 3 करना" बन जाता है "यदि हम फॉर्म छोटा करते हैं, तो पूर्णता दर बढ़ेगी, क्योंकि उपयोगकर्ता कम प्रयास का अनुभव करते हैं।" अब आप जानते हैं क्यों। आप उस नियम को किसी भी लंबे फॉर्म वाले क्लाइंट पर स्थानांतरित कर सकते हैं।

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

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

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

निश्चित नहीं कि कौन सा रास्ता आपके क्लाइंट के लिए उपयुक्त है? क्लासिक और AI-संचालित टेस्टिंग के बीच ट्रेडऑफ़ को समझना प्रतिबद्ध होने से पहले उचित है।

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

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

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

4. टेस्ट का आकार क्लाइंट के कैलेंडर के अनुसार रखें, अपनी स्टैट्स टेक्स्टबुक के अनुसार नहीं

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

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

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

काम का उदाहरण: एक SaaS क्लाइंट के ट्रायल साइनअप पेज को मामूली लेकिन स्थिर आगंतुक प्रवाह मिलता है। आप एक सार्थक सुधार का पता लगाना चाहते हैं, और आपका सैंपल-साइज़ अनुमान कहता है कि टेस्ट को क्लाइंट के ट्रैफ़िक की तुलना में कहीं अधिक आगंतुकों की आवश्यकता होगी, जो उपलब्ध समय में मिलेगा। क्लाइंट को अपनी बोर्ड बैठक के लिए छह सप्ताह में उत्तर चाहिए। तो आप विभाजन को 50/50 से 90/10 तक चौड़ा करते हैं — लेकिन फिर भी यह पर्याप्त नहीं होगा। इसके बजाय, आप केवल बड़ी जीत पकड़ने के लिए न्यूनतम पता लगाने योग्य प्रभाव कम करते हैं। अब टेस्ट समय सीमा के भीतर व्यवहार्य है, और आपने क्लाइंट को ठीक-ठीक बता दिया है कि टेस्ट क्या पकड़ सकता है और क्या नहीं। यह पेशेवर कदम है।

आपको एक रोकने का नियम भी चाहिए। पहले से तय करें कि टेस्ट कितने समय तक चलता है और आप किस महत्व सीमा का उपयोग करेंगे। कभी भी कैलेंडर तिथि को रोकने का एकमात्र कारण न बनने दें। जानें कि किसी प्रयोग को जल्दी कब रोकें या उसे बढ़ाएँ — आपका निर्णय, एक मनमाना शुक्रवार नहीं, उस शॉट को कॉल करना चाहिए।

5. क्लाइंट को टेस्ट जल्दी बंद करने से रोकें

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

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

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

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

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

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

6. परिणाम को फैसले के रूप में नहीं, कहानी के रूप में पढ़ें

टेस्ट समाप्त होता है। वेरिएंट फिर से जीतता है। लेकिन "कौन सा बटन जीता" सबसे कम उपयोगी चीज है जो आपने सीखी। उपयोगी प्रश्न हैं: यह क्यों जीता? क्या वह स्पष्टीकरण अन्य पृष्ठों पर लागू होता है? हमने इस ऑडिएंस के बारे में क्या खोजा जो हम पहले नहीं जानते थे?

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

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

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

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

जब आप एक शून्य परिणाम प्रस्तुत करते हैं, तो माफी न मांगें। इसे एक डेटा बिंदु के रूप में फ्रेम करें। "हमने सीखा कि हेडलाइन की लंबाई इस ऑडिएंस के लिए कन्वर्ज़न नहीं बदलती। यह हमें इस टेस्ट को फिर से चलाने से बचाता है।" एक शून्य परिणाम एक प्रश्न का साफ उत्तर है। यह विफलता नहीं है।

7. हर परिणाम को एक दोहराने योग्य नियम में बदलें

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

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

प्लेबुक प्रविष्टि के लिए चेकलिस्ट:

• क्लाइंट उद्योग और साइट प्रकार
• परीक्षण किया गया पेज और वेरिएबल
• "यदि... तो... क्योंकि..." रूप में हाइपोथीसिस
• प्राथमिक मेट्रिक परिणाम: जीत, हार, या शून्य
• "क्यों" स्पष्टीकरण जिस पर आप सहमत हुए
• एक क्रिया जिसे आप एक नए क्लाइंट पर दोहराएंगे
• एक क्रिया जिसे आप फिर कभी नहीं आजमाएंगे

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

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

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