बजट के बिना स्थानीयकरण के ROI का आकलन कैसे करें?

स्थानीयकरण का हर ROI टेम्पलेट आपसे वही दो इनपुट माँगता है: साल भर में इसकी लागत क्या होगी, और आप कितने अपलिफ़्ट की उम्मीद करते हैं। अगर आप किसी टीम में हैं जिसके बजट में स्थानीयकरण की मद है, तो दोनों के जवाब मिल सकते हैं। लेकिन अगर आप अकेले हैं और बस वीकेंड का थोड़ा समय बचता है, तो पहला आँकड़ा लगभग शून्य है और दूसरा ऐसा आँकड़ा जो आप अंदाज़े से गढ़ रहे होंगे। globalize.now AI-संचालित स्थानीयकरण इन्फ्रास्ट्रक्चर है, और यह पेज इस बारे में है कि उस टेम्पलेट को भरने की जगह आप क्या करें।

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

इस पैमाने पर ROI वाला सवाल क्यों टूट जाता है?

क्योंकि गणना के दोनों हिस्से ग़ायब हैं, और उनमें से सिर्फ़ एक ही साफ़ दिखता है।

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

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

इसलिए सवाल का ईमानदार रूप यह नहीं है कि ROI क्या है। वह यह है कि वह सबसे छोटा टेस्ट कौन-सा है जो मुझे बता दे, और अगर नतीजा सपाट आया तो मैं क्या करूँगा।

जब किसी टीम ने इसके लिए पैसा लगाया, तब रिटर्न कैसा दिखा?

बड़ा, देर से आने वाला, और एक स्थायी वेंडर संबंध से जुड़ा हुआ।

इस श्रेणी का सबसे अच्छी तरह दर्ज किया गया मामला आज भी Smallpdf का है, और वह एक वेंडर का है। OneSky की प्रकाशित Smallpdf केस स्टडी के अनुसार (8 अक्टूबर 2026 को दोबारा देखी गई), SEO से मासिक यूज़र 60% बढ़े, यानी 2016 के 60 लाख से 2017 में 95 लाख से ऊपर; 70% से अधिक यूज़र ग़ैर-अंग्रेज़ीभाषी देशों से थे, और थाई, जो उस दौरान जोड़ी गई तीन भाषाओं में सबसे फ़ायदेमंद रही, में एक साल में ट्रैफ़िक 500% से ज़्यादा बढ़ा। उस काम की शुरुआत के समय Smallpdf 17 भाषाओं में था। इन सबको एक वेंडर का, एक ग्राहक के बारे में, एक साल का बयान मानकर पढ़ें।

ROI के सवाल के लिए अहम वाक्य इनमें से कोई नहीं है। उसी स्रोत से, उसी दिन दोबारा देखा गया यह वाक्य है: OneSky के स्वचालित समाधानों ने Smallpdf को नई सुविधाओं और साइट सुधारों के अनुवाद अनुरोध सभी 17 भाषाओं में 1-2 दिनों में निपटाने दिए, जबकि वही काम पहले फ़्रीलांस अनुवादकों के साथ हफ़्तों लेता था। वही लागत की मद है। प्रति शब्द दर नहीं, बल्कि किसी कतार के दूसरे छोर पर बैठा एक वेंडर, जो प्रोडक्ट के हर बदलाव पर खुलती थी।

इसीलिए एंटरप्राइज़ ROI मॉडल वहाँ चलता है और यहाँ नहीं। वह एक ज्ञात आवर्ती लागत की तुलना एक मापे गए रिटर्न से करता है। आपके पास दोनों में से कुछ नहीं है।

जब कोई फ़ंडिंग नहीं कर रहा, तब रिटर्न कैसा दिखता है?

असमान, और औसत पूरी कहानी छिपा लेता है।

Ken Imoto ने अपने ब्लॉग का चार भाषाओं में अनुवाद एक ऐसी प्रक्रिया से किया जिसे वे क्रॉस-लैंग्वेज LLM पाइपलाइन बताते हैं, और बाद में रजिस्टर व लोकेल के हिसाब से हाथ से संपादित किया। उनके GA4 आँकड़े (dev.to पर प्रकाशित, 8 अक्टूबर 2026 को दोबारा देखे गए) 30 अप्रैल से 21 मई 2026 तक के 22 दिन कवर करते हैं: पुर्तगाली 748 पेजव्यू और 709 सेशन, अंग्रेज़ी 195 पेजव्यू और 176 सेशन, जापानी 27 पेजव्यू और 29 सेशन, स्पैनिश 7 पेजव्यू और 7 सेशन। उनके शब्दों में: "यानी एक ही ब्लॉग, एक ही प्रकाशन गति, एक ही लेखक पर पुर्तगाली लगभग 3.8× अंग्रेज़ी, 28× जापानी और 107× स्पैनिश को खींच रही है।"

इसे एक ही क्षण में चार भाषाओं का स्नैपशॉट मानें, क्योंकि असल में यही यह है। एक ही कंटेंट पर पहले-बाद की तुलना नहीं है और स्थानीयकरण से पहले का कोई बेसलाइन प्रकाशित नहीं हुआ। उनके लेखों की संख्या हर भाषा में अलग है, अंग्रेज़ी में 26, जापानी में 25, पुर्तगाली में 17 और स्पैनिश में 10, और उन्होंने प्रति-लेख सामान्यीकरण नहीं दिया, इसलिए आप कोई ऐसा सामान्यीकरण न बनाएँ।

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

वह लागत क्या है जो असल में भारी पड़ती है?

हर बार जब प्रोडक्ट बदले, अनुवाद की ज़िम्मेदारी लेना।

अब एक प्रकाशित मामला है जिसमें किसी ने तय किया कि यह लागत बहुत ज़्यादा है और फ़ैसला पलट दिया। dev.to पर Field Notes #3 के पीछे की साइट (8 अक्टूबर 2026 को दोबारा देखी गई) एक सोलो डेवलपर की साइट है, जिसे वह खुद एजेंट-संचालित बताता है और जिसका ब्लॉग एक AI पाइपलाइन से अनुवादित होता है। उसने इक्कीस भाषाएँ घटाकर छह कर दीं। यह कटौती 24 सितंबर 2026 को हुई, और जैसा प्रकाशित है, वह ट्रैफ़िक की गणना नहीं बल्कि मालिक का फ़ैसला थी। रखी गई भाषाएँ: अंग्रेज़ी, फ़्रेंच, स्पैनिश, रूसी, चीनी, अरबी। बाकी सब, जिनमें जर्मन, जापानी, पुर्तगाली, इतालवी, वियतनामी, पोलिश और एक दर्जन और भाषाएँ शामिल हैं, उसी दिन फ़ाइलों के रूप में मौजूद नहीं रहीं।

उसका बताया कारण गुणवत्ता था। जैसा वह कहता है, ख़राब अनुवाद अनुवाद न होने से भी बुरा पढ़ा जाता है, और रोज़ चलने वाली पाइपलाइन इक्कीस भाषाओं में एक साथ नेटिव-स्तर की गुणवत्ता साबित नहीं कर सकती थी। छह भाषाओं में वह यह कर सकती थी।

जिसके पास स्थानीयकरण का कोई विभाग नहीं है, उसके लिए लागत की असली मद यही है, और वह अनुवाद नहीं है। वह ऐसी समीक्षा है जिसे आप किसी को सौंप नहीं सकते, उन भाषाओं में जिन्हें आप पढ़ नहीं सकते, और जो हर बदलाव पर दोहरानी पड़ती है। यह आपके रखे हुए लोकेल की संख्या के साथ बढ़ती जाती है।

उसी पोस्ट में उसके Search Console आँकड़े भी हैं, और उन्हें सीधे उद्धृत करने के बजाय उनकी सीमाओं के साथ पढ़ना ज़रूरी है। 4 अक्टूबर 2026 को प्रकाशित पिछले 28 दिनों में, रखी गई पाँच लोकेल को 493 इंप्रेशन और 6 क्लिक मिले, और हटाए गए समूह को, रिपोर्ट में दिखाई गई बारह को गिनकर, लगभग 850 इंप्रेशन और 7 क्लिक मिले। इस अवधि की सीमा उसने खुद बताई है: यह कटौती के आर-पार फैली है, इसलिए इसका एक हिस्सा उन भाषाओं को कवर करता है जो तब तक चालू थीं। कुल क्लिक छह और सात हैं, जो किसी भी दिशा में तर्क को सहारा देने के लिए बहुत कम हैं, और लगभग 850 प्रकाशन में अनुमानित है, इसलिए उसे अनुमानित ही रहने दें। उसकी अपनी पोस्ट में पाँच रखी गई लोकेल लिखी है जबकि छह नाम गिनाए गए हैं; हम न तो इसे उसकी ओर से सुलझाएँगे, न इससे प्रति-लोकेल आँकड़े निकालेंगे।

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

तो आप असल में कौन-सा टेस्ट चला सकते हैं?

दो लोकेल, जिन्हें आती हुई माँग के आधार पर चुना जाए, हर लोकेल को अलग से पढ़ा जाए, और निकासी की योजना पहले ही तय हो।

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

इसे दो पर ही रखें। इसलिए नहीं कि पाँच पर काम कठिन है, बल्कि इसलिए कि समीक्षा कठिन है। ऊपर का दूसरा मामला दिखाता है कि तब क्या होता है जब लोकेल की संख्या उस एक चीज़ से आगे निकल जाती है जिसे कोई आपके लिए ऑटोमेट नहीं कर सकता।

शुरू करने से पहले लिख लें कि नुक़सान कैसा दिखेगा और उस पर आप क्या करेंगे। यहाँ के दोनों प्रकाशित मामलों में एक ऐसी लोकेल थी जिसने कोई नतीजा नहीं दिया। अगर आपकी योजना में उस नतीजे के लिए कोई विकल्प नहीं है, तो वह टेस्ट नहीं है।

फिर इसे एक तिमाही दें। Smallpdf के आँकड़े साल-दर-साल के हैं, dev.to का स्नैपशॉट बिना बेसलाइन के 22 दिनों का है, और इनमें से कोई भी दूसरे हफ़्ते के बारे में कुछ नहीं बताता।

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

अब वह टेस्ट चलाने में कितना खर्च आता है?

बदलाव आवर्ती हिस्से में आया है, और ROI मॉडल को सिर्फ़ उसी की परवाह थी।

globalize.now किसी कोडबेस को इन-ऐप कनेक्ट फ़्लो में एक बार कन्वर्ट करता है। यह कन्वर्ज़न एक ही ऑपरेशन है, किसी शेड्यूल पर चलने वाली चीज़ नहीं। इसके बाद पुश जॉब नई कैटलॉग यूनिट आते ही उनका अनुवाद करते हैं, और आपको स्टैंडर्ड JSON या PO मिलता है, वही फ़ॉर्मैट जो आपकी i18n लाइब्रेरी पहले से पढ़ती है। आपके रनटाइम, फ़्रेमवर्क या डिप्लॉयमेंट में कुछ नहीं बदलता, और इसी वजह से किसी लोकेल को हटाना कोई प्रोजेक्ट नहीं, बस एक फ़ाइल-स्तर का काम रह जाता है। सेटअप की जानकारी डेवलपर और वाइब कोडर पेजों पर है।

प्राइसिंग pricing page पर है और यह पेज उसे दोहराने वाला नहीं है।

जो हम अभी नहीं बता सकते

हमारे पास अपने आँकड़े नहीं हैं, और हम उनके होने का संकेत भी नहीं देंगे।

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

आप अभी कहाँ खड़े हैं

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