חיזוי נטישה מבוסס בינה מלאכותית לאפליקציות מובייל

קל יותר למנוע נטישת משתמשים מאשר להחזיר אותם. הבעיה היא שעד שהמשתמש מפסיק להיכנס, כבר מאוחר מדי: הוא קיבל את ההחלטה לפני ימים. אנחנו עוזרים להטמיע חיזוי נטישה — מערכת שמזהה משתמשים על סף עזיבה 7–14 ימים לפני הנטישה בפועל, כשמנגנוני השימור עדיין עובדים. במשך יותר מ-5 שנים, סיפקנו יותר מ-50 פרויקטים באנליטיקה למובייל וב-ML. הניסיון שלנו מראה שזיהוי מוקדם של סיכון נטישה משפר את השימור ב-15–25% וחוסך עד 30% מתקציב השיווק לרכישת משתמשים חדשים, כלומר חיסכון של $25,000 בחודש לאפליקציה טיפוסית עם 100 אלף משתמשים פעילים חודשיים.

איך אנחנו חוזים נטישה ועל איזה נתונים

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

מאפיינים שעובדים בפועל:

• תדירות הפעלות ב-7/14/30 הימים האחרונים עם מגמה (עולה/יורדת)
• משך הפעלה ממוצע והדינמיקה שלו
• מספר פעולות מפתח שהושלמו (שלבי אונבורדינג שהושלמו, תשלום שבוצע)
• ימים מאז ההפעלה האחרונה — המאפיין החזק ביותר
• התקדמות בזרימה המרכזית: משתמש שלא הוסיף את רשומת היומן הראשונה שלו ינטוש בסבירות של 80%
• שיעור פתיחת הודעות push ב-14 הימים האחרונים
• גרסת האפליקציה והפלטפורמה (קריסות בגרסה מסוימת לפעמים גורמות לאנומליות נטישה חריגות)

אנחנו שולפים נתונים מאנליטיקת מובייל: Firebase Analytics, Amplitude, Mixpanel, או צינור אירועים מותאם אישית. המפתח הוא הגדרת אירועים נכונה בצד הלקוח לפני תחילת עבודת ML. בלי session_start, key_action_complete, payment_initiated, אין ממה לבנות את המודל.

למה Gradient Boosting מנצח רשתות נוירונים במשימה הזו

Gradient Boosting מבצע הכי טוב על נתונים טבלאיים עם מאפיינים "התנהגותיים". XGBoost או LightGBM הם הסטנדרט בתעשייה. רשתות נוירונים הן מיותרות כאן — כנראה שיש לך כמה עשרות מאפיינים, לא אלפים. XGBoost מדויק פי 2 מ-Logistic Regression ומדויק ב-10% יותר מרשתות נוירונים במשימה הזו.

דיוק טיפוסי על נתונים מוכנים היטב: precision 0.70–0.80, recall 0.65–0.75 בסף 0.5. חשוב: לבצע אופטימיזציה ל-recall, לא ל-precision — עדיף לשלוח הצעת שימור למשתמש שלא היה נוטש מאשר לפספס נוטש אמיתי. מחקרים מראים ש-XGBoost משיג עד 80% דיוק במשימות דומות.

האימון נעשה על נתונים היסטוריים עם תוויות: בזמן T, המשתמש היה בקבוצת סיכון, ואחרי 14 ימים הוא נטש בפועל (Y=1) או נשאר (Y=0). המחלקה לא מאוזנת: נוטשים הם בדרך כלל 10–25% מהבסיס. אנחנו מיישמים SMOTE או class_weight='balanced'.

באיזו תדירות צריך לאמן מחדש את המודל?

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

Precision, recall, F1-score, AUC-ROC — הסט הסטנדרטי להערכת איכות המודל. סף ההחלטה נבחר באופן אישי: העלאת recall מגדילה תוצאות חיוביות שגויות, ומעלה את עלויות קמפיין השימור. אנחנו ממליצים לקבוע את הסף אחרי מבחן A/B.

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

תוצאת החיזוי משמשת בצד הלקוח דרך Backend-Driven UI או קמפיינים של push:

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

אינטגרציה בצד המובייל: בתחילת הפעלה, האפליקציה מבקשת קונפיגורציה מהשרת (Firebase Remote Config או נקודת קצה מותאמת אישית), מקבלת retention_variant למשתמש הנוכחי, ומציגה את ה-UI המתאים.

מה כלול בתוצר הסופי?

• תיעוד על צינור המאפיינים והגדרת הנטישה
• מודל מאומן עם קוד וקונפיגורציות
• אינטגרציה של חישוב אצווה לשרת שלך
• הגדרת טריגרים לשימור (push, in-app, remote config)
• דשבורד לניטור precision/recall
• הדרכת צוות על עבודה עם המערכת

תשתית השרת

חישוב ציונים למשתמשים הוא תהליך אצווה, לא בזמן אמת. אנחנו מריצים אותו יומית: שולפים אירועים מצינור האנליטיקה (BigQuery, ClickHouse, או אחסון משלך), בונים וקטור מאפיינים לכל משתמש פעיל ב-30 הימים האחרונים, מריצים דרך המודל, וכותבים לטבלה user_churn_score(user_id, score, risk_segment, calculated_at).

השוואת אלגוריתמים לחיזוי נטישה

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

איך ליישם חיזוי נטישה: תוכנית שלב-אחר-שלב

1. ביקורת על האנליטיקה הנוכחית — בדוק אילו אירועים כבר נשלחים, האם קיימים session_start ופעולות מפתח.
2. הגדרת נטישה — קבע מה נחשב נטישה עבור המוצר שלך.
3. עיצוב צינור המאפיינים — צור צינור לחישוב מאפיינים יומי.
4. איסוף ותיוג נתונים היסטוריים — אסוף נתונים מ-6+ חודשים אחרונים, תייג נטישה.
5. אימון ואימות המודל — אמן XGBoost/LightGBM, כוונן את הסף.
6. אינטגרציה של חישוב ציונים לשרת — הפעל את תהליך האצווה.
7. הגדרת טריגרים לשימור — קשר בין חישוב ציונים ל-push, in-app, remote config.
8. מבחן A/B לפעולות שימור — ודא את יעילות המודל והמנגנון.
9. ניטור precision/recall בסביבת הייצור — אפשר אימון אוטומטי מחדש.

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

הערכות זמנים

מודל בסיסי עם חישוב אצווה והודעות push — 3–4 שבועות אם יש לך 6+ חודשים של נתונים היסטוריים. מערכת מלאה עם צינור מאפיינים, מבחן A/B, דשבורד ניטור ואימון אוטומטי מחדש — 8–12 שבועות. העלות מחושבת באופן אישי.

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