Czym jest poprawność?
Poprawność mierzy, czy wartości danych są zgodne z oczekiwanymi formatami i wzorcami. Wartość jest poprawna, gdy pasuje do zdefiniowanej struktury. Wartość jest niepoprawna, gdy łamie reguły formatu.
Adres e-mail jest poprawny, gdy zawiera symbol „@” i domenę. URL jest poprawny, gdy zaczyna się od protokołu i zawiera domenę. Kod produktu jest poprawny, gdy ma dokładną liczbę znaków wymaganą przez Twój system.
DQS waliduje wartości pól przy użyciu wzorców regex (wyrażeń regularnych). Możesz wybrać wbudowane wzorce dla typowych formatów takich jak Email, URL i Fixed Length, lub napisać własny regex dla dowolnego formatu biznesowego.
Stopień poprawności = (Rekordy pasujące do wzorca / Łączna liczba rekordów) x 100Jeśli 35 500 z 50 000 rekordów Contact ma adres e-mail pasujący do wzorca formatu, Twój stopień poprawności dla Email wynosi 71%. Pozostałe 29% zawiera wartości, które nie przeszły sprawdzenia wzorca.
Poprawność a dokładność
Poprawność i dokładność to różne pojęcia:
| Sprawdzenie | Poprawne? | Dokładne? |
|---|---|---|
| [email protected] | Tak | Nieznane bez weryfikacji |
| john@company | Nie | N/D (format jest zły) |
| [email protected] | Tak | Nie (osoba odeszła z firmy) |
| 555-123-4567 | Tak | Nieznane bez dzwonienia |
| 555-12-456 | Nie | N/D (zła liczba cyfr) |
DQS mierzy poprawność, ponieważ sprawdzenia formatu można zautomatyzować. Dokładność wymaga weryfikacji zewnętrznej lub ludzkiego potwierdzenia.
Poprawne dane działają w Twoich systemach, nawet jeśli nie odzwierciedlają rzeczywistości. Niepoprawne dane psują Twoje systemy, niezależnie od ich realnej prawdziwości. Skoncentruj się najpierw na poprawności. Zajmij się dokładnością przez procesy weryfikacji.
Dlaczego poprawność ma znaczenie
Niepoprawne dane powodują awarie w całym Twoim stacku. Odbite e-maile szkodzą reputacji nadawcy. Zniekształcone numery telefonów marnują czas dialerów. Uszkodzone URL frustrują użytkowników i blokują narzędzia wzbogacania.
API odrzucają zniekształcone dane. Gdy Twoja integracja wysyła niepoprawny format e-mail do platformy marketingowej, cała paczka może zawieść. Flows w Salesforce, które parsują wartości pól, psują się, gdy format jest nieoczekiwany.
Modele AI przetwarzają tekst dosłownie. Gdy pole telefonu zawiera „Phone: 555-1234” zamiast czystego numeru, model widzi niespójne wzorce. Niepoprawne formaty zmniejszają efektywność AI i produkują nierzetelne wyniki Agentforce.
| System | Wpływ poprawności |
|---|---|
| Kampanie e-mail | Odbicia szkodzą reputacji nadawcy |
| Telefonia | Niepoprawne numery marnują czas dialerów |
| Linki web | Uszkodzone URL blokują wzbogacanie i nawigację |
| API | Zniekształcone dane powodują awarie synchronizacji |
| AI i Agentforce | Niespójne formaty zmniejszają dokładność modelu |
Jak DQS mierzy poprawność
DQS produkuje 6 metryk poprawności zorganizowanych wokół pytania diagnostycznego: „Czy dane pasują do wzorca i czy w wartościach, które przechodzą, nie ukrywa się śmieć?”
Pomyśl o tych metrykach jak o przepływie diagnostycznym. Każdy krok ujawnia głębszą warstwę problemu.
Krok 1: Czy pasuje do wzorca?
Validity Rate to metryka nagłówkowa. Oblicza procent rekordów, w których wartość pola pasuje do Twojego skonfigurowanego wzorca. To liczba, którą umieszcza się na dashboardzie.
Konfigurujesz wzorzec Email na polu PersonEmail dla Contacts. Validity Rate wraca 71%. Oznacza to, że 29% adresów e-mail nie przechodzi sprawdzenia formatu. Brakuje im symbolu „@”, nie mają domeny lub zawierają spacje. Każda kampania marketingowa wysłana na te adresy odbija się. Każdy zautomatyzowany flow uruchamiany na e-mail cicho zawodzi.
Valid Count podaje liczbę bezwzględną. Z 50 000 Contacts, 35 800 ma poprawne adresy e-mail. To Twoja rzeczywista adresowana publiczność dla kampanii e-mail, a nie 50 000 w systemie. Marketing może ustalać realistyczne projekcje kampanii zamiast pracować z zawyżonymi liczbami.
Krok 2: Jaki jest pełny podział?
Stopnie mówią o dotkliwości. Liczby mówią o nakładzie pracy. Dwie metryki dopełniają obraz:
| Metryka | Co Ci mówi |
|---|---|
| Invalid Rate | Negatywne ujęcie Twojego wyniku poprawności. „29% naszych adresów e-mail jest strukturalnie niepoprawne” przyciąga więcej uwagi na prezentacji zarządu niż „71% jest poprawne”. Te same dane, ramowane do działania. |
| Invalid Count | Obciążenie czyszczenia jako twarda liczba. Twoja firma migruje do nowego systemu telefonii wymagającego formatu E.164. Invalid Count na polu Phone: 23 400. To dokładna liczba rekordów, które trzeba przeformatować przed uruchomieniem migracji. |
Krok 3: Czy jest śmieć poza błędami formatu?
Wartość może przejść sprawdzenie formatu i nadal być śmieciem. Twój formularz web-to-lead wymaga pola Company. Validity Rate na Company wynosi 98%, ponieważ prawie wszystko przechodzi podstawowy wzorzec tekstowy. Ale Noise Rate ujawnia, że 14% tych wartości to wpisy takie jak „asdf”, „test”, „xxxxx” lub „na na na”. Poprawne pod względem formatu, ale całkowicie bezużyteczne do routingu sprzedaży, wzbogacania czy segmentacji.
Noisy Records Count daje Ci zakres czyszczenia. Jeśli Noise Rate wynosi 14% na 50 000 rekordach, to 7000 Leads z śmieciowymi nazwami firm. Twój zespół ops może zbudować kolejkę czyszczenia, oszacować godziny i zdecydować, czy automatycznie usunąć, czy oznaczyć do ręcznego przeglądu.
Dwie kategorie awarii
Metryki poprawności rozróżniają dwa fundamentalnie różne problemy:
| Problem | Metryki | Przyczyna źródłowa | Rozwiązanie |
|---|---|---|---|
| Błędy formatu | Validity Rate, Invalid Rate, Valid/Invalid Count | Ludzkie błędy, bugi integracji, brakujące reguły walidacji | Wyczyść dane: reguły walidacji pól, transformacja danych, wzbogacanie |
| Szum i śmieć | Noise Rate, Noisy Records Count | Boty, wymuszone przesłania formularzy, masowe importy z śmieciowymi wartościami domyślnymi | Napraw źródło: CAPTCHA, przeprojektowanie pól wymaganych, usuwanie rekordów |
Rozróżnienie ma znaczenie, ponieważ rozwiązanie jest zupełnie inne. Błędy formatu są naprawiane przez czyszczenie danych. Szum jest naprawiany przez naprawę źródła, które go produkuje.
Referencja metryk
Metryki podstawowe
Te 2 metryki tworzą bazę każdej analizy poprawności. Mówią Ci o stopniu dopasowania i liczbie rekordów, które przechodzą.
| Metryka | Typ | Co mierzy |
|---|---|---|
| Validity Rate | Procent | Udział rekordów pasujących do skonfigurowanego wzorca |
| Valid Count | Liczba | Liczba rekordów pasujących do skonfigurowanego wzorca |
Metryki zaawansowane
Te 4 metryki wykraczają poza „czy pasuje?”, aby dać pełny podział, w tym wykrywanie szumu. Wymagają trybu analizy Advanced Format Validation.
| Metryka | Typ | Co mierzy |
|---|---|---|
| Invalid Rate | Procent | Udział rekordów niepasujących do skonfigurowanego wzorca |
| Invalid Count | Liczba | Liczba rekordów niepasujących do skonfigurowanego wzorca |
| Noise Rate | Procent | Udział rekordów zawierających wzorce szumu (śmieci) |
| Noisy Records Count | Liczba | Liczba rekordów zawierających wzorce szumu |
Dlaczego stopnie i liczby występują w parach
Większość metryk występuje jako stopień (procent) i liczba (wartość bezwzględna). Jest to celowe:
- Stopnie są dla dashboardów, raportowania dla zarządu i śledzenia trendów. „Poprawność poprawiła się z 71% do 92% w tym kwartale.”
- Liczby są do planowania projektów, szacowania obciążenia i określania zakresu czyszczenia. „Mamy 23 400 numerów telefonów do przeformatowania.”
Używaj stopni do komunikowania postępu. Używaj liczb do planowania pracy.
Pokrycie typów pól
Wszystkie 6 metryk poprawności ma takie samo bazowe wsparcie typów pól, z metrykami szumu ograniczonymi do pól tekstowych.
| Metryka | Wszystkie 6 typów pól | Tylko String i TextArea |
|---|---|---|
| Validity Rate | X | |
| Valid Count | X | |
| Invalid Rate | X | |
| Invalid Count | X | |
| Noise Rate | X | |
| Noisy Records Count | X |
Metryki oparte na wzorcu (Validity Rate, Valid Count, Invalid Rate, Invalid Count) działają na wszystkich 6 obsługiwanych typach pól: String, TextArea, Email, Phone, URL i Picklist.
Metryki szumu (Noise Rate, Noisy Records Count) mają zastosowanie tylko do pól String i TextArea. Wzorce szumu, takie jak powtarzane znaki i walenie w klawiaturę, to zjawiska tekstu dowolnego. Pole Picklist z poprawną wartością picklisty nie może zawierać szumu. Wykrywanie szumu ma sens tylko na polach, gdzie użytkownicy piszą tekst dowolny.
Dwa tryby analizy
DQS oferuje dwa tryby analizy poprawności:
Format Validation odpowiada na pytanie: „Czy wartości pól pasują do oczekiwanego wzorca?” Produkuje 2 metryki podstawowe i pokrywa podstawy dla sprawdzenia zgodności formatu lub szybkiego audytu.
Advanced Format Validation idzie głębiej. Produkuje wszystkie 6 metryk, w tym pełny podział valid/invalid i wykrywanie szumu. Używaj tego trybu, gdy musisz odróżnić błędy formatu od danych śmieciowych lub gdy potrzebujesz precyzyjnych liczb do planowania projektów czyszczenia.
| Potrzeba biznesowa | Rekomendowany tryb |
|---|---|
| Szybkie sprawdzenie zgodności formatu | Format Validation |
| Raportowanie zgodności lub audyt | Advanced (pełny podział valid/invalid dla regulatorów) |
| Ocena jakości Leads | Advanced (Noise Rate wychwytuje śmieć, który przechodzi sprawdzenia formatu) |
| Ocena danych przed migracją | Advanced (pełny podział do określenia zakresu naprawy według kategorii) |
| Bieżące zarządzanie danymi | Zacznij od Format Validation, przejdź do Advanced dla wykrywania szumu |
Konfigurowanie poprawności
W przeciwieństwie do kompletności (która działa automatycznie na dowolnym polu) poprawność wymaga konfiguracji. Musisz zdefiniować, co oznacza „poprawne” dla każdego pola, zanim DQS będzie mogło to sprawdzić. Skanowanie poprawności bez wzorca jest bezsensowne: poprawne w porównaniu do czego?
DQS udostępnia 5 wejść konfiguracyjnych. Każde można ustawić na poziomie globalnym (dotyczy wszystkich pól) i nadpisać na poziomie pojedynczego pola.
| Ustawienie | Co kontroluje |
|---|---|
| Pattern Type | Format do walidacji. Wybierz z Email, URL, Fixed Length lub Custom regex. Wymagane: musisz wybrać typ wzorca przed uruchomieniem skanowania. |
| Pattern / Fixed Length | Konkretna wartość dla wybranego typu. Dla Fixed Length wprowadź liczbę znaków (1 do 255). Dla Custom wprowadź wzorzec regex. Email i URL używają wbudowanych wzorców. |
| Custom Pattern | Twój własny regex, gdy Pattern Type jest ustawione na Custom. DQS waliduje Twój regex przed zapisaniem i blokuje niepoprawne wyrażenia. |
| Include Blanks | Gdy włączone, DQS liczy puste wartości jako niepoprawne. Gdy wyłączone (domyślnie), puste wartości są całkowicie wykluczone z oceny. |
| Case Sensitive | Gdy włączone, dopasowanie wzorca uwzględnia wielkość liter. Gdy wyłączone (domyślnie), dopasowanie jest niewrażliwe na wielkość liter. |
Typy wzorców
| Typ | Co waliduje | Przykład poprawny | Przykład niepoprawny |
|---|---|---|---|
| Standardowy format adresu e-mail: [email protected] | [email protected] | user@domain, invalid-email | |
| URL | Adresy web HTTP/HTTPS z poprawną domeną | https://example.com | example.com, htp://site.com |
| Fixed Length | Dokładna liczba znaków (definiujesz liczbę) | AAAAAAAAAA (10 znaków, jeśli długość = 10) | SHORT (5 znaków) |
| Custom | Dowolny wzorzec regex, który zdefiniujesz | Zależy od wzorca | Zależy od wzorca |
Przykład: Twoje kody produktów mają format „DQS-” po którym następuje 6 cyfr. Ustaw Pattern Type na Custom i wprowadź regex ^DQS-\d{6}$. DQS oznaczy każdy kod produktu, który nie pasuje do tej struktury.
Wykrywanie szumu
Wykrywanie szumu wychwytuje dane, które przechodzą sprawdzenia formatu, ale nadal są śmieciem. DQS używa dwóch wbudowanych heurystyk do identyfikacji śmieciowych wartości:
Heurystyka 1: Kolejne identyczne znaki. Trzy lub więcej tych samych znaków z rzędu. Wartości takie jak „aaaa”, „!!!”, „---” czy „xxxxx” wyzwalają to sprawdzenie. Zazwyczaj pochodzą z trzymania klawisza, wypełniacza lub nadużywania wartości zastępczych.
Heurystyka 2: Nadmierne znaki specjalne. Ponad 50% znaków niealfanumerycznych (z wyłączeniem spacji). Wartości takie jak „!@#$%^” lub „***///---” wyzwalają to sprawdzenie. Wskazują na walenie w klawiaturę, wprowadzanie przez bota lub celowe wprowadzanie śmieci.
| Heurystyka | Co wychwytuje | Przykłady wartości śmieciowych | Przykłady wartości czystych |
|---|---|---|---|
| 3+ kolejne identyczne znaki | Wypełniacz, trzymanie klawisza | „aaaa”, „!!!”, „---”, „xxxxx” | „Premium”, „DOT AB3 2024” |
| Ponad 50% znaków specjalnych | Walenie w klawiaturę, wprowadzanie przez bota, śmieć | „!@#$%^”, „***test”, „//—//“ | „[email protected]”, „O’Brien Inc” |
Możesz też zdefiniować niestandardowe wzorce szumu używając regex dla śmieci specyficznych dla org, których wbudowane heurystyki nie obejmują.
Wskazówka: Wykrywanie szumu jest najbardziej wartościowe na polach tekstu dowolnego, gdzie użytkownicy mogą pisać cokolwiek: Company, Description, Notes i niestandardowe pola tekstowe. Uruchom je najpierw na polach web-to-lead, gdzie zgłoszenia botów i wymuszone wpisy są najczęstsze.
Typowe problemy z poprawnością
Niepoprawne adresy e-mail
Użytkownicy wprowadzają e-maile bez właściwego formatu. Brakujące symbole „@”, brakujące domeny, podwójne kropki i literówki to najczęstsze problemy.
| Problem | Przykład |
|---|---|
| Brak @ | john.company.com |
| Brak domeny | john@ |
| Podwójne kropki | [email protected] |
| Literówki | [email protected] |
Wpływ: Odbite e-maile, uszkodzony wynik nadawcy, utracona komunikacja.
Zniekształcone numery telefonów
Pola telefonu akceptują dowolny tekst w Salesforce, co prowadzi do niespójnych i niepoprawnych formatów.
| Problem | Przykład |
|---|---|
| Litery wmieszane | 555-CALL-NOW |
| Zła liczba cyfr | 555-12 |
| Numer wewnętrzny w polu | 555-1234 ext 5 |
| Mylenie kodu kraju | 1-555-123-4567 vs 555-123-4567 |
Wpływ: Nieudane połączenia, zmarnowany czas sprzedaży, błędy synchronizacji telefonii.
Niepoprawne URL
Pola adresów web często zawierają częściowe lub zniekształcone wartości.
| Problem | Przykład |
|---|---|
| Brak protokołu | www.company.com |
| Brak domeny | https:// |
| Literówki | htps://company.com |
| Uchwyty społecznościowe | @company (nie jest URL) |
Wpływ: Uszkodzone linki, nieudane wzbogacanie, błędy nawigacji.
Najlepsze praktyki
Waliduj przy wprowadzaniu
Najlepsze sprawdzenie poprawności odbywa się przy wprowadzaniu danych. Używaj reguł walidacji Salesforce, aby egzekwować formaty, zanim dane wejdą do Twojego systemu.
// Przykład: reguła walidacji formatu e-mail
NOT(ISBLANK(Email)) && NOT(REGEX(Email, "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$"))Standaryzuj formaty przed skanowaniem
Wybierz jeden format dla każdego pola i egzekwuj go. Dla numerów telefonów E.164 (+15551234567) to najbardziej uniwersalnie akceptowany standard. Dla URL wymagaj protokołu https://. Dokumentuj swoje decyzje formatu, aby zespół znał standard.
Ustawiaj progi według priorytetu pola
Różne pola potrzebują różnych standardów poprawności:
| Pole | Sugerowany próg | Uzasadnienie |
|---|---|---|
| Primary Email | 95%+ | Krytyczne dla komunikacji |
| Phone | 90%+ | Ważne, ale oczekiwane są stare dane |
| Website | 85%+ | Często wprowadzane niekompletnie |
| Niestandardowe kody tekstowe | 98%+ | Generowane przez system, oczekiwana wysoka zgodność |
Używaj wykrywania szumu na polach tekstu dowolnego
Uruchamiaj wykrywanie szumu na polach, gdzie użytkownicy piszą tekst dowolny: Company, Description, niestandardowe pola tekstowe i dowolne pole wypełniane przez formularze web. Noise Rate ujawnia problemy, których walidacja formatu nie łapie.
Dokumentuj oczekiwane formaty
Stwórz słownik danych, który określa oczekiwany format dla każdego pola, akceptowalne warianty oraz przykłady wartości poprawnych i niepoprawnych. Udostępnij go zespołowi i odwołuj się do niego podczas projektów czyszczenia danych.
Następne kroki
Teraz rozumiesz, jak walidować formaty danych i wykrywać śmieciowe wartości. Kontynuuj naukę o następnym wymiarze:
- Dalej: Unikalność - Wykrywaj i zapobiegaj zduplikowanym rekordom
- Poprzednio: Kompletność - Zapewnij obecność wymaganych danych
- Powiązane: Pięć wymiarów - Przegląd wszystkich wymiarów
- Działanie: Ocena gotowości na AI - Zobacz swoje aktualne wyniki poprawności