Google Play Store Listing Experiments: अपने स्क्रीनशॉट का A/B टेस्टिंग (2026)

Google Play पर, आपको यह अंदाज़ा नहीं लगाना पड़ता कि नया पहला स्क्रीनशॉट पुराने से बेहतर convert करता है या नहीं — आप इसे असली Play Store ट्रैफिक पर टेस्ट कर सकते हैं। Store Listing Experiments Play Console में Test and release → Store listing experiments के तहत built-in हैं (Google ने menu location एक से ज़्यादा बार बदली है; पुरानी guides इसे "Grow → Store listing experiments" कहती हैं)। ये मुफ़्त हैं, आपके live listing पर चलते हैं, और ट्रैफिक split व statistics खुद संभालते हैं।

अगर आप दोनों stores पर ship करते हैं, तो यह Apple के setup का counterpart है। हमने iOS side Product Page Experiments से App Store स्क्रीनशॉट का A/B टेस्टिंग में कवर किया था — वही idea, अलग mechanics। यह post Play-side counterpart है।

Store Listing Experiments कैसे काम करते हैं

आप एक experiment बनाते हैं, चुनते हैं कि कौन सा asset टेस्ट करना है (app icon, स्क्रीनशॉट, feature graphic, preview video, short description, या long description), और अपने current live listing के साथ 3 variants तक अपलोड करते हैं — जो control का काम करता है। Google फिर उन variants को उन users के एक हिस्से को दिखाता है जो आपके store page पर आते हैं, और मापता है कि कौन सा ज़्यादा installs लाता है।

परिणामों में दो metrics मायने रखते हैं:

• Acquisition (store listing conversion). उन visitors का हिस्सा जो किसी दिए गए variant को देखने के बाद install करते हैं। यह स्क्रीनशॉट टेस्ट के लिए headline number है।
• Retained first-time installers (1-day retention). क्या किसी variant के attract किए हुए लोग एक दिन बाद भी टिके रहे। जो variant ज़्यादा installs खींचता है लेकिन retention कमज़ोर देता है, उसने over-promise किया हो सकता है।

Google प्रति variant एक confidence interval calculate करता है, और जब कोई variant आपके चुने confidence threshold को clear करता है, तो उसे winner declare करता है। आप email alert पर opt-in कर सकते हैं ताकि dashboard पर नज़र रखने की ज़रूरत न पड़े। Winner apply करना एक click भर है — लेकिन आम तौर पर आप winning asset को अपने normal release/review flow से भी गुज़ारना चाहेंगे ताकि बाकी listing consistent बनी रहे।

Default graphics बनाम localized experiments

यही वह हिस्सा है जहाँ लोग अटकते हैं, और यह तय करता है कि आप एक साथ कितने टेस्ट चला सकते हैं।

• Default graphics experiment. आपके default store listing पर assets टेस्ट करता है — वह listing जो हर उस user को दिखती है जिसे localized version नहीं मिलता। जिन users को localized assets दिखते हैं, वे इस experiment के audience से बाहर रहते हैं। आप एक समय में सिर्फ एक default graphics experiment चला सकते हैं।
• Localized store listing experiment. किसी specific भाषा के लिए assets (और/या text) टेस्ट करता है। आप एक साथ 5 localized experiments तक चला सकते हैं — जैसे, एक German के लिए, एक Japanese के लिए, एक Brazilian Portuguese के लिए, और आगे भी, सब एक साथ।

व्यावहारिक रूप से: अगर आपका install base मुट्ठी भर markets में concentrated है, तो localized experiments आपको उन markets को parallel में टेस्ट करने देते हैं, बजाय इसके कि आप एक single global test के पीछे queue में लगे रहें। और यह न मान लें कि भाषा = country — "English (United States)" चुनने से audience US तक सीमित नहीं होता; यह हर उस user को target करता है जिसे वह localized listing दिखती है, चाहे वह कहीं भी हो।

स्क्रीनशॉट A/B टेस्ट सेट करना

1. Store listing experiments खोलें और एक बनाएं। Default listing या कोई specific localized listing चुनें, और उसे ऐसा नाम दें जो तीन हफ्ते बाद भी समझ आए ("Hero screenshot — benefit-led caption v2")।
2. Asset चुनें। screenshots select करें। प्रति experiment एक element टेस्ट करें — एक ही टेस्ट में icon और स्क्रीनशॉट दोनों न बदलें, वरना पता नहीं चलेगा कि किसने असर डाला।
3. 3 variants तक अपलोड करें। आपका live listing control है। हर variant सही Play dimensions पर एक पूरा screenshot set है — exact specs के लिए Google Play screenshot size guide देखें।
4. Audience, confidence, और MDE सेट करें। variants में ट्रैफिक allocate करें (आमतौर पर बराबर — एक variant बनाम control के लिए 50/50, या तीन के लिए लगभग एक-तिहाई प्रत्येक)। एक confidence level (90%, 95%, 98%, या 99%) और एक minimum detectable effect चुनें — वह सबसे छोटा improvement जो detect करने लायक हो, लगभग 0.5%–6% के बीच configurable। Play Console completion conditions दिखाता है ताकि शुरू करने से पहले आप देख सकें कि आप किस चीज़ के लिए commit कर रहे हैं।
5. इसे शुरू करें और छेड़ें नहीं। बीच में झाँकने और किसी variant के आगे दिखते ही जल्दी रोकने के मोह से बचें। इसे आपकी तय की गई conditions तक चलने दें।

Sample size, duration, और significance तक पहुँचना

"इसे कितने दिन चलाना चाहिए" का ईमानदार जवाब है: जब तक यह आपकी तय की गई significance conditions तक न पहुँचे — कोई fixed संख्या में दिन नहीं। लेकिन real-world floors और ceilings ज़रूर हैं।

• कम से कम 7 दिन चलाएं। Install behavior weekdays और weekends के बीच बदलता है। एक पूरे हफ्ते से छोटा कुछ भी आपके परिणाम में day-of-week bias घोल देता है। दो हफ्ते (14 दिन) एक common, ज़्यादा safe default है, और low-traffic apps को अक्सर 28 दिन चाहिए होते हैं।
• प्रति variant पर्याप्त installs। Significance आपके install volume, variants की संख्या, आपके confidence level, और आपके MDE का function है। मोटे तौर पर एक working target के रूप में, call पर भरोसा करने से पहले प्रति variant लगभग 1,000+ installs का लक्ष्य रखें — अगर आपने high confidence level या छोटा MDE सेट किया है तो और ज़्यादा।
• Tighter settings ज़्यादा ट्रैफिक माँगती हैं। 99% confidence level या 0.5% MDE को 90% / 3% से कहीं ज़्यादा installers चाहिए होते हैं। अगर आपका ऐप low-volume है, तो एक demanding configuration शायद कभी significance तक न पहुँचे — MDE loose करें या 90% स्वीकार करें।

जो टेस्ट "inconclusive" पर खत्म होता है, वह एक असली outcome है, कोई failure नहीं। इसका मतलब आमतौर पर यह होता है कि variants आपके ट्रैफिक level पर अलग करने के लिए बहुत similar थे, या आपने काफ़ी देर तक नहीं चलाया। दोनों fixable हैं — variants को ज़्यादा distinct बनाएं, या इसे ज़्यादा समय दें।

Variants की limit और इसका मतलब

Control के मुकाबले तीन variants प्रति experiment hard cap है। यह एक feature है, कोई constraint नहीं जिससे लड़ा जाए: हर अतिरिक्त variant आपके ट्रैफिक को पतला बांटता है और significance को और आगे धकेलता है। तीन challengers के साथ आप पहले से ही अपना store ट्रैफिक चार तरीकों से बांट रहे हैं (control + 3)। ज़्यादातर apps के लिए, control के मुकाबले एक bold, साफ़-अलग challenger टेस्ट करना चार धुंधली variations से कहीं तेज़ conclusion तक पहुँचता है।

Slots का इस्तेमाल genuinely अलग hypotheses के लिए करें — एक अलग lead benefit, एक अलग visual style, portrait बनाम एक wide multi-panel layout — न कि एक ही idea की अलग-अलग shades के लिए।

बचने लायक pitfalls

• एक से ज़्यादा variable बदलना। नए स्क्रीनशॉट और एक नया short description एक ही टेस्ट में = एक uninterpretable result। Variable को isolate करें।
• किसी "winner" पर जल्दी रुक जाना। शुरुआती leads regress होती हैं। तीसरे दिन call कर देना क्योंकि कोई variant 8% ऊपर है — यही वह तरीका है जिससे confidence के साथ एक बदतर listing ship होती है।
• 7 दिन से कम चलाना। आप weekly cycle का एक हिस्सा पकड़ेंगे और बाकी miss कर देंगे।
• Low-traffic app पर over-tight stats। मामूली installs के साथ 99% / 0.5% MDE की माँग एक inconclusive, समय के हिसाब से महंगा टेस्ट पक्का करती है।
• 1-day retention को नज़रअंदाज़ करना। जो स्क्रीनशॉट over-promise करता है वह installs बढ़ा सकता है और retention को गिरा सकता है। दोनों numbers पर नज़र रखें।
• Default/localized split भूल जाना। एक default graphics experiment localized listings पर users को touch नहीं करता — अगर आपका audience ज़्यादातर localized है, तो वहीं टेस्ट करें।
• हमेशा सिर्फ last स्क्रीनशॉट टेस्ट करना। पहले 2–3 frames ही Play Store पर ज़्यादातर convincing का काम करते हैं। पहले उन्हें टेस्ट करें। (Play, Apple से कैसे अलग है इस पर और: Play Store बनाम App Store स्क्रीनशॉट के फ़र्क।)

Mokbi कहाँ fit होता है

Mokbi A/B test नहीं चलाता — यह काम Play Console करता है, और वह मुफ़्त है। ज़्यादातर teams को जो चीज़ धीमा करती है वह है variants बनाना: एक credible challenger का मतलब है सही Play dimensions पर एक पूरा screenshot set, जिसमें caption और layout वाकई बदले हों। Mokbi में आप browser में एक set डिज़ाइन करते हैं, फिर उसे duplicate करके lead caption, layout, या background बदलकर variant B बनाते हैं — और अगर आप markets में localized experiments चला रहे हैं तो captions को one-click translate कर सकते हैं। डिज़ाइन watermarked प्रीव्यू के साथ मुफ़्त है; unlimited, watermark-free एक्सपोर्ट और publishing एक subscription के साथ आते हैं — Solo €29.99/mo (1 app) या Studio €49.99/mo (5 apps तक), कोई one-time purchase नहीं। यह contenders जल्दी बनाता है; कौन जीतता है यह Play Console तय करता है।

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

• Product Page Experiments से App Store स्क्रीनशॉट का A/B टेस्टिंग — Apple counterpart
• Play Store बनाम App Store स्क्रीनशॉट के फ़र्क
• Google Play screenshot size guide

एडिटर खोलें →