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? | सटीक? |
|---|---|---|
| [email protected] | हाँ | सत्यापन के बिना अज्ञात |
| john@company | नहीं | N/A (प्रारूप गलत है) |
| [email protected] | हाँ | नहीं (व्यक्ति ने कंपनी छोड़ दी) |
| 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 करने की जरूरत है। |
चरण 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 |
|---|---|---|---|
| Standard email address format: [email protected] | [email protected] | 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 | [email protected] |
| Typos | [email protected] |
प्रभाव: 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 देखें