פיתוח מודול מערכת המלצות 1C-Bitrix במפתח סופי

מדוע מערכת ההמלצות של 1C-Bitrix לא מניבה תוצאות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פרקטיקת הטמעה: מבחרים בקטלוג החנות

איך נראו התוצאות לפני העבודה

הקטלוג ב-1C-Bitrix הציג «מוצרים דומים» לפי סימן פורמלי — מדור משותף ומותג. במגוון של כ-12,000 פריטים ובעשרות תת-קטגוריות זה יצר קשרים אקראיים: ליד משאבה הופיעו אביזרים בקוטר אחר, ומתכלים עבורה לא הוצגו בכלל.

המנהלים הרכיבו ידנית כ-120 מבחרים דרך מאפיינים וכללי הנחות, ולאחר החלפת ספק חצי מהקישורים הובילו לשום מקום. שיעור ההזמנות שבהן הקונה לקח מוצר ממבחר כזה עמד על 3-4%, ועומק הצפייה — 4.1 עמודים לסשן.

מה שינו ומה זה נתן

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

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

אחרי חודשיים שיעור ההזמנות עם מוצרים שנבחרו עלה מ-3-4% ל-27%, עומק הצפייה — ל-6.3 עמודים, והרכישות החוזרות בקטלוג הוסיפו 18%. המבחרים הידניים נעלמו: נשארו שמונה עונתיים, שמתעדכנים לפי לוח האספקות.

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

במה מערכת ההמלצות שונה מבלוקים מוכנים

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

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

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

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

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

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

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

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

איך ההמלצות משפיעות על העומס על הקטלוג?

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

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

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

מה כולל התחזוקה לאחר ההשקה?

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

נדון במשימה ונחזור עם הערכה ותוכנית עבודה

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

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

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

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