कॉन्टेंट पर जाएँ
28 जुलाई 2026 · हैंडबुक

मैनुअल: शेड्यूल और ऑटोनॉमस रन

यह लेख प्रकाशन के समय प्रोडक्ट का वर्णन करता है। मौजूदा क्षमताओं के लिए AI Builder और Agent Teams देखें।

मैनुअल: शेड्यूल और ऑटोनॉमस रन

अरे — आपने एक ही मैसेज में दो सवाल पूछे: आपकी तीन डोमेन्स के लिए सिंक आपके सेट किए गए समय से एक घंटे देर से क्यों चला, और क्या आपको इसी दौरान अपनी ऑप्टिमाइज़ेशन टीम को स्वायत्त मोड में बदल देना चाहिए। ये दोनों दरअसल एक ही बातचीत निकलती है, तो चलिए इन्हें अलग-अलग जवाब देने की बजाय एक साथ लेते हैं।

सिस्टम की बनावट से शुरुआत करते हैं, क्योंकि इससे दोनों समस्याएं स्पष्ट हो जाती हैं। यहां हर टीम तीन मोड में से किसी एक में चलती है — एक बार, मैनुअल, स्वायत्त — और "स्वायत्त" कोई अलग, ज़्यादा स्मार्ट स्तर नहीं है। यह एक मैनुअल रन है जिसमें एक शेड्यूल जोड़ा गया है और लूप को बंद छोड़ दिया गया है। वही एजेंट, वही गार्डरेल्स, वही सब कुछ, बस बटन दबाने का काम आपकी बजाय एक शेड्यूलर तय करता है। एक बार यह स्पष्ट हो जाए, तो बाकी सब अपने आप समझ में आ जाता है।

आपका सिंक और आपका शेड्यूल अलग-अलग जगह क्यों रहते हैं

शेड्यूल करेंयह क्या संचालित करता है
डेटा सिंकआपके डैशबोर्ड में Search Console / Analytics / स्टोर डेटा का रोज़ाना पुल — बाकी सब कुछ के लिए ईंधन
एजेंट रनहर सिंक के बाद स्वचालित ऑप्टिमाइज़ेशन रन, आपकी ब्रीफ क्यू को फिर से भरने वाले रिसर्च स्वीप, और कोई भी टीम जिसे आप चलती हुई छोड़ देते हैं

आपको सिंक सेटिंग्स हर डोमेन के साथ और रन सेटिंग्स हर टीम के साथ मिलेंगी — एक संयुक्त ऑटोमेशन पेज पर नहीं, जो मुझे पता है कि पहली बार खोजते वक्त अजीब लगता है। लेकिन यह जानबूझकर किया गया है। आपकी सिंक फ्रीक्वेंसी डेटा के बारे में है: Search Console वास्तव में कितनी तेज़ी से रीफ्रेश होता है। आपकी रन फ्रीक्वेंसी टीम के बारे में है: आप चाहते हैं कि वह टीम जो देखे उस पर कितनी तेज़ी से काम करे। ये अलग-अलग सवाल हैं जिनके अलग-अलग जवाब हैं, और इस प्लेटफॉर्म के पहले वर्शन में इन्हें एक पेज पर जोड़ दिया गया था, जिसका मतलब था कि किसी एक को छूने से आप दोनों के बारे में सोचने पर मजबूर हो जाते थे। इन्हें अलग करना ही समाधान था।

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

आपके माइग्रेट किए गए शेड्यूल में असल में क्या गड़बड़ हुई

आपने बताया था कि आपने समय सीधे अपने पुराने टूल से पेस्ट किया था — 14:00 UTC, जिसका मकसद आपके समय के अनुसार दोपहर 2 बजे पहुंचना था। यही असली चूक है। हमारा टाइम फील्ड आपका लोकल क्लॉक चाहता है, UTC नहीं; यह जो टाइमज़ोन पहचानता है वह ठीक नीचे दिखा देता है ताकि आपको कभी अंदाज़ा न लगाना पड़े। वहां UTC वैल्यू पेस्ट करने पर उसे पहले से लोकल मान लिया जाता है, फिर दोबारा UTC में बदला जाता है, और नतीजा यह होता है कि रन 2 बजे की बजाय शाम 4 बजे चलता है। आपकी बाकी दो डोमेन्स के लिए समाधान: पुराना टूल जो भी UTC वैल्यू दे रहा था उसे नज़रअंदाज़ करके समय को लोकल में दोबारा दर्ज करें।

जिस घंटे के बारे में आपने असल में पूछा था — सिंक का 6 बजे की बजाय 7 बजे पहुंचना — वह DST (डेलाइट सेविंग टाइम) का असर है, और इसे हर मार्च और अक्टूबर में परेशान होने की बजाय एक बार समझ लेना अच्छा रहेगा। जनवरी में बर्लिन में 6:00 का सिंक सेट करें तो प्लेटफॉर्म इसे 5:00 UTC के रूप में स्टोर करता है, क्योंकि सर्दियों में बर्लिन UTC+1 पर होता है। एक सामान्य शेड्यूलर हमेशा 5:00 UTC पर ही चलता रहेगा। DST बदलाव आने पर, बर्लिन UTC+2 पर चला जाता है, और वही 5:00 UTC टिक अब लोकल समय के हिसाब से 7:00 बजे पहुंचता है — चुपचाप, बिना किसी एरर के, बस उम्मीद से कुछ घंटे देर से। हम एंट्री के समय मौजूदा ऑफसेट के हिसाब से कन्वर्ट करते हैं, ताकि 6:00 का शेड्यूल हमेशा उस दिन के वॉल-क्लॉक 6:00 बजे का मतलब रखे, चाहे DST हो या न हो। अगर लोकल में समय दोबारा दर्ज करने के बाद भी आपको एक घंटे का अंतर दिख रहा है, तो यह सपोर्ट टिकट के लायक है — ताज़ा दर्ज किए गए शेड्यूल के साथ ऐसा नहीं होना चाहिए।

असली फ्रीक्वेंसी सेट करना

  • सिंक: रोज़ाना, इससे तेज़ नहीं। Search Console का डेटा अच्छे दिन भी दो से तीन दिन पीछे रहकर आता है। आपके तीन डोमेन में हर घंटे सिंक करने से आपको ताज़ा नंबर नहीं मिलेंगे, बस यह सिंक हिस्ट्री को ऐसे जॉब्स से भर देगा जो बार-बार वही पुराना डेटा फेच करते रहेंगे।
  • ऑप्टिमाइज़ेशन: सिंक से जुड़ा हुआ, अलग समय पर नहीं। यह वह हिस्सा है जो आपके शेड्यूल करने के लिए सबसे ज़्यादा मायने रखता है। अगर उस सुबह Google का API धीमा होने के कारण सिंक 6:00 की बजाय 6:02 पर पूरा होता है, तो ऑप्टिमाइज़ेशन रन उसी ताज़ा डेटा पर तुरंत चलता है — यह अपने खुद के 6:15 वाले स्लॉट का इंतज़ार नहीं करता, जिससे यह जोखिम रहे कि अगर सिंक ज़्यादा समय ले तो यह कल के नंबरों पर चल जाए। दो अलग-अलग घड़ियाँ तब तक ठीक लगती हैं जब तक वे एक दिन एक-दूसरे से अलग नहीं हो जातीं।
  • रिसर्च: साप्ताहिक, इस हिसाब से कि आपकी कंटेंट टीम वास्तव में कितना संभाल सकती है। ब्रीफ़ रातों-रात बासी नहीं होतीं, लेकिन क्यू में पड़ी अनरिव्यूड ब्रीफ़ पर भी क्रेडिट खर्च हो चुका होता है, भले ही उन पर कोई काम न करे। अगर आपकी टीम असल में हफ्ते में चार-पांच ब्रीफ़ को मंज़ूरी दे सकती है, तो स्वीप को उतना ही बनाने के हिसाब से सेट करें — रोज़ाना स्वीप और साप्ताहिक रिव्यू की आदत से बस एक ऐसा बैकलॉग बनता है जिसे कोई कभी पूरा नहीं करता।
  • Ads, जब आप अगले महीने उस टीम तक पहुँचेंगे: जानबूझकर कोई शेड्यूल नहीं। ड्राफ़्ट मांग पर जनरेट होते हैं; आपके बिना कुछ भी पोस्ट या खर्च नहीं होता। तर्क autopilot खर्च के खिलाफ तर्क में है, लेकिन संक्षेप में यह है कि कंटेंट सिंक में शेड्यूलिंग की गलती एक मामूली परेशानी है, जबकि ad खर्च में शेड्यूलिंग की गलती एक बिल है। उस टीम की सेटिंग्स आज आप जो सेट कर रहे हैं उससे मिलती-जुलती होंगी, ऐसी उम्मीद न रखें।

तो — क्या आपको ऑप्टिमाइज़ेशन को ऑटोनॉमस पर स्विच कर देना चाहिए?

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

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

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

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

हैंडबुक
शेयर करेंXLinkedInFacebookRedditQuoraव्हाट्सऐपटेलीग्रामईमेल
← सभी पोस्ट