אנליטיקת CRM מבוססת AI ל-iGaming: סגמנטציה, חיזוי נטישה, בונוסים

AI CRM iGaming: איפה בדיוק הולכים לאיבוד השחקנים

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

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

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

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

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

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

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

הערכת סיכון נטישה לפי התנהגות משחק

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

דיוק הסגמנטים וכיסוי הקמפיינים

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

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

Segmentation ב-iGaming: מצב אצווה, זרימה או היברידי

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

חישוב מחדש של סגמנטים באצווה

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

הערכת אירועים בזרימה

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

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

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

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

אודיט מקורות ואיכות נתונים

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

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

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

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

מה מוסרים לידיים: סכמות חישוב, כללי סגמנטים, תקנונים

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

קונפיגורציית חישוב וכללי סגמנטים

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

תיעוד ותקנון ליווי

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

מקרה בוחן: איך צמצמנו נטישה בסגמנט הבונוסים

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

מה היה לפני ההטמעה

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

התוצאה במדדים

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

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

במה נבדלת תחזית נטישה מכללי סף?

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

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

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

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

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

ספקות לגבי נתונים, תיוג ועומס על המערכת הקיימת

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

יש לנו כמה בסיסי נתונים ו-CRM — האם יהיה צורך לאחד נתונים?

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

כללי הבונוסים משתנים כל שבוע — האם המודל יתיישן?

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

האם האנליטיקה לא תיצור עומס מיותר על המערכת?

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

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

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

מה נדרש מצדכם:

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

מה הצוות יחזיר בתגובה:

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

תארו את המשימה — נחזור עם הערכה ותוכנית.