Action Forensics (Hinglish) · ScaleSKUs MCP Academy #20

एक bid change हुई, एक negative add किया गया, और एक campaign का budget बढ़ाया गया। क्या इन actions से business actually improve हुआ? शुरुआत यहाँ से करें कि पहले यह prove करें कि हुआ क्या। ScaleSKUs से कहें कि actual account change log inspect करे और हर example के लिए actor, entity, old value, new value और timestamp identify करे।

इस lesson में हम एक walnut keyword bid, एक campaign-level negative और एक budget sequence को review करते हैं। जो actions check किए गए हैं वो user-initiated थे, उनके साथ कोई rule identifier attached नहीं था। इन्हें existing cleanup automation के outcomes की तरह present नहीं करना चाहिए। Action log यह establish करता है कि change हुई — उसका effect establish करने के लिए एक अलग analysis चाहिए।

Walnut kernel keyword की bid September बाईस को बारह बजकर चौबीस मिनट पर पाँच रुपये से बढ़कर छह रुपये हो गई। Log उस exact keyword entity को identify करता है और action को applied record करता है। हमारे पास बाद की query performance evidence भी है, लेकिन bid reporting period के बीच में change हुई और उसके आसपास account में दूसरे changes भी हुए।

इस वजह से कोई simple causal claim नहीं बनाई जा सकती। उसी keyword identifier पर mature pre-change और post-change observations माँगें। Placement mix, traffic, product eligibility और simultaneous edits check करें। किसी दूसरे campaign में similar keyword name होना same entity नहीं है, और market-share increase यह prove नहीं करता कि यह bid change उसकी वजह थी। दूसरे example में exact negative 'walnut two fifty grams' को Campaign four में September बाईस को एक बजकर सात मिनट पर add किया गया है।

इस action के साथ एक task identifier और एक log identifier दोनों हैं, जिससे यह traceable है। Campaign-level exact negative उस query को पूरे account से नहीं हटाता। Campaign eleven उस search को change से पहले ही receive और convert कर रहा था। इससे traffic routing एक plausible intention बनती है, लेकिन यह prove नहीं होता कि action succeed हुआ।

यह पूछें कि वह exact search सभी relevant campaigns में क्या हुई — सिर्फ यह नहीं कि blocked campaign ने बाद में कम spend किया। Pre-change evidence में Campaign four में उस query पर zero orders दिखते हैं, जबकि Campaign eleven उसी query पर पहले से orders produce कर रहा था। बाद की September तेईस से छब्बीस की report में Campaign four की delivery बहुत कम रह गई और Campaign eleven की activity continue रही।

यह routing hypothesis के consistent है, लेकिन attributed orders और sales अभी भी provisional हैं — report की September बाईस की settlement boundary से आगे के लिए। साथ ही, एक negative mechanically उस campaign में eligible traffic reduce करता है। यह prove नहीं करता कि वो auctions कहीं और transfer हो गए। Equal और mature windows compare करें और उस query के total account outcomes देखें।

Success का मतलब है कि useful coverage preserve या improve हो, जबकि inefficient exposure reduce हो। Budget example यह बताता है कि old और new values क्यों matter करती हैं। Campaign eleven September बीस को आठ हजार आठ सौ बारह रुपये अस्सी पैसे से बढ़कर नौ हजार तीन सौ बारह रुपये अस्सी पैसे हो जाता है। September बाईस का एक event चार हजार आठ सौ पंद्रह रुपये चौहत्तर पैसे से शुरू होकर ग्यारह हजार चार सौ छप्पन रुपये चौंसठ पैसे तक बढ़ता है।

Records पहले event की ending value और दूसरे event की starting value के बीच का gap bridge नहीं करते। Story को neat बनाने के लिए कोई reset या external edit invent मत करें। Missing transition को mark करें और relevant change history request करें। आपके review में अब तीन अलग-अलग evidence states हैं। Bid change identifiable है, लेकिन उसका effect timing और दूसरे changes की वजह से confounded है।

Negative का precise scope है और एक plausible routing rationale है, लेकिन mature campaign और account-level comparison चाहिए। Budget change exist करती है, लेकिन sequence को reconcile करना होगा तब जाकर यह एक clean before-and-after study बनेगी। ये distinctions handoff में लिख दें। Exact entity और task identifiers, dates, missing evidence और next decision include करें। इससे यह review किसी दूसरे account manager के लिए useful बनता है — बजाय इसके कि उन्हें एक confident claim मिले जिसे वो reproduce नहीं कर सकते।

अपना weekly review close करते वक्त यह पूछें कि कौन से applied actions outcome evaluation के लिए ready हैं और किन्हें अभी और time या evidence चाहिए। हर action के लिए original reason, approval, exact change और measurement window preserve करें। Mature results को business context में review करें — stock, margin और दूसरे interventions को भी शामिल करते हुए।

किसी user-driven action का credit automation को मत दें, और सिर्फ इसलिए broader autonomy मत दें कि settings sensible लग रही हैं। Confidence build होती है correctly scoped proposals, traceable execution और ऐसे outcomes से जिन्हें evaluate किया जा सके। Practice के लिए अपने account के तीन recent actions audit करें और explain करें कि हर record क्या prove करता है, क्या नहीं करता, और अगला evidence check क्या होगा।