פיתוח מודל ML לחיזוי המרה (Conversion Prediction)

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

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

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

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

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

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

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

מה נותן מודל חיזוי המרה ואיך בונים אותו

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

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

את איכות המודל מחשבים לא לפי ספרה אחת. בוחנים ROC-AUC ו-PR-AUC על מדגם מופרש, כיול הסתברויות (עד כמה ה-20% החזויים תואמים את השיעור בפועל), ו-lift בעשירונים העליונים — именно הוא קובע כמה פניות יוצאות לשווא.

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

במה בונים

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

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

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

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

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

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

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

במה שונה חיזוי המרה מתחזית הכנסות?

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

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

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

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

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

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

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

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

מקרה בוחן: כיצד מודל חיזוי המרה שינה את המשפך

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

מה שינו

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

מדדים לפני ואחרי

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

מה זה נתן למשפך

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

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

ספקות לפני הטמעה: תאימות, מיגרציה, נסיגה

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

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

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

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

לאחר המסירה תקבלו לידיכם:

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

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

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

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

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

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

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

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