App Store मेटाडेटा रिजेक्शन: 2.3.x, 2.3.7, 4.3 और 5.2.1 कैसे ठीक करें
अभी-अभी आपको ईमेल मिला है। स्टेटस बदलकर Metadata Rejected हो गया है, और Resolution Center के नोट में एक गाइडलाइन नंबर दिया गया है जिसे आपको खोजना पड़ा। अच्छी खबर यह है कि मेटाडेटा रिजेक्शन को ठीक करना सबसे तेज़ काम है: आप नई बिल्ड अपलोड नहीं कर रहे, बल्कि वर्शन रिकॉर्ड एडिट करके फिर से सबमिट कर रहे हैं।
सबसे पहले जो चीज़ चेक करनी है वह है आपके Resolution Center मैसेज का गाइडलाइन नंबर, क्योंकि वही बताता है कि कौन सी फ़ील्ड ठीक करनी है। इस पोस्ट में उन चार गाइडलाइन्स को कवर किया गया है जो लिस्टिंग रिजेक्शन में सबसे ज़्यादा दिखती हैं। गाइडलाइन नंबर समय के साथ बदलते रहते हैं, तो यहां दिए गए नंबर मौजूदा App Store Review Guidelines के अनुसार हैं।
पहले, मैकेनिक: "Metadata Rejected" का असल मतलब क्या है
Metadata Rejected स्टेटस आपकी स्टोर लिस्टिंग की ओर इशारा करता है — ऐप नाम, सबटाइटल, कीवर्ड, डिस्क्रिप्शन, स्क्रीनशॉट, प्रीव्यू, URL — न कि कंपाइल की गई ऐप की ओर। क्योंकि फ़्लैग मेटाडेटा पर है, आपको नई बाइनरी की ज़रूरत नहीं। आप App Store Connect में बताई गई फ़ील्ड एडिट करते हैं, वर्शन के साथ मौजूदा बिल्ड बनी रहती है, और फिर से सबमिट करते हैं।
यहां दो बातें साफ कहनी ज़रूरी हैं। पहली, फिर से सबमिट करने पर आप फिर से रिव्यू क्यू में जाते हैं, यानी बिल्ड-फ्री तो है लेकिन रिव्यू-फ्री नहीं — कोई इंसान या ऑटोमेटेड पास इसे फिर से देखता है। दूसरी, Apple ने जो एक फ़ील्ड बताई है उसे ठीक करने से बाकी लिस्टिंग सुरक्षित नहीं हो जाती। रिव्यूअर अगली बार किसी और गाइडलाइन पर फ़्लैग लगा सकते हैं। इस मौके पर पूरी लिस्टिंग साफ करें, सिर्फ वह वाक्य नहीं जो आपको वापस कोट किया गया।
गाइडलाइन 2.3.3 — स्क्रीनशॉट में ऐप इस्तेमाल होते हुए दिखना चाहिए
क्या ट्रिगर करता है। आपके स्क्रीनशॉट में ऐप अपना काम करते हुए नहीं दिखता। क्लासिक उदाहरण है पहला स्लॉट जो स्प्लैश स्क्रीन, लॉगिन पेज, या सिर्फ टैगलाइन वाली टाइटल आर्ट हो और उसमें असली UI न हो। यह तब भी ट्रिगर होता है जब स्क्रीनशॉट में ऐसा फ़ीचर दिखे जो ऐप में है ही नहीं, या किसी दूसरे प्लेटफ़ॉर्म का डिवाइस या इंटरफ़ेस दिखे।
पहले: स्लॉट एक में एक ग्रेडिएंट के बीच आपका लोगो और "हफ़्ते की प्लानिंग का सबसे स्मार्ट तरीका" जैसे शब्द हैं, कहीं भी ऐप इंटरफ़ेस नहीं दिखता।
बाद में: स्लॉट एक में एक कोर फ़्लो की असली स्क्रीन है — भरी हुई एंट्रीज़ वाला वीक व्यू — जिसके ऊपर डिवाइस के साथ बेनिफ़िट बताने वाला छोटा कैप्शन है। रिव्यूअर (और यूज़र) थंबनेल से ही समझ जाते हैं कि ऐप क्या करता है। मार्केटिंग कैप्शन और डिवाइस फ़्रेम रखें, बस यह पक्का करें कि नीचे की ऐप UI असली और मौजूदा है।
यह मेटाडेटा बदलाव है: वर्शन रिकॉर्ड में इमेजेस बदलें, फिर से सबमिट करें, नई बिल्ड की ज़रूरत नहीं।
गाइडलाइन 2.3.7 — कीवर्ड आपके ऐप को बताने चाहिए, गेम-सर्च को नहीं
क्या ट्रिगर करता है। यह कीवर्ड-मिसयूज़ की गाइडलाइन है। यह तब ट्रिगर होती है जब आपका मेटाडेटा ऐसे टर्म्स से भरा हो जो आपके ऐप को नहीं बताते: ट्रेडमार्क वाले टर्म्स जिनके आप मालिक नहीं हैं, बड़े या ज़्यादा पॉपुलर ऐप्स के नाम, गलत फ़ील्ड में प्राइसिंग की भाषा, रीच के लिए डाले गए सेलिब्रिटी या पब्लिक-फ़िगर के नाम, या सिर्फ सर्च पकड़ने के लिए ठूंसे गए जेनेरिक फ्रेज़। 100-कैरेक्टर वाली कीवर्ड फ़ील्ड सबसे आम अपराधी है, लेकिन सबटाइटल और नाम भी फ़्लैग होते हैं। ऐप के नाम 30 कैरेक्टर तक सीमित हैं, और नाम, सबटाइटल या स्क्रीनशॉट में प्राइस या प्रमोशनल भाषा नहीं होनी चाहिए।
पहले (कीवर्ड फ़ील्ड): एक लिस्ट जिसमें आपकी कैटेगरी के तीन बड़े ऐप्स के नाम, एक जाने-माने क्रिएटर का नाम, और कुछ असंबंधित ट्रेंडिंग शब्द हैं, जिनमें से कोई भी आपके शिप किए गए फ़ीचर को नहीं बताता।
बाद में: ऐसे कीवर्ड जो उससे मेल खाते हैं जो यूज़र आपका फ़ंक्शन ढूंढने के लिए असल में सर्च करेगा — जो टास्क यह करता है, जो प्रॉब्लम यह सॉल्व करता है, आपकी अपनी स्क्रीन्स के नाउन। हर टर्म को किसी ऐसी चीज़ की ओर इशारा करना चाहिए जो ऐप वाकई करता है।
पहले (सबटाइटल): एक लाइन जो आपको एक नामी प्रतिद्वंद्वी ऐप के मुकाबले पोज़िशन करती है।
बाद में: एक सबटाइटल जो सीधे शब्दों में बताए कि आपका ऐप क्या नतीजा देता है, उसमें किसी और ब्रांड का नाम न हो। सबटाइटल आपके ऐप के कॉन्टेक्स्ट के लिए है, किसी और का ट्रैफ़िक उधार लेने की जगह नहीं।
गाइडलाइन 4.3 — स्पैम और लगभग-डुप्लिकेट ऐप्स
क्या ट्रिगर करता है। 4.3 सेमनेस के बारे में है। यह तब ट्रिगर होती है जब आप अलग-अलग बंडल ID के तहत लगभग एक जैसे कई ऐप्स शिप करते हैं (हर शहर, हर टीम, हर क्लाइंट के लिए अलग बिल्ड, बजाय एक ऐप में वे वेरिएशन शामिल करने के), या जब कोई सबमिशन पहले से मौजूद किसी चीज़ से अलग बताना मुश्किल हो। यह अक्सर कॉन्सेप्ट की समस्या होती है, लेकिन लिस्टिंग ही डुप्लिकेशन को दिखाई देने योग्य बनाती है — आपके अपने ऐप्स में एक जैसी डिस्क्रिप्शन और स्क्रीनशॉट एक मज़बूत संकेत हैं।
पहले: आपके अकाउंट में पांच ऐप्स हैं जिनका लेआउट, फ़ीचर लिस्ट एक जैसी है, और कॉपी सिर्फ शहर या टीम का नाम बदलने से अलग है।
बाद में: एक ऐप जो उन वेरिएशन को इन-ऐप ऑप्शन या परचेज़ की तरह रखता है, और जिसकी लिस्टिंग असल में अलग चीज़ बताती है जो यह करता है। अगर आपके पास वाकई अलग प्रोडक्ट हैं, तो हर लिस्टिंग में स्क्रीनशॉट और डिस्क्रिप्शन में यह दिखाएं कि वह असल में क्या अलग है, सिर्फ किसी नाउन का फ़ाइंड-एंड-रिप्लेस नहीं।
अगर अंदर का ऐप वाकई एक पतला रीस्किन है, तो 4.3 को सिर्फ मेटाडेटा एडिट से ज़्यादा की ज़रूरत हो सकती है। लेकिन जहां समस्या यह हो कि आपकी लिस्टिंग्स एक-दूसरे की क्लोन जैसी लगती हैं, वहां कॉपी और स्क्रीनशॉट को अलग बनाना एक मेटाडेटा फिक्स है।
गाइडलाइन 5.2.1 — आपके मेटाडेटा में किसी और की इंटेलेक्चुअल प्रॉपर्टी
क्या ट्रिगर करता है। ऐसी सुरक्षित थर्ड-पार्टी सामग्री इस्तेमाल करना जिस पर आपका अधिकार नहीं है — ट्रेडमार्क, कॉपीराइट वाले काम, नकल किए गए नाम — आपके बंडल, डेवलपर नाम, या मेटाडेटा में कहीं भी। एक आम वेरिएंट है लिस्टिंग में दिख रहे ऐप या ब्रांड और उसे असल में सबमिट करने वाली एंटिटी के बीच का मिसमैच, जिससे Apple पूछता है कि नाम का मालिक कौन है।
पहले: ऐसा ब्रांड या प्लेटफ़ॉर्म नाम जिसके आप मालिक नहीं हैं, वह आपके ऐप टाइटल, सबटाइटल, या कीवर्ड फ़ील्ड में उसका सर्च ट्रैफ़िक पकड़ने के लिए बैठा है।
बाद में: टाइटल, सबटाइटल और कीवर्ड में आपका अपना प्रोडक्ट नाम। अगर आप वाकई किसी थर्ड-पार्टी प्लेटफ़ॉर्म के साथ इंटीग्रेट करते हैं और यह बताना ज़रूरी है, तो कोई फ़ैक्चुअल कम्पैटिबिलिटी मेंशन डिस्क्रिप्शन में रखें जहां यह अनुमति है, नाम और सबटाइटल में नहीं। अगर आपने किसी क्लाइंट के लिए ऐप बनाया है जो मार्क का मालिक है, तो उसे उस एंटिटी के अकाउंट से सबमिट करें जो उसका मालिक है, या उनकी टीम में जुड़ें, ताकि सेलर नाम और ब्रांड मेल खाएं।
बिल्ड-फ्री वाला हिस्सा, फिर से
इन चारों के लिए, अगर फिक्स वर्शन रिकॉर्ड में है — टेक्स्ट और इमेजेस — तो आप इसे App Store Connect में ठीक करके वही बाइनरी फिर से सबमिट करते हैं। आपको बिल्ड नंबर बढ़ाने या प्रोसेसिंग का इंतज़ार करने की ज़रूरत नहीं। यही वह फ़ास्ट लेन है जो मेटाडेटा रिजेक्शन आपको देता है। इसका ट्रेड-ऑफ़ यह है कि आप फिर से रिव्यू से गुज़रते हैं, तो बेहतर है कि रिज़ेक्शन एक-एक करके ठीक करने के बजाय पूरी लिस्टिंग को इन चार गाइडलाइन्स के मुकाबले पढ़ लें, फिर सबमिट करें।
Mokbi कहां मदद करता है (और कहां नहीं)
ज़्यादातर 2.3.7 की परेशानी लिखने के चरण में शुरू होती है, जब कीवर्ड फ़ील्ड या सबटाइटल को रीच बढ़ाने के लिए भर दिया जाता है। Mokbi का AI आपके ऐप के असल काम से लिस्टिंग कॉपी — नाम, सबटाइटल, कीवर्ड, डिस्क्रिप्शन — तैयार करता है, जिससे आप उन पैडिंग और उधार-लिए-ब्रांड की आदतों से दूर रहते हैं जो शुरुआत में कीवर्ड रिजेक्शन लाती हैं। फिर यह उस कॉपी को 50 भाषाओं में लोकलाइज़ करता है, तो आपको हर मार्केट के लिए अलग से नई कीवर्ड फ़ील्ड लिखकर वही जाल दोबारा बनाने की ज़रूरत नहीं पड़ती।
सीमा के बारे में साफ रहें। इससे वर्डिंग पर 2.3.x या 5.2.1 फ़्लैग लगने की संभावना कम होती है; यह अप्रूवल की गारंटी नहीं दे सकता, और यह तय नहीं करता कि आपकी बिल्ड के अंदर क्या है। रिव्यू का फ़ैसला Apple का है। कंप्लायंट, ऐप-सटीक कॉपी सिर्फ वे आसान, खुद की गलतियों से बने कारण हटाती है जिनसे रिजेक्शन होता है। Mokbi आपकी लिस्टिंग पर ऑटो-पब्लिश नहीं करता — यह कॉपी और स्क्रीनशॉट तैयार करता है; आप उन्हें रिव्यू करके सबमिट करते हैं।