ה־CRM היה מלא.
בלי תאים ריקים בולטים. בלי כשל קטסטרופלי בייבוא. לכל ליד היה ערך בשדה המדינה, וזה נשמע מרגיע — עד שמישהו ניסה לפלח ביצועים לפי אזור וגילה ערכים כמו Israel, IL, ישראל, N/A, EMEA, Europe, ושורה אחת בלתי נשכחת שבה פשוט היה כתוב home.
מבחינה טכנית, שום דבר לא היה חסר. האנליזה עדיין נראתה כמו זירת פשע.
זאת תקפות.
תקפות שואלת אם הדאטה מציית לכללים שהוא אמור לציית להם. לא אם קיים ערך. לא אם הוא נראה סביר במבט ראשון. אלא אם הוא עומד בכללי הפורמט, הסוג, הטווח וההיגיון העסקי שמאפשרים לסמוך על המשמעות שלו.
זה חשוב היום יותר, לא פחות, כי AI יכול לעזור לתקן דאטה פגום במהירות. אם העבודה הטכנית של הניקוי נעשית זולה יותר, החלק היקר הוא לזהות אילו כללים באמת חשובים, לפני שהמודל מתחיל ״לעזור״ לכם להפוך שטויות למשהו מסודר ואחיד.
תקין לא אומר נכון
כאן אנשים מתחילים לחפף.
כתובת אימייל תקינה יכולה להשתייך לאדם הלא נכון. תאריך תקין יכול להיות משויך לאירוע הלא נכון. קוד מדינה תקין עדיין יכול לייצג את השוק הלא נכון, כי הסיקו אותו בצורה שגויה במערכת המקור.
תקפות צרה יותר מאמת. היא שואלת: האם הערך הזה מציית למערכת הכללים שאנחנו טוענים שאנחנו עובדים לפיה?
זה נשמע מוגבל, אבל זה חיוני. בלי תקפות, האנליזה מתחילה להתפרק עוד לפני שאפשר בכלל לדבר על אמת. אי אפשר לחשוב בבהירות על שדה שמעולם לא הוגדר אילו ערכים מותר להכניס אליו.
כללי פורמט לעומת כללים עסקיים
חלק מבדיקות התקפות הן טכניות:
- האם השדה הוא תאריך?
- האם הערך מספרי?
- האם הקוד מתאים לתבנית הצפויה?
- האם הערך נמצא בטווח המותר?
אלה בדיקות שימושיות, אבל הן החלק הקל.
החלק הקשה יותר הוא תקפות עסקית:
- האם
Europeהוא ערך קביל בשדה של מדינה? - האם הנחה יכולה להיות גבוהה מסכום ההזמנה לפני ההנחה?
- האם למשתמש בתקופת ניסיון בחינם אמורה להיות הכנסה מוכרת?
- האם
999הוא גיל תקף, גם אם סוג העמודה מאפשר לשמור אותו?
זאת הסיבה ש״זה עבר ולידציה״ הוא לעיתים קרובות משפט מנחם חלש למדי. הרבה צינורות נתונים בודקים תחביר ומתעלמים ממשמעות. הם מוודאים שאפשר לשמור את הדאטה, ולא שאפשר לסמוך עליו.
למה age = 999 הוא לא מקרה קצה משעשע
ערכים גרועים הם לעיתים רחוקות אקראיים. הם סימנים.
999 בדרך כלל אומר שמישהו היה צריך ערך למילוי מקום. N/A בשדה עם ערכים מוגדרים אומר שתהליך קליטת הנתונים הסכים לחיות עם עמימות. unknown אומר לא פעם שמערכת המקור לא הצליחה לסווג משהו, אבל הסכמה בהמשך הדרך דרשה תשובה בכל זאת.
להתייחס אליהם כאל מקרי קצה לא מזיקים זאת עצלנות. הם מעוותים קיבוצים, מנפחים את מספר הקטגוריות ויוצרים יציבות מדומה, כי הזבל מגיע בפורמט שחוזר על עצמו.
דעה נחרצת אחת: אם צינור הנתונים שלכם מקבל ערכי מילוי בלי מדיניות מוגדרת, הוא לא מפגין גמישות. הוא מעביר את הבלבול לאחריותו של האנליסט שיקבל את הטבלה בהמשך.
רשימות ערכים מותרות משעממות — עד שהן מצילות את האנליזה
אף אחד לא רוצה לשבת בפגישה על קודי מדינה מותרים. בדיוק בגלל זה מזניחים את הבעיה עד שהפילוח נשבר.
רשימות ערכים מותרות מרגישות בירוקרטיות כשהכול רגוע. ואז החברה מנסה להשוות ביצועים של ערוצי שיווק בין שווקים, לחבר דאטה מה־CRM לאירועי מוצר או לבנות תחזית אזורית — ופתאום הרשימה המשעממת של הערכים הקבילים היא הדבר היחיד שמפריד בין סדר לבין סיפור שמתמוטט.
אותו הדבר נכון לקודי סטטוס, לשמות מסלולים, למטבעות, לסוגי מכשירים, לסיווגי קמפיינים ולסיבות להחזרים כספיים. אנליסטים מקבלים אותם לעיתים כאילו היו חוקי טבע. הם לא. אלה בחירות תכנוניות עם השלכות.
ההבדל בין לקבל דאטה לבין לסמוך עליו
מערכות רבות מתוכננות לקבל קלט לא מושלם, כי הפעילות העסקית צריכה להימשך. זה הגיוני.
אבל יש הבדל עצום בין לאפשר לדאטה להיכנס למערכת לבין לאשר שהוא מתאים לאנליזה.
התפעול אולי צריך לקלוט ליד עכשיו ולתקן את הפרטים אחר כך. האנליזה לא יכולה פשוט להעמיד פנים שבגלל זה השדה כבר מוכן לפילוח. קבלה היא החלטה של תהליך העבודה. אמון הוא החלטה אנליטית.
הבלבול בין השניים הוא מה שגורם לצוותים להציג גרפים מדויקים שמבוססים על ערכים שאף אחד לא הגדיר מספיק טוב כדי שאפשר יהיה להשוות ביניהם.
איך אנליסטים בדרך כלל מפספסים בעיות תקפות
הם מחפשים תאים ריקים וערכים חריגים, אבל לא הפרות של כללים.
הם שמים לב לערכי null. לפעמים הם אפילו שמים לב לערכים קיצוניים ומופרכים. מה שהם נוטים לדלג עליו הוא הגדרה מפורשת של הציפיות מכל שדה:
- אילו ערכים מותרים?
- באיזה פורמט?
- באילו תנאים?
- מי אחראי לכלל?
- מה קורה כשהכלל מופר?
בלי זה, איכות נתונים הופכת לעניין אסתטי. אנליסטים בודקים אם השדה ״נראה בסדר״, במקום לבדוק אם הוא מציית לסטנדרט מספיק חזק כדי לתמוך בהחלטה.
זה לא ממשל נתונים. זאת אנליזה לפי תחושת בטן.
מטריצת בדיקות מעשית
אם שדה חשוב להחלטות, תעדו את היגיון הבדיקה שלו במקום אחד.
| שדה | כלל | דוגמאות לערכים לא תקפים | אחראים | תגובה |
|---|---|---|---|---|
country | חייב להיות קוד מדינה בפורמט ISO-2 | Europe, N/A, ישראל | תפעול CRM | דחייה בקליטה או מיפוי דרך טבלה מאושרת |
discount_pct | חייב להיות בין 0 ל־100 | 150, -10 | צוות הפיתוח של המסחר | בידוד השורה ושליחת התראה |
signup_date | לא יכול להיות תאריך עתידי | 2030-01-01 | הנדסת נתונים | חסימת הטעינה למערכות ההמשך |
plan_name | חייב להתאים לקטלוג המאושר | enterprise-ish | תפעול מוצר | מיפוי מחדש או העברה לטיפול האחראים |
המטרה היא לא ניירת. המטרה היא להפוך את האמון למפורש.
ברגע שכל ערך נראה קביל, מופיעה תקלה מסוג אחר: ייתכן שאתם עדיין סופרים את אותו הדבר כמה פעמים. זאת בעיית הייחודיות.
