מפה איננה החלטה

🌐 זמין גם ב-28 שפות

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

התמונה נוצרה בבינה מלאכותית

תורגם בבינה מלאכותית. הקהילה עוד לא בדקה את התרגום. לקריאה באנגלית

יחידה 4 מתוך 6 בפרק נתוני אב וזהות, הפרק השישי בקורס Data Architect. כל יחידה עומדת בפני עצמה. הקודם: התאמה, מיזוג וכללי שרידות · הבא: כשהסמכות משותפת

השאלה שהיחידה הזו עונה עליה: האם פרופיל מאוחד הוא אותו דבר כמו רשומת זהב?

אותו לקוח יושב בשלוש מערכות. Salesforce מכיר את Daniel Reyes, d.reyes@example.com, דאלאס. המסחר המקוון מכיר את Dan Reyes, אותו אימייל, דאלאס, טקסס. התמיכה מכירה את Daniel Reyes, 214-555-0100, דאלאס. Data 360 מחליט שכל השלושה הם אותו אדם ובונה פרופיל מאוחד. מצוין. יש לנו רשומת זהב? לא בהכרח. אנחנו יודעים שהרשומות שייכות יחד; לא החלטנו איזה מקור הוא הבעלים של האמת. זה יכול לבלבל אנשים: זיהוי ישויות יוצר אדם מאוחד (unified individual), אבל לא רשומת זהב. אז אני מלמד את ההבדל ישירות:

פרופיל מאוחד הוא מפה. רשומת זהב היא החלטה.

זיהוי ישויות עונה על “מי?”

בלי זיהוי ישויות, אדם אחד מופיע כפרופילים מנותקים: השיווק רואה אחד, המכירות אחר, השירות עוד אחד. Data 360 קולט אותם ומשתמש בכללי זיהוי ישויות כדי להחליט אילו שייכים יחד. ואז אפשר להגיד הרשומות האלה נראות כמו אותו אדם. זה פותר את הזהות. זה לא פותר את ניהול נתוני האב.

והפרופיל המאוחד שומר את המפה חזרה למקורות שלו. בתיאור של Salesforce עצמה, פרופיל מאוחד איננו רשומת זהב: הוא אוסף של מפתחות, עם אובייקטי קישור זהות (identity link) שקושרים את המזהה של כל רשומת מקור למזהה של הפרופיל המאוחד (Data 360 Architecture (opens in a new tab)). האדם המאוחד 10042 ממופה לאיש הקשר ב-Salesforce 003…, ללקוח המסחר המקוון EC-48372 וללקוח התמיכה SUP-9128. המקוריים לא נעלמים. זה קרוב מאוד לרישום של יחידה 2.

Click to enlarge

פרופיל מאוחד הוא מפה חזרה לזהויות המקור.

כללי התאמה: הקפדנות היא החלטת סיכון

איך Data 360 מחליט את מי לאחד? כללי התאמה (match rules). פרופילים מותאמים כשכל הקריטריונים בכלל מתקיימים, ואם יש לכם כמה כללים, התאמה בכל אחד מהם יוצרת את הפרופיל המאוחד. ההנחיה של Salesforce עצמה: השתמשו ביותר קריטריונים לדיוק (יותר פרופילים נפרדים), פחות לאיחוד (Identity Resolution Match Rules (opens in a new tab)). אז הוספת קריטריונים לכלל הופכת אותו לקפדני יותר; הוספת כללים חלופיים מרחיבה את הדרכים שבהן פרופילים יכולים להיות מותאמים. הגדרת זיהוי ישויות היא לא “להדליק התאמה.” היא הגדרה של איזו ראיה מספיקה כדי להגיד שהפרופילים האלה הם אדם אחד.

יותר התאמה היא לא אוטומטית טובה יותר. עשרה מיליון פרופילי מקור הופכים לשמונה מיליון מאוחדים. תרפו את הכללים, ועכשיו שישה מיליון. יותר טוב? אולי מצאתם יותר כפילויות. ואולי התחלתם לשלב אנשים שונים. מספר קטן יותר איננו הוכחה לנתונים טובים יותר. המטרה היא לא הכי מעט פרופילים; היא הזהויות שהכי קל להגן עליהן בשביל המטרה. ולכל קריטריון יש שיטת התאמה (match method): Exact, Exact Normalized, או Fuzzy בדיוק גבוה, בינוני או נמוך. האזהרה של Salesforce עצמה היא העיקר: שיטה פחות מדויקת מעלה את שיעור האיחוד, “אבל יכולה להוביל להתאמות לא רצויות.” (Fuzzy לא זמין לשדות של Account, והערכים המנורמלים משמשים רק להשוואה; הם לא נשמרים בפרופיל המאוחד, וזה שלב ההאחדה של יחידה 3 בפעולה: Identity Resolution Match Methods (opens in a new tab).) ככל שהשיטה רופפת יותר, הזהות עצמה הופכת יותר לשיקול דעת. אם היא שגויה, האם רק נתאים אישית דף בצורה גרועה, או נראה לאדם אחד את היסטוריית התמיכה של אדם אחר, או ניתן לסוכן לפעול על נתונים של שני אנשים?

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

גם יישוב איננו ניהול נתוני אב

אחרי שהפרופילים מאוחדים, המקורות עדיין לא מסכימים: Salesforce אומר דאלאס, המסחר המקוון פלאנו, התמיכה דאלאס. מה הפרופיל המאוחד מציג? כללי יישוב (reconciliation rules) מחליטים: Last Updated, Most Frequent או Source Priority, שנקבעים לכל אובייקט ואפשר לעקוף אותם לכל שדה (Identity Resolution Reconciliation Rules (opens in a new tab)). זה אמור להישמע כמו כללי השרידות של יחידה 3.

כאן צוותים נכנסים לצרות. הפרופיל המאוחד מציג דאלאס, ומישהו אומר, “מעולה, דאלאס הוא ערך הזהב שלנו.” לאט. המסחר המקוון עדיין אומר פלאנו. Salesforce אומרת במפורש שיישוב לא מוחק או משנה נתוני מקור ולא מעדכן את מערכות המקור, והוא לא נועד לבחור ערך “הכי טוב” לכל אפליקציה. הוא מחליט רק מה הפרופיל המאוחד מציג (אותו מקור). תצוגה איננה סמכות.

ידע למבחן. הכירו איך זיהוי הישויות של Data 360 מחליט ומציג: בכלל התאמה, כל הקריטריונים חייבים להתאים, והתאמה של כלל אחד כלשהו מאחדת את הפרופילים (יותר קריטריונים לדיוק, פחות לאיחוד); שלושת כללי ההתאמה והיישוב הם Last Updated, Most Frequent ו-Source Priority, שנקבעים לכל אובייקט ואפשר לעקוף אותם לכל שדה; והיישוב לא משנה את נתוני המקור, ונקודות קשר (contact points) לא עוברות יישוב.

נקודות קשר מבהירות את העניין עוד יותר. לאדם יכולים להיות אימייל אישי ואימייל של העבודה, נייד וטלפון בבית, כולם לגיטימיים. Data 360 לא מיישב נקודות קשר בכלל: כל אימייל וכל טלפון נשארים על הפרופיל המאוחד (אותו מקור). לפעמים כמה ערכים הם פשוט האמת. “מאוחד” לא אומר ערך אחד לכל דבר.

רשומת זהב היא החלטה

השוו לדרישה אמיתית של ניהול נתוני אב. העסק אומר שה-ERP סמכותי לשם המשפטי, והערך המנוהל הוא “Oakline Logistics LLC.” Salesforce, החיוב והשירות חייבים כולם להשתמש בו, ואם אחד לא מסכים, תהליך ניהול נתוני האב דוחף את הערך המנוהל חזרה. זו ארכיטקטורה אחרת. אנחנו לא בוחרים מה תצוגה אחת מציגה; אנחנו מחליטים שזה הערך שהארגון משתמש בו, וכל מערכת שמשתתפת מתכנסת אליו.

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

Click to enlarge

פרופיל מאוחד הוא מפה. רשומת זהב היא החלטה.

יכולת התחקות

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

שלושה כלים לשלוש עבודות

ככה אני מפריד ביניהם:

1. ניהול כפילויות ומיזוג, בתוך org אחד של Salesforce, כשיש מנצח ברור ואתם כבר לא צריכים את הכפילויות (יחידה 3).
2. זיהוי ישויות ב-Data 360, לזהות אחת ולתמונה אחת על פני מקורות בלי לשנות אותם: רישום.
3. פלטפורמת MDM ייעודית, כשצריך להכריע בערכים פעם אחת ולדחוף אותם חזרה לכל מערכת שמשתתפת: דו-קיום או מרכזי.

Click to enlarge

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

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

זהות אחת איננה הרשאה אחת

זיהוי ישויות אומר שהרשומות האלה הן אדם אחד. זה לא אומר שכל מי שיכול לראות רשומת מקור אחת רשאי לראות את כל מה שמחובר לזהות המאוחדת. שותף קמעונאי רשאי לראות את המשלוחים ששלח; המשלוחים של שותף אחר לאותו נמען הם לא עניינו, גם אם שכבת הזהות יודעת שהם קשורים. גרף הזהויות יכול להיות נכון בזמן שתכנון הגישה שגוי. איחוד זהות לא מוחק גבולות אבטחה. בגלל זה התאמת יתר הופכת לבעיית פרטיות, ובגלל זה נקודת הביקורת של Steve Trucking מתייחסת לאיחוד נמענים בזהירות כזו: מפה של מי זה מי לא מעניקה בעלות, וגם לא גישה.

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

מה הארכיטקט מחליט כאן

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

Data 360 יכול להגיד לנו שהפרופילים האלה שייכים יחד, לתת לנו זהות מאוחדת, ליישב את מה שהוא מציג ולשמור את הקישורים חזרה לכל מקור. זה בעל ערך עצום. אבל אם Salesforce אומר דבר אחד וה-ERP דבר אחר, מישהו עדיין צריך להחליט איזו מערכת רשאית לשנות את האמת הארגונית. אז כשמישהו אומר “יש לנו פרופיל מאוחד, אז יש לנו את רשומת הזהב שלנו”, שאלו: איחדנו את הנתונים, או ניהלנו אותם כנתוני אב?

להרחבה

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).
• Salesforce Help, Data 360: Identity Resolution Match Rules (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) ו-Identity Resolution Reconciliation Rules (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).