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

מדוע ניתוח AI של מעורבות נכשל בפועל

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

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

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

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

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

מה משתנה במדדים: נטישה, פעילות, עומס

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

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

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

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

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

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

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

מצבי חישוב: מנות, זרימה, היברידי

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

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

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

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

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

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

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

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

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

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

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

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

מדיניות גישה, סכימות נתונים ונוהל אימון מחדש

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

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

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

מקרה בוחן: ירידה במעורבות זוהתה שלושה שבועות לפני הנטישה

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

מה שינינו

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

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

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

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

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

במה שונה חיזוי נטישה מהערכת פעילות נוכחית?

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

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

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

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

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

ספקות טכניים: סחיפת נתונים, התראות שווא

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

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

מאין נובעות התראות שווא וכיצד אתם מפחיתים אותן?

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

מה מציגה המערכת בהתנעה קרה?

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

עד כמה קריטיים אירועים חסרים?

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

נדון במשימה ונחזור עם הערכה, תוכנית ולוחות זמנים

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

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

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

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