KPI הוא מדד שנבחר למעקב אחר מטרה. המספר אינו מאבחן סיבה ואינו מוכיח ערך עסקי או אבטחה.
כתיבת הסכם מדידה
תעדו מטרה, נוסחה, יחידה, מונה, מכנה, אוכלוסייה ותקופה. ציינו אחראי והחלטה מתוכננת. עלות לליד אינה עלות ללקוח חדש; יש לציין הוצאות והגדרת תוצאה.
בדיקת שינוי לפני פעולה
בדקו כיסוי, כפילויות, עיכוב זמינות ושינויי הגדרה. ממוצע שיעורים אינו בהכרח השיעור הכולל: השתמשו בספירות המתאימות. סף דורש בירור ולא מספק הסבר אוטומטי. כלי אינו מבטיח איכות איסוף.
| נושא | בדיקה לתיעוד |
|---|---|
| הגדרה | נוסחה, יחידה והיקף כתובים |
| איכות | כיסוי, כפילויות וזמינות נבדקו |
| החלטה | אחראי, פעולה ומגבלות ברורים |
מקורות ובדיקה
חבר כל KPI לחוזה ולהחלטה.
מדד שימושי מציין את הפעולה ששינוי צריך להצדיק. לפני קביעת יעד, יש לתעד נוסחה, אוכלוסייה, מקור ותנאים שהופכים את המספר ללא שלם. לוח מחוונים יכול לעקוב אחר הגדרתו בצורה נכונה אך להיכשל בשאלת העסק כאשר היחידה או ההיקף שונים.
- רשום מונה, מכנה והחרגות.
- בדוק מקרה ידוע מאירוע לתרשים.
- הצג עדכון אחרון ותקופות שעדיין לא הושלמו.
מקור ראשוני: Google SRE — Data Processing Pipelines. שיטה קשורה: קריאת המדריך המעשי.
תן ל-KPI את ההקשר שלו.
KPI באחוזים זקוק ליחידות, ספירות ותקופה. ערכים זהים יכולים אחרת לייצג נפחים ואי-ודאויות שונים מאוד.
- פרסם מונה ומכנה לצד השיעור.
- תיעוד איסוף חלקי ואוכלוסיות חסרות לפני פירוש.
מקור ראשוני: NIST/SEMATECH — Confidence intervals for proportions. שיטה קשורה: קריאת המדריך המעשי.
שלמות צירופי נתונים
צירוף טבלאות עשוי להכפיל שורות ולעוות סכומים.
- שורה בטבלת הזמנות מייצגת הזמנה; שורת פריטים מייצגת מוצר בהזמנה. בדקו מפתחות חוזרים וחסרים לפני הצירוף.
- קבצו פריטים לפי מזהה הזמנה. צירוף לתוצאה זו מונע חזרה על סכום ההזמנה לכל פריט. השוו לסכום בטבלת ההזמנות המקורית.
- LEFT JOIN משמר הזמנות ללא פריטים, אך תנאי WHERE בטבלה הימנית עלול להסיר אותן. התאמה חסרה אינה סכום אפס.
מקרה קבלה שניתן לשחזר
דוגמה בדיונית: הנתונים אינם מתארים לקוח או תוצאה שנצפתה.
הצגת נתוני המקרה
{
"orders": [
{
"id": 1,
"total": 100
},
{
"id": 2,
"total": 200
}
],
"line_order_ids": [
1,
1,
2
],
"sum_before": 300,
"sum_after_raw_join": 400
}החלטה צפויה
400 סופר הזמנה פעמיים. אגדו שורות לפי הזמנה כדי לשחזר סכום 300. בדקו גם שתי הזמנות פיקטיביות של 100 כל אחת: הסכום הוא 200. SUM(DISTINCT total) יחזיר 100 ויסיר ערך תקין. בדקו מזהים וקרדינליות של הצירוף במקום להסיר סכומים חוזרים.
שאילתות SQL שניתן לשחזר
דוגמה בדיונית: הזמנות של 100 ו־200 ושלושה פריטים להזמנות 1, 1 ו־2. השאילתות משתמשות רק ב־VALUES; הפעילו בסביבת בדיקה.
WITH orders(id, total) AS (VALUES (1, 100), (2, 200)),
lines(order_id) AS (VALUES (1), (1), (2))
SELECT COUNT(*) AS rows, SUM(o.total) AS total
FROM orders o JOIN lines l ON l.order_id = o.id;WITH orders(id, total) AS (VALUES (1, 100), (2, 200)),
lines(order_id) AS (VALUES (1), (1), (2)),
per_order AS (
SELECT order_id, COUNT(*) AS line_count
FROM lines GROUP BY order_id
)
SELECT COUNT(*) AS orders, SUM(o.total) AS total
FROM orders o LEFT JOIN per_order l ON l.order_id = o.id;הצירוף הישיר יוצר שלוש שורות וסכום 400. צבירה מוקדמת מחזירה שתי הזמנות וסכום 300.
WITH orders(id, total) AS (VALUES (1, 100), (2, 100))
SELECT SUM(total) AS correct_total,
SUM(DISTINCT total) AS distinct_total
FROM orders;בסכומים 100 ו־100, התוצאה הנכונה היא 200; SUM(DISTINCT total) מחזיר 100.
נוהל בדיקה
- הגדירו רמת פירוט הזמנות ושורות.
- צרפו הזמנה בעלת שתי שורות.
- שמרו מפתחות, ספירות וסכומים מותאמים.
האם SUM(DISTINCT total) מספיק?
לא. שתי הזמנות של 100 מסתכמות ב־200, ואילו SUM(DISTINCT total) מחזיר 100. תקנו את הקשר בין המפתחות, לא את הסכומים.
מקור ראשוני: PostgreSQL — Table expressions and joins. שיטה קשורה: קריאת המדריך המעשי.