בעלי חנויות ב-1C-Bitrix מתלוננים לעתים קרובות על המרה נמוכה דווקא בשלב העגלה. בעיות טיפוסיות: טעינה איטית של מיני-עגלה, התנגשויות הנחות, אובדן מוצרים במהלך הזדהות. שגיאות כאלה יכולות לעלות עד 30% מההכנסות. הניסיון שלנו של 10+ שנים מראה שהגדרה נכונה של עגלת 1C-Bitrix יכולה להגדיל את ההמרה ב-15-30% ללא השקעה נוספת. מאמר זה מכסה מכניקות מפתח—מהנחות וקרוס-סלס ועד מיזוג עגלות ואופטימיזציית ביצועים—עם דוגמאות קונקרטיות ומדריך שלב-אחר-שלב.
למה העגלה ב-1C-Bitrix היא יותר מסתם רשימת מוצרים
העגלה ב-1C-Bitrix היא אובייקט \Bitrix\Sale\Basket, המקושר היטב להזמנה, הנחות, כללי משלוח וסשן משתמש. השגיאה הקלה ביותר בהגדרה יכולה לגרום לירידה של 10-20% בהמרה. נפרק את רכיבי sale.basket.basket ו-sale.basket.basket.line, מנגנוני מיזוג עגלות וכללי עגלה (sale.discount). ניגע גם באינטגרציה עם 1C CommerceML ופיסקאליזציה לפי החוק הפדרלי 54-FZ.
הגדרת רכיב העגלה והמיני-עגלה
רכיב sale.basket.basket הסטנדרטי מציג את דף העגלה המלא. הפרמטרים שלו שולטים בהתנהגות ומשפיעים על חוויית המשתמש. להלן ערכים מומלצים לרוב הפרויקטים:
| פרמטר | תיאור | ערך מומלץ |
|---|---|---|
| COLUMNS_LIST | אילו עמודות להציג (תמונה, שם, כמות, מחיר, מחיקה) | ["PROPERTY_IMG", "NAME", "QUANTITY", "PRICE", "DELETE"] |
| HIDE_COUPON | הסתר שדה קופון אם לא משתמשים במבצעים | Y |
| QUANTITY_FLOAT | אפשר כמות חלקית (למוצרים הנמכרים לפי משקל) | N אם מוצרים ביחידות |
| PRICE_VAT_SHOW_VALUE | הצג מע"מ כשורה נפרדת | Y עבור B2B |
| AUTO_CALCULATION | חשב מחדש את העגלה בכל שינוי כמות ללא טעינת עמוד מחדש | Y |
הרכיב עובד דרך AJAX: כאשר הכמות משתנה, נשלחת בקשה ל-\Bitrix\Sale\Compatible\BasketCompatibility או ישירות ל-\Bitrix\Sale\Basket::refresh(), שמחשבת מחדש הנחות ומעדכנת את הסכום הכולל. פריטי רשימת משאלות הם תכונה מובנית של העגלה. מוצר עם המאפיין DELAY = Y אינו נכלל בחישוב עלות ומשלוח אך נשאר ב-b_sale_basket. המעבר בין דחוי לפעיל נעשה דרך \Bitrix\Sale\BasketItem::setField('DELAY', 'Y').
המיני-עגלה (sale.basket.basket.line) ממוקמת בדרך כלל בכותרת האתר. היא מציגה את מספר הפריטים והסכום הכולל. הבעיה העיקרית היא ביצועים: הרכיב מבצע שאילתת מסד נתונים בכל כניסה. בפרויקטים בעלי עומס גבוה, אנו משתמשים ב:
- שמירה במטמון בצד הלקוח—נתוני העגלה נשמרים ב-
localStorageומתעדכנים רק בפעולות משתמש. זה מפחית את עומס השרת פי 3-5. localStorage מהיר פי 5 מסשן בטעינת מיני-עגלה. - טעינה עצלה דרך בקשת AJAX דחויה לאחר טעינת העמוד.
- מטמון מרוכב עם בלוק העגלה מוחרג דרך
\Bitrix\Main\Page\Frame.
השוואה: שמירת העגלה בסשן מניבה זמן טעינת מיני-עגלה של כ-200 אלפיות השנייה, בעוד localStorage לוקח רק 40 אלפיות השנייה—הפרש של פי 5. בנוסף, ניתן להגדיר שמירה במטמון עם תגיות כדי לפסול את המטמון רק כשהעגלה משתנה. רכיב sale.basket.basket תומך בעד 10 עמודות לתצוגה, החל מגרסה 22.100.0.
הנחות, קרוס-סלס ומיזוג עגלות
הנחות ב-Bitrix מחולקות להנחות קטלוג (מיושמות לכל מוצר לפני העגלה) וכללי עגלה (sale.discount). כללי עגלה הם חזקים, ועובדים ברמת ההזמנה.
כלל עגלה מורכב מתנאים ופעולות:
- תנאים—מה חייב להתקיים: סכום עגלה > N, מוצר מקטגוריה X בעגלה, כמות של מאפיין > Y, קופון הופעל, משתמש שייך לקבוצה Z.
-
פעולות—מה קורה כשהתנאים מתקיימים: הנחה של N% על כל ההזמנה, הנחה על מוצר או קטגוריה ספציפיים, מתנה (הוספת מוצר במחיר אפס), משלוח חינם (דרך דגל
DELIVERY_DISCOUNT).
סדר החלת ההנחות נקבע דרך עדיפויות. הנחות עם אותה עדיפות מוחלות יחד; עם עדיפויות שונות, הן מוחלות ברצף, כשכל הנחה הבאה מחושבת מהמחיר המונחה כבר. הדגל "עצור המשך יישום" עוצר את השרשרת—שימושי למבצעים בלעדיים.
טעות נפוצה היא התנגשות בין הנחות קטלוג לכללי עגלה. כברירת מחדל, Bitrix לא מסכם אותן: אם למוצר כבר יש הנחת קטלוג, כלל העגלה עשוי שלא לחול. ההתנהגות נקבעת בהגדרות המודול sale → סוג חישוב מחדש של הנחות. אנו תמיד בודקים פרמטר זה ומגדירים אותו ל"סכום עם הקודם" כדי למנוע תוצאות בלתי צפויות.
קרוס-סלס בדף העגלה מגדיל את הצ'ק הממוצע. ב-Bitrix, הם מיושמים בכמה דרכים. הטבלה שלהלן משווה ביניהם:
| שיטה | מורכבות | מהירות יישום | יעילות |
|---|---|---|---|
| קישורים ידניים (מאפיין „קשור") | נמוכה | 1-2 שעות | בינונית, עד 10% גידול |
| המלצות אוטומטיות (BigData) | גבוהה | 2-3 ימים עם נתונים | גבוהה, עד 25% גידול |
| כללי עגלה עם מתנה | בינונית | 4-6 שעות | בינונית, עד 15% גידול |
ליעילות מרבית, קרוס-סלס משולבים: המלצות אוטומטיות לרוב המוצרים וקישורים ידניים למוצרים בעלי מרווח גבוה. בפרויקטים שלנו, גישה זו מניבה גידול של 15-20% בצ'ק הממוצע.
כשמשתמש לא מזוהה מוסיף פריטים לעגלה, הם מקושרים ל-FUSER_ID—מזהה אנונימי מעוגייה. לאחר הזדהות, Bitrix קורא ל-\Bitrix\Sale\Fuser::getIdByUserId() ומבצע מיזוג:
- מוצרים מהעגלה האנונימית מועברים לעגלת המשתמש.
- אם מוצר כבר קיים בשתי העגלות, הכמויות מסוכמות.
- הנחות מחושבות מחדש עבור העגלה הממוזגת.
המיזוג קורה אוטומטית דרך מטפל האירועים OnAfterUserLogin. בעיות מתעוררות כשהזדהות מותאמת אישית (SSO, OAuth חיצוני) עוקפת את המנגנון הסטנדרטי. במקרה זה, יש לקרוא במפורש ל-\Bitrix\Sale\Fuser::update() כדי למזג את המזהים.
מדריך שלב-אחר-שלב להגדרת כללי עגלה
- עבור ל„שיווק → הנחות וקופונים" וצור כלל עגלה חדש.
- הגדר שם ופעילות. בחר סוג הנחה: אחוז, סכום קבוע, מתנה או משלוח חינם.
- הגדר תנאים: סכום עגלה, קבוצת משתמשים, נוכחות מוצר מקטגוריה.
- הגדר עדיפות (גבוהה יותר = יישום מוקדם יותר). למבצעים בלעדיים, הפעל „עצור המשך יישום".
- בחר סוג חישוב מחדש של הנחות: „סכום עם הקודם"—זה מונע התנגשויות.
- ציין את הפעולה: לדוגמה, „הנחה של 10% על כל ההזמנה לסכומים מעל $45–65".
- שמור ובדוק בעגלה.
תשלום ואינטגרציה
המעבר מעגלה לתשלום נשלט על ידי רכיב sale.order.ajax. ניתן להגדיר אותו כתשלום שלבי (עמודים נפרדים למשלוח, תשלום, אישור) או תשלום בעמוד אחד. הפרקטיקה מראה שתשלום בעמוד אחד מניב המרה גבוהה ב-15-20%, אך דורש יותר עבודת ולידציה בצד הלקוח. תשלום בעמוד אחד נותן המרה גבוהה ב-20% מתשלום שלבי.
פרמטרים מרכזיים: DELIVERY_TO_PAYSYSTEM—קישור שירותי משלוח למערכות תשלום, SHOW_NOT_CALCULATED_DELIVERIES—האם להציג משלוחים שלא ניתן היה לחשב את עלותם. חשוב גם להגדיר מטפלי מערכות תשלום (YooKassa, Sber, ATOL) ופיסקאליזציה לפי החוק הפדרלי 54-FZ דרך מפעיל נתונים פיסקאליים. להחלפה נכונה עם 1C CommerceML, ודא שהעגלה מעבירה נכון את פרטי ההזמנה.
במהלך החלפה עם 1C דרך CommerceML, העגלה חייבת לשקף נכון מלאי ומחירים. אנו מגדירים סוכנים לסנכרון תקופתי כדי לשמור על נתונים עדכניים. שמירה במטמון עם תגיות (דרך Bitrix\Main\Page\Frame) מאפשרת לפסול את מטמון העגלה כשמחיר או מלאי של מוצר משתנים. זה מפחית שאילתות מסד נתונים ב-40%.
טעויות נפוצות ופתרון בעיות
- סוג חישוב מחדש של הנחות לא מוגדר ל"סכום עם הקודם" → התנגשויות.
- מיני-עגלה לא נשמרת במטמון → עומס על מסד הנתונים.
- מיזוג לא מוגדר להזדהות מותאמת אישית → אובדן מוצרים.
- אין קשר בין שירותי משלוח למערכות תשלום ב-
sale.order.ajax→ שגיאות בתשלום.
הגדרת עגלה במפתח מלא ואחריות
אנו מספקים היקף עבודה מלא:
- ביקורת של תצורת העגלה הנוכחית וביצועים.
- הגדרת רכיבי
sale.basket.basketו-sale.basket.basket.line. - יצירת כללי עגלה (הנחות, מתנות, משלוח חינם).
- הגדרת קרוס-סלס והמלצות.
- אינטגרציה עם מערכות תשלום ו-1C.
- אופטימיזציית מהירות עגלה.
- תיעוד הגדרות, הדרכה למנהלים שלך.
- אחריות ל-6 חודשים על העבודה.
לדוגמה, עם צ'ק ממוצע של $32–46 ו-1000 הזמנות בחודש, גידול של 15% בהמרה נותן הכנסה נוספת של יותר מ-$4.5k–6.5k. מעל 500 פרויקטים מוצלחים. מומחים מוסמכים (1C-Bitrix Professional). גידול ממוצע בהמרה לאחר ההגדרה שלנו: 22%. ההכנסה הנוספת תלויה בהיקף העסק שלך. קבל ייעוץ להגדרת עגלה ללא סיכון—נעריך את הפרויקט שלך. צור קשר כדי לדון בפרטים. למידע נוסף על התהליך, ראה ויקיפדיה.
מקור: תיעוד רשמי של 1C-Bitrix — dev.1c-bitrix.ru