Validity | DQS Resources

Validity क्या है?

Validity मापती है कि डेटा मान अपेक्षित प्रारूपों और पैटर्न के अनुरूप हैं या नहीं। एक मान तब valid होता है जब वह परिभाषित संरचना से मेल खाता है। एक मान तब invalid होता है जब वह प्रारूप नियम तोड़ता है।

एक ईमेल पता तब valid होता है जब उसमें “@” चिह्न और एक domain हो। एक URL तब valid होता है जब वह एक प्रोटोकॉल से शुरू होता है और एक domain हो। एक product code तब valid होता है जब उसमें आपके system की आवश्यक exact character count हो।

DQS regex (regular expression) पैटर्न का उपयोग करके फ़ील्ड मानों को validate करता है। आप Email, URL, और Fixed Length जैसे सामान्य प्रारूपों के लिए built-in पैटर्न में से चुनते हैं, या किसी भी business-specific प्रारूप के लिए अपना regex लिखते हैं।

Validity Rate = (पैटर्न से मेल खाने वाले रिकॉर्ड / कुल रिकॉर्ड) x 100

यदि 50,000 Contact रिकॉर्ड में से 35,500 में email format पैटर्न से मेल खाने वाला email पता है, तो आपकी Email validity rate 71% है। शेष 29% में ऐसे मान हैं जो pattern check में विफल होते हैं।

Validity बनाम सटीकता

Validity और सटीकता अलग अवधारणाएँ हैं:

जाँच	Valid?	सटीक?
john@company.com	हाँ	सत्यापन के बिना अज्ञात
john@company	नहीं	N/A (प्रारूप गलत है)
john.doe@formerjob.com	हाँ	नहीं (व्यक्ति ने कंपनी छोड़ दी)
555-123-4567	हाँ	बिना कॉल किए अज्ञात
555-12-456	नहीं	N/A (गलत अंक संख्या)

DQS Validity मापता है क्योंकि प्रारूप जाँच को स्वचालित किया जा सकता है। सटीकता के लिए बाहरी सत्यापन या मानव पुष्टि की आवश्यकता होती है।

Valid डेटा आपके systems में काम करता है, भले ही यह वास्तविकता को प्रतिबिंबित न करे। Invalid डेटा आपके systems को तोड़ता है, इसकी real-world सच्चाई के बावजूद। पहले Validity पर ध्यान दें। सत्यापन प्रक्रियाओं के माध्यम से सटीकता को संबोधित करें।

Validity क्यों महत्वपूर्ण है

Invalid डेटा आपके पूरे stack में विफलताएँ पैदा करता है। Bounced email sender reputation को नुकसान पहुँचाते हैं। विकृत phone नंबर dialer समय बर्बाद करते हैं। टूटे URL उपयोगकर्ताओं को निराश करते हैं और enrichment tools को ब्लॉक करते हैं।

API विकृत डेटा को reject करते हैं। जब आपका integration एक marketing platform को invalid email प्रारूप भेजता है, तो पूरा batch विफल हो सकता है। Salesforce Flows जो फ़ील्ड मानों को parse करते हैं, प्रारूप अप्रत्याशित होने पर टूट जाते हैं।

AI मॉडल टेक्स्ट को यथावत process करते हैं। जब phone फ़ील्ड में एक स्वच्छ नंबर के बजाय “Phone: 555-1234” हो, तो मॉडल असंगत पैटर्न देखता है। Invalid प्रारूप AI effectiveness कम करते हैं और अविश्वसनीय Agentforce outputs उत्पन्न करते हैं।

System	Validity प्रभाव
Email campaigns	Bounces sender reputation को नुकसान पहुँचाते हैं
Telephony	Invalid नंबर dialer समय बर्बाद करते हैं
Web links	टूटे URL enrichment और navigation block करते हैं
APIs	Malformed डेटा sync विफलताओं का कारण बनता है
AI और Agentforce	असंगत प्रारूप model accuracy कम करते हैं

DQS Validity कैसे मापता है

DQS एक diagnostic प्रश्न के चारों ओर व्यवस्थित 6 Validity मेट्रिक्स उत्पन्न करता है: “क्या डेटा पैटर्न से मेल खाता है, और क्या pass होने वाले मानों में junk छुपा है?”

इन मेट्रिक्स को एक diagnostic flow के रूप में सोचें। प्रत्येक चरण समस्या की एक गहरी परत प्रकट करता है।

चरण 1: क्या यह पैटर्न से मेल खाता है?

Validity Rate मुख्य मेट्रिक है। यह उन रिकॉर्ड का प्रतिशत गणना करता है जहाँ फ़ील्ड मान आपके configured पैटर्न से मेल खाता है।

Valid Count आपको absolute संख्या बताता है। 50,000 Contacts में से, 35,800 में valid email पते हैं। यह email अभियानों के लिए आपकी वास्तविक addressable audience है, system में 50,000 नहीं।

चरण 2: पूरा Breakdown क्या है?

Rate गंभीरता बताती है। Count कार्यभार बताता है। दो मेट्रिक्स तस्वीर पूरी करते हैं:

मेट्रिक	यह क्या बताता है
Invalid Rate	आपके validity score का नकारात्मक framing। “हमारे 29% email पते structurally invalid हैं” board presentation में “71% valid हैं” से अधिक ध्यान आकर्षित करती है।
Invalid Count	एक hard संख्या के रूप में सफाई का कार्यभार। आपकी कंपनी E.164 format की आवश्यकता वाले नए telephony system में migrate हो रही है। Phone फ़ील्ड पर Invalid Count: 23,400। यही वह रिकॉर्ड की exact संख्या है जिन्हें migration से पहले reformat करने की जरूरत है।

मेट्रिक

यह क्या बताता है

Invalid Rate

आपके validity score का नकारात्मक framing। “हमारे 29% email पते structurally invalid हैं” board presentation में “71% valid हैं” से अधिक ध्यान आकर्षित करती है।

Invalid Count

एक hard संख्या के रूप में सफाई का कार्यभार। आपकी कंपनी E.164 format की आवश्यकता वाले नए telephony system में migrate हो रही है। Phone फ़ील्ड पर Invalid Count: 23,400। यही वह रिकॉर्ड की exact संख्या है जिन्हें migration से पहले reformat करने की जरूरत है।

चरण 3: प्रारूप त्रुटियों से परे Junk है?

एक मान format check pass कर सकता है और फिर भी garbage हो सकता है। Noise Rate उन मानों का प्रतिशत प्रकट करता है जिनमें noise patterns (junk data) हैं। Noisy Records Count cleanup scope देता है।

विफलता की दो श्रेणियाँ

Validity मेट्रिक्स दो मौलिक रूप से भिन्न समस्याओं को अलग करती हैं:

समस्या	मेट्रिक्स	मूल कारण	Fix
प्रारूप त्रुटियाँ	Validity Rate, Invalid Rate, Valid/Invalid Count	मानव गलतियाँ, integration bugs, गायब Validation Rule	डेटा साफ करें: field validation rules, data transformation, enrichment
Noise और junk	Noise Rate, Noisy Records Count	Bots, forced form submissions, garbage defaults के साथ bulk imports	स्रोत ठीक करें: CAPTCHA, required field redesign, record deletion

यह अंतर महत्वपूर्ण है क्योंकि fix पूरी तरह अलग है। प्रारूप त्रुटियाँ डेटा साफ करके remediate की जाती हैं। Noise उसे उत्पन्न करने वाले स्रोत को ठीक करके remediate किया जाता है।

मेट्रिक संदर्भ

Foundation Metrics

ये 2 मेट्रिक्स प्रत्येक Validity विश्लेषण का आधार बनाते हैं।

मेट्रिक	प्रकार	यह क्या मापता है
Validity Rate	प्रतिशत	configured पैटर्न से मेल खाने वाले रिकॉर्ड का हिस्सा
Valid Count	Count	configured पैटर्न से मेल खाने वाले रिकॉर्ड की संख्या

Advanced Metrics

ये 4 मेट्रिक्स “क्या यह मेल खाता है?” से परे जाकर noise detection सहित पूरा breakdown देते हैं।

मेट्रिक	प्रकार	यह क्या मापता है
Invalid Rate	प्रतिशत	configured पैटर्न में विफल रिकॉर्ड का हिस्सा
Invalid Count	Count	configured पैटर्न में विफल रिकॉर्ड की संख्या
Noise Rate	प्रतिशत	noise patterns (junk data) वाले रिकॉर्ड का हिस्सा
Noisy Records Count	Count	noise patterns वाले रिकॉर्ड की संख्या

Field Type कवरेज

सभी 6 Validity मेट्रिक्स एक ही base field type support साझा करते हैं, noise metrics text fields तक सीमित हैं।

मेट्रिक	सभी 6 Field प्रकार	केवल String और TextArea
Validity Rate	X
Valid Count	X
Invalid Rate	X
Invalid Count	X
Noise Rate		X
Noisy Records Count		X

Pattern-based metrics सभी 6 supported field types पर काम करते हैं: String, TextArea, Email, Phone, URL, और Picklist।

Noise metrics केवल String और TextArea fields पर लागू होते हैं।

दो Analysis Modes

DQS दो Validity analysis modes प्रदान करता है:

Format Validation प्रश्न का उत्तर देता है: “क्या field values अपेक्षित पैटर्न से मेल खाती हैं?” यह 2 foundation metrics उत्पन्न करता है।

Advanced Format Validation गहरा जाता है। यह सभी 6 मेट्रिक्स उत्पन्न करता है, जिसमें full valid/invalid breakdown और noise detection शामिल है।

व्यावसायिक आवश्यकता	अनुशंसित Mode
Quick format compliance check	Format Validation
Compliance reporting या audit	Advanced (regulators के लिए full valid/invalid breakdown)
Lead quality assessment	Advanced (Noise Rate उन junk को पकड़ता है जो format checks pass करते हैं)
Pre-migration data assessment	Advanced (category द्वारा remediation scope के लिए full breakdown)
Ongoing data governance	Format Validation से शुरू करें, noise detection के लिए Advanced में जाएँ

Validity कॉन्फ़िगर करना

Completeness (जो automatically किसी भी field पर काम करती है) के विपरीत, Validity के लिए configuration की आवश्यकता होती है। DQS 5 configuration inputs प्रदान करता है।

Setting	यह क्या नियंत्रित करता है
Pattern Type	Validate करने का प्रारूप। Email, URL, Fixed Length, या Custom regex में से चुनें। आवश्यक।
Pattern / Fixed Length	आपके chosen type के लिए specific value। Fixed Length के लिए, character count दर्ज करें।
Custom Pattern	जब Pattern Type Custom पर set हो तो आपका regex।
Include Blanks	सक्षम होने पर, DQS blank मानों को invalid गिनता है।
Case Sensitive	सक्षम होने पर, pattern matching letter casing को consider करती है।

Pattern Types

प्रकार	यह क्या Validate करता है	उदाहरण Pass	उदाहरण Fail
Email	Standard email address format: user@domain.tld	user@example.com	user@domain, invalid-email
URL	HTTP/HTTPS web addresses	https://example.com	example.com, htp://site.com
Fixed Length	Exact character count	`AAAAAAAAAA` (10 chars, length = 10)	`SHORT` (5 chars)
Custom	आपके द्वारा परिभाषित कोई भी regex	आपके पैटर्न पर निर्भर	आपके पैटर्न पर निर्भर

Noise Detection

Noise detection उस डेटा को पकड़ती है जो format checks pass करता है लेकिन फिर भी garbage है। DQS noisy मानों की पहचान के लिए दो built-in heuristics उपयोग करता है:

Heuristic 1: लगातार समान characters। एक पंक्ति में तीन या अधिक समान character। “aaaa”, “!!!”, “—”, या “xxxxx” जैसे मान इस जाँच को trigger करते हैं।

Heuristic 2: अत्यधिक special characters। 50% से अधिक non-alphanumeric characters। “!@#$%^” या “***///—” जैसे मान इस जाँच को trigger करते हैं।

सुझाव: Noise detection free-text fields पर सबसे मूल्यवान है जहाँ उपयोगकर्ता कुछ भी type कर सकते हैं: Company, Description, Notes, और custom text fields। पहले अपने web-to-lead fields पर इसे चलाएँ, जहाँ bot submissions और forced entries सबसे आम हैं।

सामान्य Validity समस्याएँ

Invalid Email Addresses

समस्या	उदाहरण
@ गायब है	john.company.com
Domain गायब है	john@
Double dots	john@company..com
Typos	john@comapny.com

प्रभाव: Bounced email, damaged sender score, खोई communication।

विकृत Phone Numbers

समस्या	उदाहरण
Letters mixed in	555-CALL-NOW
गलत digit count	555-12
Extension in field	555-1234 ext 5
Country code confusion	1-555-123-4567 बनाम 555-123-4567

प्रभाव: विफल calls, बर्बाद sales समय, telephony sync त्रुटियाँ।

Invalid URLs

समस्या	उदाहरण
Protocol गायब है	www.company.com
Domain गायब है	https://
Typos	htps://company.com
Social handles	@company (URL नहीं)

प्रभाव: टूटे links, विफल enrichment, navigation त्रुटियाँ।

Best Practices

Entry पर Validate करें

सबसे अच्छी Validity जाँच data entry पर होती है। डेटा आपके system में प्रवेश करने से पहले प्रारूप enforce करने के लिए Salesforce Validation Rule का उपयोग करें।

Scanning से पहले प्रारूपों को मानकीकृत करें

प्रत्येक फ़ील्ड के लिए एक प्रारूप चुनें और enforce करें। Phone numbers के लिए, E.164 (+15551234567) सबसे universally accepted standard है। URLs के लिए, https:// protocol की आवश्यकता करें।

Field Priority द्वारा Thresholds सेट करें

Field	सुझाया Threshold	तर्क
Primary Email	95%+	Communication के लिए महत्वपूर्ण
Phone	90%+	महत्वपूर्ण लेकिन legacy data अपेक्षित
Website	85%+	अक्सर अपूर्ण रूप से दर्ज
Custom text codes	98%+	System-generated, high compliance अपेक्षित

Free-Text Fields पर Noise Detection चलाएँ

Fields पर noise detection चलाएँ जहाँ उपयोगकर्ता free text type करते हैं: Company, Description, custom text fields, और web forms द्वारा populate की गई कोई भी field।

अगले कदम

अगला: Uniqueness - डुप्लिकेट रिकॉर्ड detect और prevent करें
पिछला: Completeness - सुनिश्चित करें कि आवश्यक डेटा मौजूद है
संबंधित: पाँच आयाम - सभी आयामों का अवलोकन
कार्रवाई: AI Readiness Assessment - अपने वर्तमान Validity scores देखें