פיתוח מערכת Next Best Action: איך להגדיל ROAS פי 4–8

למה המלצות לא עובדות: היכן נשבר Next Best Action

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

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

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

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

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

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

השפעת ההטמעה: עלייה ב-ROAS, בדיוק ובשימור

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

דיוק הפגיעה בפעולה היעד

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

מהירות התגובה לביקוש

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

נטישה ורכישות חוזרות

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

עומס על האנליסטים

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

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: עלייה ב-ROAS וברכישות חוזרות לאחר מעבר להמלצות אישיות

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

בקלט תועדו מדדי בסיס: המרה לפעולה יעד — 1.9%, שיעור ההמלצות שנכנסו לטופ-3 — 14%, נטישה — 4.2% מהבסיס הפעיל בחודש, ומחזור הכנת קמפיין — שבועיים.

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

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

כיצד חישבו את האפקט

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

ההמרה לפעולה יעד עלתה ל-4.4%, שיעור הפגיעות בטופ-3 — ל-58%, הנטישה הצטמצמה בכשליש בערך. הכנת קמפיין אורכת 40 דקות במקום שבועיים, ההמלצות מחושבות מחדש פעם ביום לפי אירועים טריים. ROAS בתקופה ברת-השוואה עלה פי 4–8 בהתאם לקטגוריה.

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

במה Next Best Action שונה מכללים וסגמנטים ידניים?

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

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

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

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

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

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

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

מה עושים עם אירועים נדירים?

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

מה לעשות עם נתונים חסרים?

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

האם המודל לא יטשטש את המגבלות של כללי העסק?

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

מה יקרה במקרה של תקלה במקור נתונים?

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

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

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

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

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

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