Rule Coordination (Hinglish) · ScaleSKUs MCP Academy #19

एक rule bid कम कर रहा है क्योंकि recent orders weak हैं। दूसरा rule उसी bid को बढ़ाने की कोशिश कर रहा है क्योंकि कोई और performance signal strong दिख रहा है। तो आप अपनी automation को खुद से लड़ने से कैसे रोकते हैं? शुरुआत यहाँ से करें — ScaleSKUs से पहले existing rules और schedules inspect करवाएं, उसके बाद कोई नया rule propose करें।

इस lesson में हम एक walnut strategy के लिए overlap, priority, cooldowns और action limits review करते हैं। मकसद यह समझना है कि decisions एक ही entity पर आपस में कैसे interact करते हैं — सिर्फ और rules बनाना नहीं है। Saved settings को अपनी proposed settings से अलग request करें, और यह भी पूछें कि system हर type के operation के लिए actually कौन से coordination mechanisms support करता है।

जो account check किया गया है उसमें एक disabled weekly keyword cleanup rule है। यह rule चौदह दिनों का data देखता है, कम से कम बीस clicks और पाँच सौ रुपये का spend require करता है, और zero orders ढूंढता है। इसका proposed action है दस percent bid decrease, जिसमें minimum पाँच रुपये है। इसकी priority एक सौ है, चौबीस घंटे का cooldown है, और approval requirement भी है।

ये existing settings हैं — यह recommendation नहीं है कि इन्हें हर account में copy कर लें। चूँकि यह rule अभी disabled है, इसलिए फिलहाल कोई active collision नहीं बन रही। लेकिन अगर इसे किसी दूसरे overlapping bid rule के साथ enable किया जाए, तो एक future coordination problem बन सकती है — जिसे पहले ही review करना ज़रूरी है।

एक ज़रूरी follow-up question यह है कि क्या priority हर तरह के action को एक universal order में control करती है। इसका verified answer काफी limited है: lower priority number पहले act करता है, लेकिन सिर्फ same type के overlapping operations के लिए। यह negatives, bid increases, bid decreases और budget changes के बीच कोई universal sequence establish नहीं करता।

किसी imagined orchestration feature के आधार पर अपनी strategy मत बनाइए। पहले यह identify करें कि हर rule कौन सी entity और कौन सा operation affect कर सकता है, फिर overlaps explicitly निकालें। एक negative target उस traffic को बदल सकता है जिसे एक bid rule बाद में evaluate करता है — भले ही दोनों rules एक ही field को write करने के लिए compete नहीं कर रहे हों।

Cooldown इसलिए helpful होता है ताकि पिछले action को useful evidence produce करने का time मिले, उससे पहले बार-बार changes न हों। लेकिन यह mature reporting window का substitute नहीं है, और इसे action और business के हिसाब से fit होना चाहिए। एक proposed weekly bid review में existing चौबीस घंटों से लंबा cooldown हो सकता है। यह एक design choice है जिसे evaluate करना है — कोई saved setting या universal best practice नहीं है।

यह भी पूछें कि cooldowns, approval और execution history के साथ कैसे interact करते हैं। अगर कई rules एक ही product या campaign को affect कर सकते हैं, तो check करें कि यह protection उन सभी actions पर apply होती है या सिर्फ individual rule के अंदर। Planning discussion में example safeguards शामिल हैं — जैसे bid movement limit करना, budget increases limit करना, और actions per run cap करना।

इन examples को clearly proposed ही रखें। कुछ भी save करने से पहले इन्हें seller के margins, inventory, growth priorities और budget authority के हिसाब से replace करें। हमें इस business का कोई verified advertising cost target नहीं दिया गया है, इसलिए हमें कोई convenient default insert नहीं करना चाहिए। एक sensible automation plan यह बताता है कि कौन सा business input missing है और उसे कौन provide कर सकता है।

यह यह भी explain करता है कि एक reviewer किसी ऐसे action को कैसे reject कर सकता है जिसकी numerical condition तो meet हो गई हो, लेकिन product context उसे inappropriate बनाता हो। Proposed scope के लिए चारों verified walnut campaigns use करें और जो campaign unresolved है उसे बाहर रखें। फिर existing cleanup rule और proposed strategy के बीच overlap review माँगें।

Affected entity types, operations, conditions, cooldowns और approval requirements की list बनाएं। Day-parting schedules भी check करें — एक schedule किसी budget या bid को independently affect कर सकता है, उस rule से अलग जिसे आप review कर रहे हैं। Checked result में account में अभी कोई active day-parting schedules नहीं हैं, लेकिन जब strategy deploy हो तब इसे दोबारा check करना चाहिए।

Current configuration, potential future conflict और proposed mitigation को अलग-अलग columns में रखें ताकि team हर एक पर सही तरीके से act कर सके। Final output एक coordination brief होना चाहिए — जिसमें real objective, verified scope, operation boundaries, proposed limits, approval steps और review dates हों। यह explain करें कि अगर दो conditions एक साथ satisfy हों तो क्या होगा, और कौन सा behaviour अभी भी preview में validate करना बाकी है।

एक controlled approval-based run से शुरू करें और scope बढ़ाने से पहले proposed actions inspect करें। Practice के लिए, दो ऐसे rules compare करें जो एक ही keyword को touch कर सकते हों। देखें कि क्या वे same field change करते हैं, क्या priority apply होती है, और क्या उनके evidence windows meaningful review allow करते हैं। अच्छी automation एक coherent decision process होती है — individually plausible rules का collection नहीं।