इस लेख में
जेद्दा 23 सितंबर से 6 अक्टूबर 2026 तक 27वें अरेबियन गल्फ़ कप की मेज़बानी कर रहा है। दो समूहों में बँटी आठ राष्ट्रीय टीमें किंग अब्दुल्ला स्पोर्ट्स सिटी स्टेडियम और प्रिंस अब्दुल्ला अल-फ़ैसल स्टेडियम में खेलेंगी। यह एक खेल की ख़बर है, और ज़्यादातर लोगों के लिए बात वहीं ख़त्म हो जाती है।
लेकिन इसके भीतर एक परिचालन कहानी छिपी है जो जेद्दा और उसके आसपास के हर रेस्तराँ, होटल, दुकान, परिवहन कंपनी और क्लिनिक से जुड़ी है। पूरे दो हफ़्तों तक आपके काउंटर के सामने खड़े ग्राहकों की बनावट बदल जाती है। प्रतिस्पर्धी टीमें इराक़, ओमान, कुवैत, संयुक्त अरब अमीरात, क़तर, बहरीन और यमन से आ रही हैं, और हर टीम अपने साथ ऐसे समर्थक ला रही है जिनके मोबाइल नंबर 964, 968, 965, 971, 974, 973 और 967 से शुरू होते हैं। यानी उस एक कोड के अलावा सात देशों के कोड, जिसके इर्द-गिर्द आपके सिस्टम बनाए गए थे।
ज़्यादातर सऊदी सिस्टमों के नीचे छिपी ख़ामोश मान्यता
राज्य की राष्ट्रीय नंबरिंग योजना के तहत स्थानीय मोबाइल नंबर 05 से शुरू होता है और दस अंकों का होता है। यह एक स्पष्ट नियामक तथ्य है और समस्या यह नहीं है। समस्या यह है कि यह तथ्य कोड में एक कठोर वैलिडेशन नियम के रूप में कैसे पहुँच गया: एक ऐसा फ़ील्ड जो शून्य पाँच से शुरू होने वाले दस अंकों से मेल न खाने वाले हर इनपुट को अस्वीकार कर देता है।
नियम सही लगता है, क्योंकि पूरे साल यह 99 प्रतिशत ग्राहकों के लिए काम करता है। फिर ऐसा कोई पखवाड़ा आता है और यह नियम सुरक्षा न रहकर एक बंद दरवाज़ा बन जाता है। यह अंतर मायने रखता है: सुरक्षा ग़लत इनपुट को अस्वीकार करती है, जबकि यह नियम उस असली ग्राहक को अस्वीकार करता है जो आपको भुगतान करने की कोशिश कर रहा है।
इससे भी बुरा यह है कि यह पैटर्न सिर्फ़ फ़ोन फ़ील्ड में नहीं रहता। यह हर उस जगह दोहराया जाता है जहाँ किसी डेवलपर ने मान लिया कि ग्राहक सऊदी अरब का निवासी है:
- मोबाइल फ़ील्ड। 05 से बँधा, या दस अंकों की तय लंबाई से बँधा वैलिडेशन, खाड़ी देश के नंबर को आपके सर्वर तक पहुँचने से पहले ही अस्वीकार कर देता है।
- वेरिफ़िकेशन कोड। अगर फ़ील्ड नंबर स्वीकार भी कर ले, तो हो सकता है आपके मैसेजिंग प्रदाता ने आपके खाते पर अंतरराष्ट्रीय डिलीवरी चालू न की हो, और ग्राहक नंबर डालकर एक ऐसे संदेश का इंतज़ार करता रहे जो कभी नहीं आता।
- भुगतान पेज। केवल Mada के लिए कॉन्फ़िगर किया गया गेटवे। आगंतुक के पास किसी खाड़ी बैंक का जारी किया हुआ, अंतरराष्ट्रीय नेटवर्क वाला कार्ड है, और उसे एक ऐसा अस्वीकरण दिखता है जिसे वह समझ नहीं पाता।
- पहचान फ़ील्ड। एक या दो से शुरू होने वाला, दस अंकों का अनिवार्य राष्ट्रीय पहचान या निवास नंबर। आगंतुक के पास पासपोर्ट है, और फ़ॉर्म कोई तीसरा विकल्प नहीं देता।
- पता। केवल सऊदी शहरों वाली एक बंद सूची और स्थानीय फ़ॉर्मेट में अनिवार्य पोस्टकोड, वह भी एक ऐसे फ़ॉर्म में जिसे पते की बिल्कुल ज़रूरत नहीं, क्योंकि ऑर्डर शाखा से ख़ुद लेना है।
- भाषा। बुकिंग या भुगतान जैसे महत्वपूर्ण रास्ते पर केवल अरबी इंटरफ़ेस। खाड़ी के आगंतुक अरबी पढ़ते हैं, लेकिन यात्रा कर रहे समर्थकों और उनके साथ आए लोगों का एक हिस्सा नहीं पढ़ता।
इनमें से कुछ भी आपकी रिपोर्टों में क्यों नहीं दिखता
असली ख़तरा यहीं है। जब आपका फ़ॉर्म किसी आगंतुक का नंबर अस्वीकार करता है, तो कुछ भी मापने योग्य नहीं होता। डैशबोर्ड पर कोई असफल ऑर्डर नहीं, लॉग में कोई त्रुटि नहीं, कोई सपोर्ट टिकट नहीं। ग्राहक दो बार कोशिश करता है, टैब बंद करता है, और उस प्रतिस्पर्धी के पास चला जाता है जिसके फ़ॉर्म ने नंबर स्वीकार कर लिया। आप नतीजे को एक व्यस्त हफ़्ते में उम्मीद से थोड़े कम बिक्री आँकड़े के रूप में देखते हैं, और उसे किसी और वजह से समझा लेते हैं।
सिस्टम सफलता को बेहतरीन विस्तार से दर्ज करते हैं और जो शुरू होने से पहले ही विफल हो गया, उस पर चुप रहते हैं। पूरे हुए ऑर्डर का पहले क्लिक से लेकर इनवॉइस तक पूरा रिकॉर्ड रहता है, जबकि ब्राउज़र में वैलिडेशन पर रुका आगंतुक कभी सर्वर तक पहुँचा ही नहीं कि कोई निशान छोड़े। इसलिए यहाँ पहला सुधार फ़ॉर्म में नहीं, बल्कि मापन में है: वैलिडेशन की विफलताओं को एक अलग इवेंट के रूप में दर्ज करें, जिसमें फ़ील्ड का नाम और अस्वीकृति का कारण हो, पर इनपुट ख़ुद सहेजा न जाए। एक हफ़्ते का यह रिकॉर्ड आपको ठीक-ठीक बता देगा कि कौन-सा फ़ील्ड ग्राहकों को लौटा रहा है, और यह उसी तरह की दृश्यता है जिसकी चर्चा हमने आपकी आर्किटेक्चर में वह सिंगल पॉइंट ऑफ़ फ़ेल्योर जो आपको दिखता नहीं में की थी।
23 सितंबर से पहले वास्तव में क्या ठीक किया जा सकता है
पाँच दिन किसी सिस्टम को फिर से बनाने के लिए काफ़ी नहीं हैं, लेकिन ऊपर बताई गई छह बाधाओं को हटाने के लिए ज़रूरत से ज़्यादा हैं, क्योंकि इनमें से ज़्यादातर डेवलपमेंट नहीं, बल्कि कॉन्फ़िगरेशन हैं। नीचे दिया गया क्रम सबसे ज़्यादा असर से नीचे की ओर चलता है:
- मोबाइल फ़ील्ड को अंतरराष्ट्रीय फ़ॉर्मेट के लिए खोलें। डिफ़ॉल्ट रूप से सऊदी अरब पर सेट एक कंट्री-कोड चयनकर्ता, और नंबरों को प्लस चिह्न से शुरू होने वाले एक ही मानक अंतरराष्ट्रीय फ़ॉर्मेट में सहेजना। यह एक ही परत का बदलाव है, और यह सात देशों के बजाय हर देश के लिए समस्या हल करता है।
- टूर्नामेंट से पहले किसी असली खाड़ी नंबर पर वेरिफ़िकेशन डिलीवरी की जाँच करें। यह मानकर न चलें कि यह चालू है। किसी प्रतिस्पर्धी देश के असली नंबर पर कोड भेजें और पुष्टि करें कि वह कुछ सेकंड में पहुँचता है। इस परीक्षण में कुछ मिनट लगते हैं और यह एक ऐसी ख़राबी उजागर करता है जिसकी क़ीमत आपको पूरा पखवाड़ा चुकानी पड़ती।
- अंतरराष्ट्रीय कार्ड और मोबाइल वॉलेट चालू करें। अपने भुगतान प्रदाता से पता करें कि आपके खाते पर वास्तव में कौन-से नेटवर्क सक्रिय हैं, न कि आपके प्लान में सैद्धांतिक रूप से कौन-से उपलब्ध हैं। अगर वॉलेट विकल्प नहीं है तो जोड़ें, क्योंकि यह उस आगंतुक के लिए सबसे तेज़ रास्ता है जो किसी ऐसी साइट पर कार्ड नंबर टाइप नहीं करेगा जिसका उसने कभी उपयोग नहीं किया।
- पहचान फ़ील्ड को वैकल्पिक बनाएँ या पासपोर्ट का विकल्प जोड़ें। अगर यह फ़ील्ड किसी वैधानिक कारण से है, तो उसके पास यह लिखें और पासपोर्ट फ़ॉर्मेट स्वीकार करें। अगर यह आदत के कारण है, तो इसी हफ़्ते इसे हटा दें।
- पते को बंद सूची से मुक्त करें। शहर को मुक्त टेक्स्ट फ़ील्ड बनाएँ और पोस्टकोड को वैकल्पिक, ख़ासकर उन ऑर्डरों में जिनमें कोई डिलीवरी शामिल नहीं है।
- केवल महत्वपूर्ण रास्ते का अनुवाद करें। मेन्यू या उत्पाद सूची, बुकिंग के चरण, भुगतान पेज और रास्ते वाला पेज। आपको मंगलवार तक पूरी साइट का अनुवाद नहीं चाहिए। आपको यह चाहिए कि आगंतुक ख़रीद सके।
सुधारों के ठीक बाद क्षमता का सवाल आता है। यह पीक पूरे दिन में फैला नहीं होता, बल्कि हर मैच से पहले और बाद की दो छोटी अवधियों में सिमटा होता है, और यह काफ़ी हद तक उस पैटर्न जैसा व्यवहार करता है जिसका वर्णन हमने वेतन का दिन और वह पीक जिसकी तारीख़ आप पहले से जानते हैं में किया था, बस एक अंतर के साथ: यह भीड़ भौगोलिक रूप से भी चलती है, एक ही दिशा में, एक ही समय पर।
पखवाड़े भर में आप जो डेटा इकट्ठा करेंगे
राज्य के बाहर से आया कोई आगंतुक आपके सिस्टम में पंजीकरण करता है, तो इसका मतलब है व्यक्तिगत डेटा संरक्षण क़ानून (PDPL) के अधीन व्यक्तिगत डेटा, ठीक वैसे ही जैसे किसी स्थानीय ग्राहक का डेटा। व्यावहारिक बात सीधी है: ऐसा कोई फ़ील्ड इकट्ठा न करें जिसका आप उपयोग नहीं करेंगे। जल्दबाज़ी में बनाए गए फ़ॉर्म में जोड़ा गया हर अतिरिक्त फ़ील्ड एक दायित्व है जो टूर्नामेंट ख़त्म होने के महीनों बाद तक आपके साथ रहता है।
अपने गोपनीयता पेज पर बताएँ कि आप क्या इकट्ठा करते हैं, क्यों, और कितने समय तक रखते हैं, और वह भी ऐसी भाषा में जिसे आगंतुक समझ सके, न कि कॉपी की हुई क़ानूनी शब्दावली में। पखवाड़े में एक बार आपके यहाँ पंजीकरण करने वाला व्यक्ति दस पैराग्राफ़ नहीं पढ़ेगा, लेकिन यह ज़रूर देख लेगा कि आप एक टेबल बुक करने के लिए राष्ट्रीय पहचान नंबर माँग रहे हैं।
Origami का नज़रिया
मौजूदा सिस्टमों की समीक्षा करते समय हमें यह पैटर्न अक्सर मिलता है: तीन साल पहले उस समय सच रही किसी स्थिति के लिए लिखा गया वैलिडेशन नियम, जो बाद में कोड में एक स्थायी फ़ैसले के रूप में पड़ा रह गया और जिस पर किसी ने दोबारा ध्यान नहीं दिया। ग़लती यह नहीं कि किसी डेवलपर ने चूक की। ग़लती यह है कि यह मान्यता कभी किसी समीक्षा योग्य जगह पर लिखी ही नहीं गई, इसलिए यह एक सेटिंग के बजाय ढाँचे का हिस्सा बन गई।
इसीलिए जब हम कोई सिस्टम बनाते हैं, तो वैलिडेशन नियमों को कोड से अलग रखते हैं और उन्हें कॉन्फ़िगरेशन की तरह बरतते हैं, और मोबाइल नंबर हमेशा अंतरराष्ट्रीय फ़ॉर्मेट में सहेजते हैं, भले ही आज हर ग्राहक स्थानीय हो। निर्माण के समय इसकी लागत लगभग शून्य है। दो साल बाद, जब आप दम्माम में बहरीन के आगंतुकों को सेवा देने वाली शाखा खोलते हैं, या जब आपके शहर में कोई टूर्नामेंट आता है, तब इसकी लागत एक घंटे के कॉन्फ़िगरेशन और हफ़्तों में मापी जाने वाली बदलाव परियोजना के बीच का अंतर होती है। हम अपनी सेवाओं के दायरे में जो कुछ भी बनाते हैं, उस पर यही सिद्धांत लागू करते हैं: जो मान्यता आज सही है, उसे कोड की किसी पंक्ति में शर्त के रूप में नहीं, बल्कि एक सेटिंग के रूप में लिखा जाता है।
6 अक्टूबर के बाद क्या बचता है
टूर्नामेंट छह अक्टूबर को ख़त्म हो जाता है। जो हिस्सा आपने ठीक किया, वह ख़त्म नहीं होता। राज्य लगातार बड़े आयोजनों की मेज़बानी करता है, और सीज़न, सम्मेलन और टूर्नामेंट अब कैलेंडर में अपवाद नहीं, बल्कि उसका स्थायी हिस्सा हैं। जो सिस्टम आज राज्य के बाहर से आए आगंतुक को स्वीकार करता है, वह अगले आयोजन में भी बिना किसी अतिरिक्त काम के उसे स्वीकार करेगा।
इस हफ़्ते सबसे छोटे अमल योग्य क़दम से शुरुआत करें: अपनी साइट या ऐप खोलें और किसी असली खाड़ी मोबाइल नंबर और एक गैर-सऊदी कार्ड से पूरी ख़रीदारी करने की कोशिश करें। अगर यह काम कर जाए, तो आप तैयार हैं। अगर आप किसी ख़ास फ़ील्ड पर अटक जाएँ, तो आपने अभी-अभी वह जगह ढूँढ ली है जहाँ से दो हफ़्तों की बिक्री निकल जाने वाली थी।
स्रोत
- Visit Saudi, सऊदी अरब की आधिकारिक पर्यटन साइट — जेद्दा में गल्फ़ कप 27 का पेज और आगंतुकों के लिए आधिकारिक जानकारी।
- सऊदी प्रेस एजेंसी — गल्फ़ कप 27 के टिकटों की बिक्री शुरू होने की आधिकारिक घोषणा।
- संचार, अंतरिक्ष और प्रौद्योगिकी आयोग — राष्ट्रीय नंबरिंग योजना और राज्य में मोबाइल नंबरों का फ़ॉर्मेट।
- सऊदी डेटा और आर्टिफ़िशियल इंटेलिजेंस प्राधिकरण (SDAIA) — व्यक्तिगत डेटा संरक्षण क़ानून और उसके कार्यान्वयन विनियम।
- सऊदी केंद्रीय बैंक (SAMA) — राज्य में भुगतान सेवा प्रदाताओं के लिए नियामक ढाँचा।
सामान्य प्रश्न
मेरी साइट खाड़ी देश का मोबाइल नंबर आख़िर अस्वीकार क्यों करती है?
क्योंकि मोबाइल फ़ील्ड का वैलिडेशन नियम आमतौर पर स्थानीय सऊदी फ़ॉर्मेट से मेल खाने के लिए लिखा जाता है: 05 से शुरू होने वाले दस अंक। जो भी नंबर इस पैटर्न पर खरा नहीं उतरता, वह आपके सर्वर तक पहुँचने से पहले ही ब्राउज़र में अस्वीकार हो जाता है, भले ही वह अपने देश में पूरी तरह वैध हो। समाधान पैटर्न को सात देशों तक बढ़ाना नहीं है, बल्कि नंबरों को एक ही मानक अंतरराष्ट्रीय फ़ॉर्मेट में सहेजना है, साथ में एक कंट्री-कोड चयनकर्ता जो डिफ़ॉल्ट रूप से सऊदी अरब पर हो। यह एक ही परत का बदलाव है जो हर देश के लिए समस्या हल कर देता है।
मुझे कैसे पता चलेगा कि मेरे फ़ॉर्म असली ग्राहकों को लौटा रहे हैं?
आपकी मौजूदा रिपोर्टों से आपको पता नहीं चलेगा, क्योंकि ब्राउज़र में हुई अस्वीकृति न तो कोई असफल ऑर्डर बनाती है और न ही लॉग में कोई त्रुटि। व्यावहारिक तरीका यह है कि वैलिडेशन की विफलताओं को एक अलग इवेंट के रूप में दर्ज करें, जिसमें फ़ील्ड का नाम और अस्वीकृति का कारण हो, लेकिन उपयोगकर्ता ने जो टाइप किया वह सहेजा न जाए। एक हफ़्ते का ऐसा रिकॉर्ड यह दिखाने के लिए काफ़ी है कि कौन-सा फ़ील्ड सबसे ज़्यादा आगंतुकों को लौटा रहा है। सबसे तेज़ परीक्षण यह है कि आप ख़ुद एक असली खाड़ी नंबर और एक गैर-सऊदी कार्ड से पूरी ख़रीदारी करने की कोशिश करें।
क्या टूर्नामेंट से पहले मुझे अपनी पूरी साइट का अनुवाद करना होगा?
नहीं। पाँच दिनों में लक्ष्य पूरी तरह द्विभाषी साइट नहीं, बल्कि ऐसा आगंतुक है जो ख़रीदारी पूरी कर सके। केवल महत्वपूर्ण रास्ते का अनुवाद करें: उत्पाद या खाने की सूची, बुकिंग के चरण, भुगतान पेज, और लोकेशन व रास्ते वाला पेज। बाकी इंतज़ार कर सकता है, और जल्दबाज़ी में घटिया गुणवत्ता का अनुवाद फ़ायदे से ज़्यादा नुक़सान करता है।
क्या डेटा संरक्षण क़ानून राज्य के बाहर से आए आगंतुकों पर भी लागू होता है?
आपके सिस्टम में पंजीकरण करने वाले आगंतुक का डेटा व्यक्तिगत डेटा है और व्यक्तिगत डेटा संरक्षण क़ानून (PDPL) के तहत उस पर वही ज़िम्मेदारी बनती है जो आपके स्थानीय ग्राहक के डेटा पर। सबसे उपयोगी व्यावहारिक नियम यह है कि केवल वही फ़ील्ड इकट्ठा करें जिनका आप वास्तव में उपयोग करेंगे: किसी आयोजन से पहले जल्दबाज़ी में जोड़ा गया हर अतिरिक्त फ़ील्ड आयोजन ख़त्म होने के महीनों बाद तक एक दायित्व बना रहता है, और आपके गोपनीयता पेज पर लिखा होना चाहिए कि आप क्या इकट्ठा करते हैं, क्यों, और कितने समय तक रखते हैं।
Google पर Origami को फ़ॉलो करें
Origami को अपना पसंदीदा स्रोत बनाइए, तो हमारे लेख आपको Google Search और प्रमुख ख़बरों में सबसे पहले दिखेंगे।








