ניקוי כפילויות לפני Salesforce: אסטרטגיית Deduplication מעשית

התשובה הקצרה

Deduplication נכשל כשמתייחסים אליו כפעולת ניקיון חד-פעמית. הוא בעצם שלוש החלטות: מה מגדיר זהות, מי מנצח כשיש סתירה, ואיך מונעים שהבעיה תחזור. הכלי הטכני הוא החלק הקל.

הטעות הנפוצה היא להריץ Fuzzy Matching על שמות, לקבל רשימה של 12 אלף התאמות אפשריות, ולנסות להכריע אותן ידנית תחת לחץ לוח זמנים. מה שעובד הוא ההפך: מצמצמים תחילה את מרחב ההחלטה באמצעות מפתחות חזקים, ומשאירים לסקירה אנושית רק את אזור האפור.

תכנון ההסבה הרחב מתואר במיגרציית נתונים ל-Salesforce.

שלוש שכבות של Matching

היחס שמאפיין פרויקט מנוהל: כ-70% מהכפילויות נסגרות בשכבה הראשונה, כ-20% בשנייה, וכ-10% מגיעות לאדם. אם רוב ההתאמות מגיעות לשכבה השלישית, זה סימן שלא הושקעה עבודה בנירמול - ולא שהנתונים גרועים במיוחד.

נירמול לפני השוואה

לפני כל השוואה מייצרים עמודות עזר מנורמלות ולא נוגעים בנתון המקורי: הסרת סיומות תאגיד (בע"מ, Ltd), אחידות רווחים וגרשיים, טלפון לפורמט E.164, אימייל ל-lowercase עם הסרת תוויות אחרי הפלוס, וכתובת מפוצלת לרחוב/מספר/עיר. בעברית מוסיפים טיפול בכתיב מלא וחסר ובראשי תיבות.

הנירמול לבדו מוריד בדרך כלל שליש עד מחצית מהכפילויות ה"קשות" עוד לפני שהפעילו אלגוריתם דמיון.

Golden Record ברמת השדה

ההחלטה "איזו רשומה שורדת" היא לא ההחלטה החשובה. החשובה היא "איזה ערך שורד בכל שדה". קובעים מדיניות קצרה: פרטי חיוב מה-ERP, פרטי קשר מהמערכת שבה נרשמה פעילות אחרונה, סטטוס לקוח מהמערכת התפעולית. לכל שדה מקור מועדף אחד, ולערך שנדחה נשמר תיעוד.

בלי מדיניות כזו, כל מיזוג הוא החלטה של מי שביצע אותו באותו רגע - ואי אפשר להסביר אחר כך למה נעלמה כתובת.

מה קורה לקשרים ולהיסטוריה

מיזוג רשומות משפיע על פעילויות, הזדמנויות, Cases, קבצים והרשאות. לפני הרצה המונית מגדירים במפורש: לאן עוברות הפעילויות, מה קורה להזדמנויות פתוחות מול אותו לקוח משתי רשומות, ומי הבעלים אחרי המיזוג - כי שינוי Owner משנה גם נראות וגם דוחות עמלות.

הכלל המעשי: אין מיזוג לפני שקיים דוח "מה השתנה" שניתן לשחזור, ומזהי המקור נשמרים בשדה נפרד כדי לאפשר חקירה חודשים אחר כך.

תרחיש: יבואן עם 210 אלף אנשי קשר

יבואן B2B ניגש להסבה עם 210 אלף Contacts משלוש מערכות. ההרצה הראשונה של כלי דמיון החזירה 31 אלף זוגות חשודים - מספר שאיש לא יכול לסקור.

הצוות עצר והפך את הסדר. תחילה נורמלו אימייל וטלפון: 14 אלף זוגות נסגרו אוטומטית על מפתח חזק. אחר כך נקבע שהיחידה העסקית היא אתר לקוח ולא תאגיד, מה שהוציא מהרשימה 6 אלף זוגות שהיו לגיטימיים - סניפים נפרדים של אותה רשת. נותרו 4,200 זוגות לשכבת הביניים, מהם 3,800 נסגרו בציון גבוה. לסקירה אנושית הגיעו 400 זוגות, ושני אנשים סגרו אותם בשלושה ימים.

הלקח לא היה בבחירת הכלי. הוא היה בכך שהגדרת היחידה העסקית - אתר מול תאגיד - הורידה יותר רעש מכל שיפור אלגוריתמי.

מניעה: למה הכפילויות חוזרות

שלושה מקורות עיקריים מחזירים כפילויות אחרי Go Live: הזנה ידנית ללא Matching Rules פעילים, אינטגרציות שיוצרות רשומה במקום לעדכן (Upsert על External ID פותר את רובן), וטפסי Web-to-Lead ללא בדיקת קיום. אם לא נסגרו שלושתם, שיעור הכפילות חוזר לרמתו המקורית תוך שנה עד שנתיים.

סיכונים נפוצים ופעולות מניעה

כיצד מודדים הצלחה

ליווי מקצועי בבניית כללי הזהות והמניעה ניתן במסגרת שירות אינטגרציות ודאטה.

Checklist לפני הרצת מיזוג

• ☐ הוגדרה היחידה העסקית: תאגיד, אתר או חוזה
• ☐ עמודות נירמול נבנו בלי לשנות את המקור
• ☐ שלוש שכבות Matching עם ספים מספריים כתובים
• ☐ מדיניות Golden Record ברמת שדה, מאושרת עסקית
• ☐ הוכרע מה קורה לפעילויות, הזדמנויות ובעלות
• ☐ מזהי מקור נשמרים לאחר המיזוג
• ☐ דוח "מה השתנה" ניתן להפקה ולשחזור
• ☐ הרצת ניסיון על מדגם עם בדיקה ידנית
• ☐ Matching Rules ו-Upsert פעילים למניעה
• ☐ בעלים קבוע לתהליך אחרי Go Live

מקורות מקצועיים

• Salesforce Data 360 — https://www.salesforce.com/data/
• Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
• HPI Pro – אינטגרציות ודאטה — https://hpi.pro/integrations-data