מערכת בינה מלאכותית להתאמה אישית של החוויה בהימורים מקוונים

מדוע ללא התאמה אישית ב-iGaming יורד שימור השחקנים

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

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

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

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

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

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

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

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

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

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

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

פורמטים של התאמה אישית ב-iGaming: השוואת גישות

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

מה לבחור לפי המשימה

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

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

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

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

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

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

מה מועבר לידיים: קונפיגורציות, תרשימים, תקנונים

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

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

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

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

נקודת התחלה

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

מה שינו

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

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

תוצאה

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

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

במה הגשת הצעות בזרימה נבדלת מסגמנטציה באצווה

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

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

קריטריוני הבחירה — בטבלה שלמטה; אין "או-או" נוקשה בין המצבים.

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

ספקות טכניים: עונים על שאלות נפוצות

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

איך התאמה אישית משתלבת במשחק אחראי?

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

אפשר להשיק פיילוט על חלק מהתנועה?

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

מה קורה אחרי מסירת המערכת?

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

נדבר על המשימה: נבנה תוכנית והערכה למוצר שלכם

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

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

מה מבררים בשיחה:

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

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

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