r/PPC की एक चर्चा में क्लाइंट खातों में वास्तविक बदलाव करने की पहुँच वाले AI टूल इस्तेमाल कर रहे लोगों से चार सवाल पूछे गए: उसने क्या गलत किया, आप नियंत्रण व्यवस्था कैसे सँभालते हैं, क्या उसने सचमुच काम के घंटे घटाए, और साठ दिनों बाद आपने क्या बंद कर दिया। जवाब किसी टूल की सिफ़ारिश से अधिक उपयोगी चीज़ पर आकर मिले — नियंत्रणों की एक सूची।
यह वही सूची है, जिसे इस तरह लिखा गया है कि आप किसी भी विक्रेता को इन मानकों पर परख सकें, हमें भी।
सात नियंत्रण
1. सिफ़ारिश से पहले डेटा को ताज़ा पढ़ना
दस मिनट पहले लोड किए गए डेटा से योजना बनाने वाला एजेंट पूरे आत्मविश्वास से ऐसी स्थिति पर कार्रवाई करेगा जो अब मौजूद ही नहीं है। लोगों द्वारा बताई जाने वाली सबसे आम विफलता गलत फैसला नहीं है — वह है गलत इनपुट पर पक्का भरोसा: ऐसा फ़ील्ड जिसका API दस्तावेज़ों में उल्लेख है, लेकिन एजेंट ने जिस एज से पूछताछ की वहाँ वह undefined लौटता है और उसे चुपचाप शून्य मान लिया जाता है। यह अनिवार्य करें कि बदलाव को उचित ठहराने वाला डेटा उसी टर्न में पढ़ा जाए जिसमें बदलाव किया जाता है।
2. बदलाव से पहले वास्तविक अंतर, उसका वर्णन नहीं
एजेंट का बयान प्रमाण नहीं है। “मैं खराब प्रदर्शन करने वालों पर बोली घटा दूँगा” एक वाक्य है। 3 लक्ष्यों पर बोली 1.40 → 0.95 वास्तविक अंतर है। समीक्षा सिर्फ़ दूसरे की की जा सकती है।
3. प्रभाव के दायरे पर सीमा
सबसे महँगी विफलता शायद ही कभी एक गलत बदलाव होती है। वह चार सौ ऑब्जेक्ट पर लागू एक गलत बदलाव होती है। प्रभावित ऑब्जेक्ट की संख्या पर हर कॉल के लिए सख्त सीमा माँगें, जिसे कॉल से पहले लागू किया जाए — मॉडल से सावधान रहने को कहकर नहीं।
4. महत्वपूर्ण बदलावों तक सीमित मानवीय पुष्टि
हर चीज़ की पुष्टि करना आपको हर चीज़ पर बिना सोचे क्लिक करना सिखाता है, और दो महीने में आपके पास ऐसा अनुमोदन संवाद रह जाता है जो वास्तव में किसी चीज़ को मंज़ूरी नहीं देता। पुष्टि के चरण को वापस पलटे जा सकने वाले संपादन और पैसों से जुड़ी कार्रवाई में अंतर करना होगा।
5. वर्गीकरण होस्ट के नियंत्रण में हो, टूल के नहीं
अगर किसी कार्रवाई का जोखिम स्तर टूल के अपने विवरण से तय होता है, तो विवरण लिख सकने वाली कोई भी चीज़ अपना जोखिम स्तर घटा सकती है। खुद को “एक छोटी सेटिंग अपडेट करना” कहने वाला टूल अपनी बातों से अनुमोदन से बच न सके। अज्ञात या कस्टम कार्रवाइयों को डिफ़ॉल्ट रूप से संवेदनशील माना जाना चाहिए, सुरक्षित नहीं।
6. ऐसा ऑडिट रिकॉर्ड जिसे आप क्लाइंट को दे सकें
सवाल यह नहीं है कि घटनाएँ कहीं लॉग हो रही हैं या नहीं। सवाल यह है कि क्या माँगे जाने पर आप ऐसा अपरिवर्तनीय रिकॉर्ड दे सकते हैं जिसमें हो कि किसने क्या और कब बदला। उत्पाद टेलीमेट्री यह नहीं है।
7. ज़रूरत पड़ने से पहले बनाया गया बदलाव वापस लेने का तरीका
हर महत्वपूर्ण कार्रवाई के साथ ऐसी कुंजी होनी चाहिए जो उसके बैच को ढूँढ़ सके और उसे वापस पलट सके। कुछ गलत हो जाने के बाद उसे पूर्ववत करने का तरीका तय करना ही एक खराब घंटे को खराब सप्ताह बना देता है।
वह विफलता जिसे इनमें से कोई नहीं पकड़ता
ऊपर के सभी नियंत्रण क्रियान्वयन को नियंत्रित करते हैं। अंतर बताता है कि क्या बदला, लॉग बताता है किसने और कब, और वापसी का तरीका उसे पूर्ववत करता है। इनमें से कोई भी सही और गलत सिफ़ारिश में अंतर नहीं करता — शुरू में दोनों एक जैसी दिखती हैं, और गलत वाली के पक्ष में अक्सर बेहतर तर्क दिए जाते हैं।
एक विक्रेता का बहुचर्चित अनुभव है जिसका ROAS अच्छे 3.5–4x पर था, लेकिन उसने मॉडल की बातों में आकर अभियान फिर से व्यवस्थित किए और पैसा गँवाया। सबसे अधिक वोट वाले जवाब ने वजह बताई: मॉडल आपकी इन्वेंट्री की स्थिति, अनुबंध की सीमाएँ या खाते का इतिहास नहीं जानता। जैसा किसी और ने कहा, उन्हें नहीं पता कि दो अच्छे विकल्पों में से कैसे चुनना है। पैटर्न ढूँढ़ने में ये मॉडल सचमुच मज़बूत हैं। दो तर्कसंगत रणनीतियों में से निर्णय लेने में नहीं।
दूसरी अनपकड़ी विफलता बार-बार उलटफेर करना है: तीन दिन के डेटा पर बोली बढ़ाएँ, दो दिन बाद घटा दें, और लक्ष्य का स्थिर आकलन कभी मिल ही न पाए। बड़े पैमाने पर यह काम करने वाले लोग हर लक्ष्य के लिए पाँच से सात दिन तक दोबारा बदलाव न करने का अंतराल अनिवार्य करते हैं और बताते हैं कि इससे किसी भी मॉडल परिवर्तन से अधिक समस्याएँ ठीक हुईं।
आज Orkas क्या कवर करता है
Orkas स्थानीय उपयोग को प्राथमिकता देने वाला बहु-एजेंट डेस्कटॉप ऐप है। इसके कॉमर्स कनेक्टर — Shopify, Amazon Seller Central, eBay, Etsy, TikTok Shop, Shopee, WooCommerce, Walmart और अन्य — होस्ट के नियंत्रण वाली नीति परत से चलते हैं। इनमें से आठ लागू हैं और चार नहीं। हम चाहते हैं कि आपको यह किसी गलत बदलाव के बाद पता चलने के बजाय यहीं पता चले।
| नियंत्रण | स्थिति | क्या मौजूद है |
|---|---|---|
| कार्रवाई के जोखिम का चार-स्तरीय मॉडल | ✅ | हर कनेक्टर कार्रवाई R / W / H / D है — पढ़ना, लिखना, उच्च प्रभाव वाली, विनाशकारी |
| बदलाव से पहले पूर्वावलोकन | ✅ | लिखने वाली कार्रवाइयाँ तुरंत चलने के बजाय पूर्वावलोकन के साथ पुष्टि माँगती हैं |
| पैसों से जुड़ी कार्रवाइयों पर नई पुष्टि | ✅ | उच्च प्रभाव वाली कार्रवाइयों को बाहरी या वित्तीय बदलाव के रूप में चिह्नित किया जाता है और उनके लिए नई पुष्टि आवश्यक होती है |
| प्रभाव के दायरे पर सीमा | ✅ | एक कार्रवाई कितने ऑब्जेक्ट को प्रभावित कर सकती है, इस पर प्रति-कॉल सीमा, जिसकी जाँच कॉल चलने से पहले होती है |
| पूरी तरह सिर्फ़ पढ़ने वाला कनेक्शन | ✅ | कनेक्टर को क्षमताओं की सूची, कार्रवाई के विवरण और पढ़ने तक सीमित किया जा सकता है |
| होस्ट के नियंत्रण में वर्गीकरण | ✅ | जोखिम कार्रवाई की सटीक पहचान पर आधारित एक निश्चित होस्ट तालिका से तय होता है; टूल के दिए संकेत भरोसे का दायरा नहीं बढ़ा सकते |
| अज्ञात कार्रवाइयों को सुरक्षित रूप से रोकना | ✅ | बिना वर्गीकरण वाली कार्रवाई को उच्च प्रभाव वाली माना जाता है; भरोसेमंद नीति के बिना कॉमर्स कार्रवाई अस्वीकार की जाती है, चलाई नहीं जाती |
| उत्पाद की सीमा तय करने वाली निषिद्ध कार्रवाइयों की सूची | ✅ | कार्रवाइयों की एक निश्चित सूची जो कभी उपलब्ध नहीं कराई जातीं, चाहे कोई भी अनुमति दी गई हो |
| हर क्रिया के लिए अलग अनुमति (बनाना / संपादित करना / रोकना अलग-अलग) | ❌ | अनुमतियाँ जोखिम के स्तर के अनुसार दी जाती हैं, क्रिया के अनुसार अलग नहीं की जातीं |
| खर्च की मौद्रिक सीमा या बजट बदलाव का अधिकतम प्रतिशत | ❌ | सीमा ऑब्जेक्ट की संख्या पर है, राशि पर नहीं |
| बदलाव वापस लेने का तरीका | ❌ | लागू नहीं है। बैच को वापस पलटना हाथ से करना होता है |
| निर्यात किया जा सकने वाला अपरिवर्तनीय ऑडिट लॉग | ❌ | कनेक्टर कॉल टेलीमेट्री के लिए ट्रैक की जाती हैं; वह क्लाइंट को दिया जा सकने वाला ऑडिट रिकॉर्ड नहीं है |
अगर आखिरी चार आपके लिए अनिवार्य आवश्यकताएँ हैं — आमतौर पर तब जब आप ऐसे क्लाइंट के विज्ञापन खाते सँभालते हैं जो ऑडिट माँग सकते हैं — तो Orkas आज उन्हें पूरा नहीं करता, और आपको हर बदलाव पर इंसान की निगरानी रखनी चाहिए।
दूसरा रास्ता: बदलाव करने की पहुँच बिल्कुल न देना
काम के बड़े हिस्से में बदलाव करने की पहुँच उद्देश्य नहीं होती; विश्लेषण होता है। रिपोर्ट निर्यात करें, फ़ाइल स्थानीय कार्यक्षेत्र में रखें और एजेंट को उसे पढ़ने दें। न डेवलपर आवेदन, न अनुमोदन की कतार, न प्रक्रिया में लिखने की अनुमति वाले क्रेडेंशियल। यह किसी एजेंट को अपरिवर्तनीय कार्रवाई की क्षमता देने से पहले उसकी उपयोगिता परखने का सबसे तेज़ तरीका भी है। दो व्यावहारिक उदाहरण: सप्लायर के ट्रैकिंग नंबरों का अपने ऑर्डर से मिलान और साप्ताहिक स्टोर समीक्षा का उपयोग उदाहरण.
इसे खुद बनाने के बजाय खरीदना मुश्किल क्यों है
प्लेटफ़ॉर्म API आमतौर पर मुफ़्त होते हैं। बाधा कीमत नहीं, अनुमोदन है। Amazon के अपने Ads MCP सर्वर के लिए सक्रिय Ads API क्रेडेंशियल चाहिए। Shopify को स्टोर वाले ही संगठन में व्यापारी के स्वामित्व वाला ऐप चाहिए। TikTok Shop को ऐसा Custom App चाहिए जो विक्रेता डेवलपर समीक्षा पास कर चुका हो। eBay को Developers Program का प्रोडक्शन कीसेट और आपकी अपनी हस्ताक्षर कुंजी चाहिए। अकेले काम करने वाले विक्रेता के लिए इनमें से हर चीज़ एक प्रोजेक्ट है, सिर्फ़ फ़ॉर्म नहीं — इसीलिए इतने लोग निर्यात वाला रास्ता अपनाते हैं और कुछ भी कनेक्ट नहीं करते। यह उचित चुनाव है, और उपयोग करने लायक किसी भी टूल को इस तरीके में भी अच्छी तरह काम करना चाहिए।