हर चीज़ की सस्ती जांच करें, ज़रूरत वाले थोड़े मामलों की गहराई से जांच करें

10,000 संपर्क अपडेट के एक काल्पनिक बैच पर विचार करें. हर रिकॉर्ड के फ़ील्ड पर नए निर्णय के लिए मॉडल चलाया जा सकता है. इससे मैपिंग का एक निर्णय 10,000 दोहराए हुए निर्णयों में बदल जाएगा.

सस्ते सवाल से शुरू करें: क्या यह रिकॉर्ड स्वीकृत मैपिंग की ज्ञात शर्तें पूरी करता है? फ़ील्ड की मौजूदगी, डेटा प्रकार, स्कीमा संस्करण और स्पष्ट सहमति की शर्तें कोड में जांचें. जो रिकॉर्ड विफल हों या अस्पष्ट रहें, उन्हें सीमित समीक्षा में भेजें.

यह उदाहरण का डिज़ाइन है, Tajo का प्रदर्शन मानक नहीं. रोचक संख्या यह नहीं कि पहली जांच कितने रिकॉर्ड पास करती है. सवाल है कि कितनी महत्वपूर्ण त्रुटियों को वह गलती से पास करती है.

इस चर्चा का विशेषज्ञ वर्कफ़्लो पहले सामान्य या असामान्य की व्यापक छंटाई करता है, फिर चिह्नित मामलों पर आगे विश्लेषण करता है. उस क्षेत्र के जोखिम और प्रमाण मार्केटिंग डेटा से अलग हैं. स्रोत चरणबद्ध निर्णय दिखाता है, उसकी पहली एल्गोरिदमिक जांच की लागत या निर्धारकता नहीं. इंटीग्रेशन में सस्ती निर्धारक जांच ज्ञात शर्तें संभाल सकती है, जबकि अनिश्चित मामले सावधानी से देखे जाते हैं.

पहली जांच सामान्य मामले तय करे

अच्छी पहली जांच उपलब्ध प्रमाण से ऐसा सवाल पूछती है जिसका जवाब कोड दे सके. “क्या स्रोत फ़ील्ड मौजूद है?” एक सवाल है. “क्या यह मान डेस्टिनेशन के घोषित प्रकार से मेल खाता है?” दूसरा है. “क्या यह वही स्कीमा संस्करण है जिसके लिए मैपिंग स्वीकृत हुई थी?” तीसरा है.

नियम हर पंक्ति पर बिना नई व्याख्या गढ़े चल सकता है. वह अपना जवाब भी समझा सकता है. रोकी गई पंक्ति बता सकती है कि डेस्टिनेशन का birthday फ़ील्ड तारीख चाहता है, जबकि स्रोत ने स्वतंत्र पाठ दिया. यह “AI का भरोसा कम है” से ज़्यादा उपयोगी है.

Tajo की Brevo कनेक्टर गाइड बताती है कि डेस्टिनेशन की एट्रिब्यूट परिभाषाएं क्यों महत्वपूर्ण हैं. कनेक्टर HTTP अनुरोध भेज सकता है, जबकि प्राप्त करने वाला सिस्टम अघोषित एट्रिब्यूट अनदेखा कर दे. घोषित फ़ील्ड की पहले की जांच लिखने से पहले एक प्रकार की त्रुटि पकड़ती है. बाद में रिकॉर्ड फिर पढ़ना दूसरी तरह की त्रुटि पकड़ सकता है. दोनों को संपर्क “ठीक दिखता है” वाली मॉडल राय न समझें.

उद्देश्य निर्णय को मिटाना नहीं, बल्कि उसे उन सवालों के लिए बचाना है जिनमें निर्णय चाहिए.

1. नया सिंक बैच

2. पहले

   ज्ञात नियम जांचें

   • पहचान, फ़ील्ड प्रकार और अकाउंट का दायरा
3. फिर

   स्पष्ट परिणाम तय करें

   • सामान्य रिकॉर्ड पास करें; ज्ञात विफलता रोकें
4. केवल ज़रूरत पर

   अनसुलझे मामले देखें

   • वह प्रमाण जांचें जिसे नियम तय नहीं कर सके

5. जांचा हुआ परिणाम या स्पष्ट रोक

महंगी जांच को सही मामले चाहिए

मान लें कि उदाहरण के 10,000 में से 9,800 रिकॉर्ड पहली जांच पार कर गए. बाकी 200 को गहराई से देखा गया. यह कुशल लगता है. लेकिन 9,800 में से नमूना और 200 के परिणाम जांचे बिना सही होने के बारे में कुछ नहीं कहता.

पहली जांच दो तरह की गलती करती है. वह सामान्य मामले को चिह्नित कर बेवजह समीक्षा खर्च कर सकती है. इससे गंभीर यह कि वह रुकने योग्य मामला पार कर सकती है. कौन सी त्रुटि महंगी है, यह वर्कफ़्लो पर निर्भर है. वैकल्पिक लेबल का अभाव और मार्केटिंग ईमेल भेजने की अनुमति का अभाव एक जैसी सीमा पर नहीं रखे जाने चाहिए.

उचित आपत्ति है: “अगर मॉडल हर रिकॉर्ड समझ सकता है, तो कमज़ोर नियम पर भरोसा क्यों?” क्योंकि सामान्य रिकॉर्ड को बार-बार मॉडल से पूछने पर वह अपने आप ज़्यादा सही नहीं हो जाता. नियम की कमज़ोरी दिखती है: स्रोत या डेस्टिनेशन अनुबंध बदले तो उसकी धारणाएं पुरानी हो सकती हैं. इसलिए अनुबंध पर नज़र रखें और स्वीकार हुए मामलों का नमूना जांचें. यह हर स्थिर जांच को असीमित निर्णय से बदलने का कारण नहीं.

एस्केलेशन पूरी मानवीय समीक्षा से भी छोटा हो सकता है. ज्ञात विक्रेता त्रुटि के लिए दस्तावेज़ में दिया सुधार पर्याप्त हो सकता है. फ़ील्ड के बिल्कुल नए अर्थ पर एजेंट मैपिंग सुझा सकता है. सहमति की अस्पष्टता के लिए ज़िम्मेदार व्यक्ति चाहिए. पहली जांच हर मामले को उस सबसे सीमित अधिकार वाले व्यक्ति या तंत्र तक भेजे जो उसे तय कर सके.

कई बिज़नेस टूल को कैसे जोड़ें टूल चुनने से पहले सत्य के स्रोत और ट्रिगर चुनने की बात करता है. उन्हीं निर्णयों से पता चलता है कि किन अपवादों पर ध्यान देना है. ऐसे फ़ील्ड की बेमेल स्थिति जिसका उपयोग आगे कहीं नहीं होता, इंतज़ार कर सकती है. कैम्पेन ऑडियंस चुनने वाले फ़ील्ड की बेमेल स्थिति नहीं.

केवल बचत नहीं, छूटी त्रुटियों की दर मापें

चरणबद्ध सिस्टम आकर्षक ग्राफ़ बना सकता है: बहुत से मामले सस्ते में निपटे, कम आगे भेजे गए. यह ग्राफ़ अधूरा है. दूसरा माप जोड़ें: पहली जांच से पास हुए मामलों में से कितने बाद की डेस्टिनेशन जांच या स्वतंत्र नमूना समीक्षा में विफल निकले?

माप वास्तविक काम से बंधा होना चाहिए. संपर्क मिलान बनाए रखना काम है तो डेस्टिनेशन संपर्क स्थिति देखें. ऑडियंस बनाए रखना काम है तो किसे शामिल और किसे बाहर किया गया, देखें. हर त्रुटि की संख्या को उसके कुल मामलों और आगे के असर के बिना मनाना आसान और उस पर भरोसा करना मुश्किल है.

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

रिवर्स ETL गाइड ऐसे काम में बार-बार होने वाला डेटा स्थानांतरण समझाती है. छंटाई का सवाल उस पाइपलाइन के साथ खड़ा है: कौन सा अवलोकन बताएगा कि स्थिर नियम अब स्थिर नहीं रहा?

गहरी जांच वहां खर्च करें जहां व्यापक जांच जान नहीं सकती.