מדוע המלצות מוצרים ב-Bitrix אינן עובדות על היסטוריית הזמנות
תמונה אופיינית: בכרטיס המוצר הבלוק "עם זה קונים" או ריק, או מציג את מה שהלקוח כבר קנה לפני חודש. הסיבה אינה בקידוד, אלא בכך שמודול ההמלצות שואב נתונים מיומן הצפיות ומהסל, ולא מהיסטוריית הרכישות ב-1С.
העסקאות נמצאות במערכת החשבונאית, סטטוסי ההזמנות נסגרים שם — וכל עוד קו מתאר זה אינו מקושר לחנות, האלגוריתם פיזית אינו יודע מה האדם כבר רכש.
הפער השני — מלאי. המלצות מותאמות אישית של חנות מקוונת נבנות על מטריצת רכישות משותפות, אך ללא יתרות לפי מחסנים ואזורי משלוח. כתוצאה מכך הבלוק מציע מוצרים נלווים שאינם נמצאים במחסן הקרוב: הלקוח מוסיף לסל, ובשלב התשלום מקבל סירוב או זמן אספקה של שלושה שבועות. ההמרה של הבלוק יורדת, אף שהבחירה עצמה פורמלית "עבדה".
הכשל השלישי — חזרה על מוצר שכבר נרכש. מתכלים, מסננים, מחסניות, מזון לבעלי חיים נקנים במחזוריות, וההמלצה מחויבת להתחשב בכך: במקום אחד להציע חזרה במרווח מחושב, במקום אחר — להחריג את הפריט ככזה שכבר נוצל. ללא סימון מחזור החיים של המוצר, האלגוריתם גורר לבלוק הכול ללא הבחנה ומרגיז את הלקוח הקבוע.
הסיבה הרביעית — היעדר משוב. קליקים על הבלוק, הוספות לסל וסירובים אינם חוזרים למודל, ולכן משקלי הקשרים אינם מחושבים מחדש, וכעבור חודש הבלוק מציג את אותה קבוצה כמו ביום ההשקה. מפרקים כיצד זה נסגר באמצעות חיבור בין 1С לחנות.
מה משתנה לאחר הטמעת התאמה לפי היסטוריית רכישות
כאשר ההמלצות מבוססות על היסטוריית הזמנות אמיתית מ-1С, ולא על בלוקים סטטיים ידניים, מה שמשתנה הוא לא "יופי הוויטרינה", אלא מדדים התנהגותיים: שיעור ההזמנות עם פריטים נוספים, הרכב הסל הממוצע והמרת כרטיס המוצר. להלן מה בדיוק ומה גורם לשינוי.
מכירות משלימות בקטלוג מפסיקות להיות הגרלה
תצוגה ידנית של "עם זה קונים" מתיישנת לאחר כל רוטציה של מלאי ואינה מתחשבת בעונתיות הביקוש. התאמה לפי היסטוריית רכישות מחשבת מחדש את הקשרים בין מוצרים על בסיס הזמנות אמיתיות: פריטים נלווים, רכישות חוזרות, מוצרים חלופיים.
כתוצאה מכך בלוק ההמלצות מציג את מה שבאמת נלקח יחד, ושיעור ההזמנות עם פריטים נוספים עולה בלי לחץ על הלקוח.
הסל הממוצע של החנות המקוונת עולה בזכות הרכב הסל
האפקט נוצר לא מכפייה, אלא מרלוונטיות: ללקוח מוצע פריט שמשלים באופן הגיוני את מה שכבר נבחר. הרכב הסל הממוצע גדל ב-1–2 פריטים בקרב אותו חלק מהקהל שאחרת היה מסתפק ברכישה אחת. בנפרד נפתרת הבעיה של בלוקים "ריקים" — כאשר ההמלצות אינן נוצרות והמקום בכרטיס עומד ללא שימוש.
המרת כרטיס המוצר ונטישות
בלוק המלצות ריק או לא רלוונטי פועל לרעת החנות: המבקר אינו מוצא המשך ועוזב. כאשר ההתאמה נשענת על היסטוריית רכישות, הכרטיס מקבל המשך דרך בעל משמעות — המעברים לעומק הקטלוג גדלים, והנטישות מבלוקים עם מוצרים לא רלוונטיים פוחתות. זה גם מפחית את העומס על המנהלים שמתקנים ידנית את התצוגה.
אנחנו עובדים עם 1C-Bitrix ו-Bitrix24 בשילוב עם מערכת הנה"ח, ולכן ההמלצות מחושבות על נתונים עדכניים על הזמנות, ולא על ייצוא שהתיישן לפני שבוע.
השוואת גישות: חוקים, רכישות משותפות, למידה מהזמנות
בלוק ההמלצות ב-1C-Bitrix נבנה על שלושה מנגנונים שונים מהותית, והבחירה ביניהם נקבעת לא לפי "אופנתיות" האלגוריתם, אלא לפי אילו נתונים על הזמנות כבר נצברו אצלכם ובאיזו תדירות משתנה המגוון.
חוקים של מוצרים נלווים פועלים על מומחיות של מנהל קטגוריה, רכישות משותפות — על סטטיסטיקה של קבלות אמיתיות, למידה מהזמנות — על דפוסי התנהגות שקשה לתאר ידנית.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| חוקים של מוצרים נלווים | מגוון מצומצם, קשרים ברורים (אביזרים לציוד, חומרים מתכלים), התחלה ללא היסטוריית הזמנות | דורש ליווי ידני: עם גדילת הקטלוג מספר החוקים גדל באופן לא ליניארי, קונפליקטים של עדיפויות יש לפתור ידנית |
| רכישות משותפות (סינון שיתופי לפי קבלות) | נצברו כמה מאות הזמנות, המגוון יציב, יש רכישות חוזרות | התחלה קרה: מוצר חדש לא ייכנס לתוצאות עד שמישהו יקנה אותו; רגישות לזינוקות חד-פעמיים בביקוש |
| למידה מהזמנות (מודל לפי היסטוריה) | קטלוג גדול, היסטוריה ארוכה, עונתיות מובהקת ופרופילים שונים של קונים | נדרשת אימון מחדש סדיר ובקרת איכות נתונים: כפילויות של פריטים, החזרות, הזמנות בדיקה מעוותות את המשקלים |
כיצד לבחור עבור הקטלוג שלכם
בפועל משלבים בין הגישות: חוקים מכסים את ההתחלה הקרה ואת הקשרים האסטרטגיים, סטטיסטיקת קבלות — תרחישים המוניים, המודל — התאמה אישית ללקוחות קבועים. אלגוריתם ההמלצות נבנה כך שבמחסור בנתונים הוא יורד אוטומטית לרמה פשוטה יותר, ולא מציג בלוק ריק.
הדרישה המרכזית לנתונים — ניקיון היסטוריית ההזמנות: אותו פריט תחת קודים שונים או החזרות שלא נלקחו בחשבון שוברים את המשקלים יותר מאשר חוסר בנפח. לכן לפני ההטמעה אנו בודקים את הייצוא מ-1С ומביאים את ספר המוצרים לצורה אחידה.
כיצד אנו מיישמים המלצות מוצרים של Bitrix על נתוני 1С
העבודה מתנהלת מתוך הנתונים, ולא מתוך מודול מוכן: תחילה בודקים מה באמת קיים ב-1С ובקטלוג, לאחר מכן בונים קשרים, ורק אז מפעילים את ההצגה. סדר השלבים זהה — משתנה היקף הייצוא והלוגיקה של ההתאמה למטריצת המוצרים הספציפית.
- ביקורת נתונים. בודקים את היסטוריית ההזמנות ב-1С: עומק, שיעור הפריטים עם קוד פריט תקין, כפילויות ומוצרים חלופיים. בנפרד מאמתים שהצעות המסחר בקטלוג מקושרות לאותם קודים, אחרת ההמלצות יפנו לשום מקום.
- סכמת קשרים. קובעים לפי אילו מאפיינים בונים את ההתאמה: רכישות משותפות בהזמנה אחת, קטגוריה, מותג, סדרה, תאימות. מגדירים אילו קשרים מחושבים בצד 1С ואילו בצד האתר, כדי לא להעביר את הקטלוג המלא בכל בקשה.
- ייצוא הזמנות. מגדירים העברה סדירה של היסטוריית רכישות אנונימית ומלאי אל Bitrix: אינקרמנטלית, לפי מסמכים שהשתנו, עם יומן שגיאות. כך ההמלצות נשענות על נתונים עדכניים, ולא על תמונת מצב מלפני חצי שנה.
- הגדרת ההצגה. מרכיבים בלוקים של המלצות למקומות באתר — כרטיס מוצר, סל הקניות, עמוד "תודה על ההזמנה". קובעים עדיפות של כללים, מגבלות על מספר הפריטים ומסננים: אזל מהמלאי, מדורים מוסתרים, מוצרים בהזמנה.
- בדיקה על הזמנות היסטוריות. מריצים את האלגוריתם על תקופות קודמות ובודקים אם ההתאמה הייתה נכנסת לרכישה בפועל. מתקנים משקלים וחותכים קשרים שנותנים התאמות מקריות.
- מדידה ומסירה. משווים את ההתנהגות לפני ואחרי: שיעור ההזמנות עם מוצר שנוסף, עומק הסל, מעברים מהבלוק. מוסרים הרשאות גישה, תקנון עדכון הנתונים והוראות לתיקון כללים.
שלבים 2 ו-3 מתנהלים במקביל להגדרת הייצוא — כך האינטגרציה של 1С ו-Bitrix אינה מעכבת את ההשקה. לאחר המסירה צוות הלקוח יכול לשנות עדיפויות של בלוקים ולהוסיף מקומות הצגה חדשים בלי לבנות מחדש את האלגוריתם.
מה נשאר לכם לאחר המסירה: תצורה, תרשימים, נהלים
אנחנו מעבירים את הפרויקט לא כ"גישה לפאנל", אלא כערכה שלמה שלפיה הצוות שלכם יוכל להתנהל בלעדינו. כל מה שקשור להמלצות — כללי ההתאמה, קישורי המוצרים, לוח הזמנים של החלפת הנתונים עם 1С — מתועד במסמכי הפרויקט, ולא נשאר בהתכתבויות ובראשים.
- כללי התאמת המלצות. אילו בלוקים באילו עמודים, לפי איזו לוגיקה נבנית התוצאה: רכישות משותפות, קטגוריות נלוות, הזמנות חוזרות. עם משקלים, ספים ותיאור מפורש של מה מוצג כאשר אין מספיק היסטוריה.
- מפת קישורי המוצרים. תרשים כיצד מותאמים הפריטים מ-1С, הצעות המסחר והכרטיסים באתר: לפי אילו מאפיינים מתבצעת ההתאמה, היכן מאוחסנים תחליפים ומקבילים, מה קורה כאשר מופיע מוצר חדש.
- הגדרות הייצוא. נוהל עדכון הנתונים: מה ובאיזו תדירות יוצא מ-1С, אילו שדות משתתפים בהתאמה, כיצד מטופלים פריטים שהופסק ייצורם ומלאי.
- הוראות לצוות התוכן. כיצד לסמן מוצר כדי שייכנס להמלצות או ייצא מהן, כיצד להגדיר קישורים ידניים מעל האוטומטיים, אילו שגיאות בכרטיס שוברות את ההתאמה.
- נוהל עדכון הנתונים. מי ומתי בודק שההחלפה עברה בהצלחה, כיצד לקרוא את היומן, מה לעשות במקרה של אי-התאמה בכמות הקישורים לאחר הייצוא.
- סדר מסירת ההגדרות. גישות, תפקידים, נקודות כניסה לחלק הניהולי — עם תיאור, כדי שמהנדס חדש יסתדר ללא שיחות אלינו.
- יומן שינויים. מה ולשם מה שונה בכללי ההתאמה, כדי שכעבור חצי שנה יהיה ברור מדוע התוצאה נראית בדיוק כך.
הערכה נשארת אצלכם במאגר ובבסיס הידע — מעדכנים בהתאם לצמיחת הקטלוג. אם תידרש הרחבה של לוגיקת ההתאמה או חיבור מקור נתונים חדש, תארו את המשימה — נחזור עם הערכה ותוכנית.
מקרה בוחן: התאמה לפי היסטוריית הזמנות בקטלוג של חומרי בניין
הלקוח — ספק חומרי בניין עם קטלוג של כמה עשרות אלפי פריטים. הקטלוג התארח על 1C-Bitrix, ניהול ההזמנות — ב-1С, ולא היה חיבור ביניהם: ההמלצות הוצגו כבלוקים סטטיים "עם זה קונים", שהובילו לפריטים אקראיים.
קונה שהכניס מלט וברזל בניין ראה בבלוקים אריחים דקורטיביים — הבלוקים לא השפיעו על הסל, והמנהלים אספו פריטים נלווים ידנית בטלפון.
מה שינו
אספנו את היסטוריית ההזמנות מ-1С למאגר נפרד ובנינו כללי התאמה לפי שילובים בפועל של פריטים בקבלות, ולא לפי קשרים ידניים. הלוגיקה מתחשבת בקטגוריה, ביחידת המידה ובכפילות האריזה: לשקית תערובת נמשכת פריימר, לפרופיל — מחברים בכמות הנדרשת, ולא "מוצר דומה מהמדור". את התפוקה העברנו דרך מטמון עם רענון לפי אירועי הזמנה — הבלוקים הפסיקו להאט את כרטיס המוצר.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| שיעור ההזמנות עם פריטים נוספים | 18% | 34% |
| חזרות בבלוקים בכרטיס המוצר | עד 40% | פחות מ-5% |
| זמן תפוקת ההמלצות | 1.8 שנ' | 120 מ"ש |
בנפרד סגרנו בלוקים ריקים: אם אין סטטיסטיקה לפריט, ההתאמה חוזרת לכללי הקטגוריה, ולא מציגה ממלא מקום. חודשיים לאחר ההשקה שיעור ההזמנות עם פריטים נוספים גדל כמעט פי שניים, החזרות בבלוקים נעלמו, ומהירות התפוקה הפסיקה להיות תלויה בגודל הקטלוג. את הפרויקט הוביל המהנדס שלנו, שעבד עם החלפה בין 1C-Bitrix ל-1С.
במה שונה התאמה לפי היסטוריית רכישות ממוצרים דומים?
אלו שלושה מנגנונים שונים, ואסור לבלבל ביניהם — הבחירה קובעת מה הלקוח יראה בכרטיס המוצר. "מוצרים דומים" נבנים על מאפיינים של המוצר עצמו: קטגוריה, מותג, מאפיינים, תגיות. זהו קשר סטטי — הוא אינו תלוי במי שצופה בדף, והוא זהה עבור כולם.
בלוק כזה פותר משימת ניווט: האדם הגיע לכרטיס ורוצה לראות חלופות בתוך אותה קבוצה. אם המוצר הוא היחיד בקטגוריה או שהמאפיינים מולאו ברשלנות, הבלוק יהיה ריק או יציג סט אקראי — לכן איכותו תלויה לחלוטין במידת העדכון המלא והאחיד של הקטלוג.
"קונים עם זה" — זו כבר סטטיסטיקה לפי הזמנות, אך אנונימית. המנגנון אוסף זוגות של מוצרים שמופיעים באותן הזמנות, ומציג את השילובים הנפוצים ביותר. כאן פועלת לא ההיגיון של הקטלוג אלא ההתנהגות של כל הקונים בבת אחת: הבלוק מרמז מה מוסיפים לפריט הנבחר. המגבלה היא שבמוצרים נדירים יש מעט סטטיסטיקה — הזוג נצבר לאט, והבלוק נשאר ריק לזמן מה.
בלוקים אישיים לפי היסטוריית רכישות — זו הרמה השלישית. הם מסתכלים לא על המוצר אלא על לקוח מסוים: מה הוא הזמין קודם, באיזו תדירות, מה לקח בפעם האחרונה. אם החנות המקוונת מחוברת ל-1С, ההיסטוריה נלקחת מהזמנות אמיתיות, ולא רק מהסל באתר — כולל רכישות אופליין ולפי חשבוניות.
זה נותן התאמה שאף אחד מהבלוקים הקודמים לא ירכיב: מתכלים למוצר שכבר נרכש, מוצרים שפג תוקף ההחלפה שלהם, פריטים מאותה סדרה שהלקוח לוקח באופן קבוע.
בפועל, המנגנונים האלה לא מחליפים זה את זה אלא משלימים זה את זה. בכרטיס המוצר מתאימים "דומים" ו"קונים עם זה" — הם עוזרים לבחור כאן ועכשיו. הבלוק האישי עובד חזק יותר בעמוד הבית, באזור האישי ובאימיילים: שם הוא מחזיר את הלקוח למה שהוא באמת קונה.
אנחנו מגדירים את שלושתם, אבל התאמה אישית מוצגת רק כשיש היסטוריית הזמנות מספקת — אחרת הבלוק מציג פריטים אקראיים ומערער את האמון בהמלצות.
ספקות טכניים נפוצים לגבי המלצות ב-Bitrix
ההמלצות מבוססות על היסטוריית הזמנות, ולא על "קסם" — לכן השאלה הראשונה היא תמיד לגבי איכות הנתונים. אם ב-1C חלק מההזמנות נרשמו בדיעבד, חלק מהפריטים נמחקו ידנית, ועסקאות ישנות מונחות ללא קישור ללקוח, האלגוריתם ילמד על רעש.
אנחנו מתחילים בבדיקה: משווים את מזהי הפריטים, הצעות המכירה והמאפיינים, מסננים כפילויות והזמנות בדיקה, ומביאים את הסטטוסים למילון אחיד. רק לאחר מכן הקשרים "קונה → מוצר" הופכים לצפויים.
העומס על הקטלוג הוא החשש השני בשכיחותו. חישוב מחדש של המלצות בכל הצגת עמוד אכן מפיל את הקטלוג, לכן הקשרים מחושבים מראש, לפי לוח זמנים, ונשמרים בטבלה נפרדת. הוויטרינה קוראת תוצאה מוכנה מהמטמון, ולא מריצה שאילתות כבדות על כל היסטוריית ההזמנות.
מה עושים אם נתוני ההזמנות חלקיים או שחלק מההיסטוריה אבד?
עובדים עם מה שיש: משלימים קשרים לפי סימנים עקיפים — קטגוריות, מותג, רכישות משותפות באותה הזמנה. אם ההיסטוריה מועטה, ההמלצות בשלב הראשון נשענות על מוצרים דומים ופופולריות בקטגוריה, וככל שנצברות הזמנות הן עוברות בהדרגה להמלצות אישיות. שלמות הנתונים נבדקת בשלב הביקורת ומתעדים אילו שדות חסרים.
איך ההמלצות מתחשבות במלאי ולא יציעו מוצר שאינו קיים?
התחשבות במלאי מגיעה מ-1C: פריטים עם מלאי אפס או שהוסרו מהמכירה מוחרגים מהתצוגה עד הסנכרון הבא. אם המוצר נגמר בין העדכונים, ההצגה מגובה בבדיקת זמינות ברגע המסירה. כך ההמלצה לא מובילה את הלקוח למבוי סתום עם מוצר שאינו זמין.
באיזו תדירות מתעדכנים הקשרים ומה יקרה בעת כשל בסנכרון?
החישוב מחדש מתבצע לפי לוח זמנים — בדרך כלל פעם ביום בשעות עומס נמוך, ובמכירות פעילות לעתים קרובות יותר. אם החלפה עם 1C לא עברה, הוויטרינה ממשיכה להציג את הסט המוצלח האחרון, ולא ריק: כשל בסנכרון לא שובר את התצוגה. שגיאות החלפה נרשמות בלוג, ואנחנו רואים באיזה שלב הנתונים אבדו.
נדון במשימה שלכם ונחזור עם הערכה ותוכנית
כדי לחזור עם הערכת פרויקט ולא עם מילים כלליות, אנחנו צריכים הקשר על ה-1C-Bitrix שלכם ונתונים על המכירות. המלצות מוצרים נבנות על היסטוריית רכישות, ולכן דיוק ההערכה תלוי ישירות במידת השלמות שבה תעבירו את התמונה על הקטלוג וההזמנות.
שלחו את מה שיש בהישג יד — את השאר נבהיר בשיחת זום:
- ייצוא או תיאור של מבנה הקטלוג: מדורים, מאפיינים, הצעות מסחריות, מלאי לפי מחסנים;
- כיצד מנוהלת כעת היסטוריית ההזמנות — ב-Bitrix, ב-1С או בשתי המערכות במקביל, ובאיזו תדירות מתבצע הסנכרון;
- אילו נתונים על הלקוח זמינים: אימות, שיוך הזמנות לפרופיל, הסכמות לעיבוד;
- דוגמאות למוצרים שעבורם ההמלצות כבר עובדות או, להפך, מפיקות תוצאות שגויות;
- היכן ההמלצות אמורות להופיע: כרטיס מוצר, סל קניות, מיילים, עמוד הבית;
- מגבלות על עומס ומצב סנכרון, אם קיימות;
- איש קשר של האדם שיאשר את כללי הלוגיקה העסקית.
לפי נתוני פתיחה אלה אנחנו מרכיבים תוכנית עבודה: ביקורת הסנכרון הנוכחי עם 1С, תרשים הקשרים בין ההזמנות לקטלוג, בחירת גישה לבחירת מוצרים דומים, הגדרת תצוגת הבלוקים ובדיקה על תעבורה אמיתית.
בסיום אתם מקבלים הערכה לפי שלבים, סדר היישום ורשימת סיכונים — מה יכול לעכב את ההשקה וכיצד לסגור זאת מראש.
תארו את המשימה בצורה הנוחה לכם — נחזור עם הערכה ותוכנית עבודה.