פיתוח סגמנטציית AI של לקוחות: קיבוץ לאשכולות + תיאור באמצעות LLM

מדוע סגמנטציית AI של לקוחות נתקעת בכללים ידניים

כיום הסגמנט נאסף לרוב ידנית: אנליסט כותב תנאי מיון ב-SQL או בבונה דוחות, מייצא את המאגר מ-CRM, מחיוב וממערכת תמיכה ומאחד הכול לטבלה אחת.

הכללים סטטיים — «קנה ב-90 הימים האחרונים», «סכום קנייה ממוצע מעל הסף» — והייצואים המפוזרים מהמערכות מתאחדים רק לאחר התאמה לפי מפתח וטיפול ידני בפערים.

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

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

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

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

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

סגמנטציה לפי התנהגות: מה יוצא מהעבודה הידנית

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

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

המאפיינים מחושבים בחלונות נעים של 7, 30 ו-90 יום ומנורמלים — הפרופיל אינו תלוי בגודל הלקוח, ומתעדכן באופן אינקרמנטלי, בלי חישוב מלא מחדש.

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

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

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

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

השוואת גישות: כללים, קיבוץ לאשכולות, היברידי

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

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

שלבי הטמעה: מביקורת נתונים ועד מסירה

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

1. ביקורת נתונים לסגמנטציה. מפרקים עסקאות, פניות, פעילות במוצר, רשומות של מערכת רישום. בודקים את עומק ההיסטוריה, שלמות השדות והמפתח שלפיו רשומות מתאחדות ללקוח אחד. בפלט — מפת מקורות עם מגבלות מפורשות.

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

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

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

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

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

מה מועבר ללקוח: ארטיפקטים ונוהלים

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

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

מקרה בוחן: איך צמצמנו תיוג ידני של המאגר

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

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

מדדים לפני ואחרי

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

בנוסף הוספנו תיאור פרופיל בשפה אנושית: מודל שפה קורא את מאפייני האשכול ומנסח מי נכנס אליו — המשווק רואה «קונים מוצר אחד בחודש ומגיבים להנחה», ולא מספר אשכול. התיוג הידני הצטמצם בערך פי עשרים, ואת הקבוצות אפשר לעדכן אפילו מדי יום.

במה קיבוץ לאשכולות שונה מכללים לפי מאפיינים?

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

הנקודה החלשה — הספים נקבעים ידנית, ועם עשרות מאפיינים האדם מפסיק לראות אילו צירופים באמת מבדילים את הקהל.

קיבוץ לאשכולות יוצא מהנתונים: האלגוריתם מוצא בעצמו קבוצות במרחב רב-ממדי — לפי תדירות ועדכניות רכישות, הרכב הסל, תגובה לתקשורת. k-means וגרסאות עמידות לחריגים נותנים חלוקה שאיש לא הגדיר: הסגמנטים נבנים מהתנהגות בפועל, ולא מציפיות הצוות.

בחירת שיטת הסגמנטציה נקבעת לפי מבנה הנתונים — קבוצות צפופות וקומפקטיות, דלילות או מקוננות דורשות גישות שונות.

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

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

שאלות טכניות נפוצות על נתונים ופרטיות

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

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

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

כיצד מבצעים אנונימיזציה של נתוני לקוחות?

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

איך אתם בודקים את איכות הסגמנטים?

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

למי שייכים המודל והנתונים?

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

מה לשלוח להערכה וממה נתחיל

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

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