פיתוח מערכת AI לחיזוי נטישת שחקנים

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

מדוע חיזוי נטישת שחקנים נשבר על נתונים חיים

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

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

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

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

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

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

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

מה נותנת מערכת מוקדמת לזיהוי נטישה: אפקטים מדידים

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

אזהרה מוקדמת במקום ניתוח בדיעבד

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

אפקט על השימור

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

אפקט על העומס בתמיכה

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

מדד אחד לכל הצוות

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

מצבי עבודה: חוקים, סטטיסטיקה, מודל על אירועים

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

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

מתי מספיקים כללי סף

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

מתי נדרש מודל על אירועים התנהגותיים

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

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

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

ביקורת נתונים והגדרת המדד

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

בדיקה על תקופות היסטוריות ומסירה

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

תוצרים: סכמות מאפיינים, תצורות ונוהלים

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

סכמת מאפיינים ותיוג

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

נוהלי ניטור איכות

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

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

מקרה בוחן: כיצד השתנו מדדי השימור לאחר ההטמעה

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

המצב ההתחלתי וההשערות

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

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

התוצאה בדינמיקת השימור

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

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

במה שונה ניקוד סיכון נטישה מפילוח התנהגותי?

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

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

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

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

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

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

מגבלות: תיוג, חוסר איזון בין מחלקות, סחיפת נתונים

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

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

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

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

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

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

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

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

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

נדון במשימה: נתונים, אופק, מדד איכות

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

  • הגדרת נטישה: כמה ימים בלי פעילות נחשבים לעזיבת שחקן והאם זה זהה לשחקן חדש ולשחקן משלם;
  • אופק החיזוי: 7, 14 או 30 ימים — ממנו תלויים גם מערך המאפיינים וגם סף ההפעלה העובד;
  • מדד איכות: מה חשוב יותר — לא להחמיץ עוזב או לא להטריד שחקן נאמן; מכאן הדיוק והכיסוי בסף הנבחר;
  • ייצוא אירועים: 2-3 חלונות תצפית, כדי לבדוק את יציבות המודל ולא להתאים אותו לקטע אחד;
  • הרכב השדות: סשנים, רכישות, התקדמות, ערוצי רכישה, פניות לתמיכה;
  • ערוץ הפעולה: דואר, הצעה בתוך המשחק או טיפול ידני — לפיו נבחרים הספים ותדירות ההפעלות;
  • מגבלות: אנונימיזציה, תקופות שמירה, השהיה בין האירוע לבין הגעתו למאגר.

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