Product Page Experiments से App Store स्क्रीनशॉट का A/B टेस्टिंग

Product Page Experiments (PPE) iOS 15 में आया और तब से App Store metadata का A/B टेस्टिंग करने का यही मुख्य तरीका रहा है। आप एक control और तीन treatment variants सेट करते हैं, ट्रैफिक allocate करते हैं, confidence level चुनते हैं, और Apple बताता है कि कौन जीता। infrastructure मज़बूत है; इसे इस्तेमाल करने का अनुशासन हमेशा नहीं होता।

PPE वास्तव में क्या मापता है

PPE product page पर impressions और conversions मापता है। खास तौर पर:

• Impressions: वे users जो आपके product page पर आए।
• Conversions: वे users जिन्होंने landing के बाद Get/Buy tap किया।

यह search-list tap-through नहीं मापता (यानी users पहले आपके search result पर tap करके page तक आते हैं या नहीं)। इसके लिए आपको search-result प्रीव्यू टेस्ट करना होगा, जो आपके default locale के पहले 3 पैनल उपयोग करता है। PPE पूरे कैरोसेल को टेस्ट कर सकता है लेकिन केवल वही मापता है जो user के page पर पहुँचने के बाद होता है।

यह इसलिए मायने रखता है क्योंकि panels 4-10 में बदलाव केवल product-page conversion को प्रभावित करते हैं, जबकि panels 1-3 में बदलाव search-list tap-through और product-page conversion दोनों को प्रभावित करते हैं। PPE दूसरे को मापता है, पहले को नहीं।

"एक बार में एक variable" का नियम

variants के बीच पूरा कैरोसेल बदल देने का मन होता है। मत करें। अगर variant A में नए कैप्शन, नया device tilt, और नया palette है, और variant A जीतता है — तो आप नहीं जानते कि कौन सा बदलाव काम आया। आप अगले टेस्ट में यह सीख भी transfer नहीं कर सकते।

अनुशासन: प्रति टेस्ट एक ही चीज़ बदलें। panel 1 पर नया कैप्शन, बाकी सब वैसा ही। नया background color, कैप्शन एक जैसे। नया panel order, content एक जैसा। धीमा है, लेकिन हर टेस्ट से एक सीख मिलती है जिस पर आगे बढ़ा जा सकता है। शोर पर तेज iteration आगे बढ़ना नहीं है।

Sample size: वह हिस्सा जिसे अधिकांश teams कम आँकती हैं

PPE standard frequentist hypothesis testing उपयोग करता है। आपको जितना sample size चाहिए वह निर्भर करता है:

• आपकी baseline conversion rate (आमतौर पर free apps के लिए 1-5%, paid apps के लिए कम)।
• वह minimum detectable effect जो आपके लिए मायने रखता है (5% relative lift, 10%, 20%?)।
• आपके product page पर ट्रैफिक।

मोटा अनुमान: 3% baseline conversion पर 10% relative lift detect करने के लिए 95% confidence पर प्रति variant ~20,000 impressions चाहिए। अगर आपके app को प्रति सप्ताह 2,000 product-page impressions मिलते हैं, तो प्रति टेस्ट 10 हफ्ते लगेंगे। अधिकांश indie apps के पास छोटे effect sizes पर statistically साफ टेस्ट चलाने का ट्रैफिक नहीं होता। ईमानदार विकल्प:

• केवल बड़े बदलाव टेस्ट करें — palette swap, panel order, मूल रूप से अलग कैप्शन tone। ये टेस्ट जल्दी significance तक पहुँचते हैं क्योंकि effect size बड़ा होता है।
• ट्रैफिक allocation तीन की बजाय एक या दो variants तक सीमित करें।
• Significant नहीं, दिशात्मक स्वीकार करें। अगर कोई variant 4 हफ्तों तक 70% confidence पर लगातार जीत रहा है, तो उसे ship करें और अगला टेस्ट चलाएं।

वह test design जो काम करता है

1. एक hypothesis चुनें। "panel 1 पर बड़े कैप्शन conversion सुधारेंगे क्योंकि thumbnails छोटे कैप्शन को अपठनीय बना देते हैं।" एक specific अनुमान, न कि "देखते हैं क्या काम करता है"।
2. Variant A design करें: एक बदलाव। वही कैरोसेल, केवल panel 1 कैप्शन बदला। बाकी सब एक जैसा।
3. 50% control को, 50% variant को। Two-arm tests, three-arm या four-arm से तेज significance तक पहुँचते हैं।
4. Test duration पहले से तय करें। "हम यह 4 हफ्ते या 95% significance तक, जो पहले हो, चलाएंगे।" बीच में झाँकने और जल्दी बंद करने से बचें।
5. परिणाम document करें। चाहे जीता हो, हारा हो, या अनिर्णायक रहा हो — लिख लें। अगर नहीं लिखा तो भविष्य में छह महीने बाद वही टेस्ट फिर चलाएंगे।

क्या टेस्ट करें, प्राथमिकता क्रम में

1. Panel 1 कैप्शन। सबसे ज़्यादा असर क्योंकि panel 1 search thumbnails और product-page first impression दोनों पर हावी होता है।
2. Panel order। खास तौर पर: आप किस feature से शुरू करते हैं?
3. Carousel palette / dark बनाम light। बड़ा असर, टेस्ट करने में आसान।
4. Device tilt / orientation। छोटा असर लेकिन सेट अप करना सस्ता है।
5. Caption tone (imperative बनाम descriptive)। "Track your runs" बनाम "Your runs, tracked"। छोटा असर, साफ signal पढ़ना मुश्किल।

Fonts, मामूली color shifts, या panel 8-10 content टेस्ट करना बंद करें। ये टेस्ट लगभग कभी significance तक नहीं पहुँचते और underlying effects इतने छोटे होते हैं कि जीत टेस्ट budget के लायक नहीं होती।

PPE में localization

PPE per-locale variants support करता है। अगर आप अपने default locale में टेस्ट चलाते हैं और winner ship करते हैं, तो आपको फिर भी हर localized variant पर manually बदलाव लागू करना होगा। जिस locale में significance तक पहुँचने के लिए पर्याप्त ट्रैफिक हो उसे चुनें (आमतौर पर en-US) और परिणाम को अन्य locales के लिए global दिशात्मक guide मानें। 39 अलग प्रयोग न चलाएं।

सामान्य गलतियाँ

• बीच में झाँकना और जल्दी बंद करना। टेस्ट के दौरान Significance यादृच्छिक रूप से बदलती रहती है। जैसे ही कोई variant जीतता दिखे वैसे ही बंद करने से गलत निष्कर्ष निकलते हैं। एक minimum duration तय करें और उसका सम्मान करें।
• बहुत सारे variables टेस्ट करना। पूरे redesign को cleanly A/B टेस्ट नहीं किया जा सकता। आपको नए design के लिए एक अलग टेस्ट चाहिए (multi-variable, कुछ confounding स्वीकार करें) और फिर winner पर single-variable iteration tests।
• Seasonal noise के दौरान टेस्ट चलाना। Black Friday, App Store featuring, marketing campaigns सभी ट्रैफिक और शोर जोड़ते हैं। इन दौरान टेस्ट न करें जब तक आप spike को control न कर सकें।
• Locale को नज़रअंदाज़ करना। US टेस्ट का परिणाम हमेशा JP पर लागू नहीं होता। इसे starting hypothesis मानें, न कि तय जवाब।

इस महीने क्या करें

1. अपनी sample size ज़रूरतों का अनुमान लगाएं। टेस्ट सेट करने से पहले अपना ट्रैफिक + baseline conversion किसी sample-size calculator में डालें।
2. एक hypothesis चुनें। इसे एक वाक्य में लिखें।
3. एक variable बदला हुआ A बनाम B design करें। App Store Connect में spin up करें।
4. Run duration तय करें और end date अपने calendar पर डालें।
5. परिणाम चाहे जो हो, document करें।

आगे क्या पढ़ें

• Captions जो convert करते हैं
• Top-100 स्क्रीनशॉट कैसे analyze करें

एडिटर खोलें →