מערכת AI לאופטימיזציה של אונבורדינג למוצרי SaaS

אונבורדינג AI: היכן נשברת לוגיקת האקטיבציה

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

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

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

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

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

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

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

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

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

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

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

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

גישות לאונבורדינג AI והמגבלות שלהן

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

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

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

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

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

הכנת הנתונים

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

הרכבה ובדיקה

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

סכימות נתונים, מדיניות גישה ותקנונים

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

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

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

מקרה בוחן: המסלול עד לערך הראשון התקצר פי שלושה

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

מה הראה המשפך

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

מבחן השוואתי: מדדים לפני ואחרי

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

• גידול בשיעור המופעלים: מ-21 ל-38 אחוזים;
• זמן חציוני עד לערך הראשון: מ-12 ל-4 ימים;
• השלמת המינימום המחייב בסשן הראשון: מ-34 ל-62 אחוזים;
• פניות לתמיכה בנוגע לצעדים הראשונים: פחות בחצי.

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

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

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

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

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

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

שאלות נפוצות: נתונים, סימון ובקרת איכות

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

מה קורה עם הנתונים האישיים?

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

כיצד נבדקת איכות הסימון?

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

כיצד נשלטת תוצאת עבודת המערכת?

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

איך מתבצעת האינטגרציה וכמה זמן לוקח ההפעלה?

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

נדבר על המשימה: ממה מתחילה העבודה

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

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

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