הנחות מצטברות ב-1C-Bitrix: אוטומציה בלי כאב ראש

הנחות מצטברות ב-1C-Bitrix: אוטומציה ללא כאב ראש

דמיינו שלקוח ביצע חמש רכישות, בסך כולל של $720–1k, אבל המערכת עדיין מתייחסת אליו כאל חדש. ללא הנחות מצטברות, הנאמנות יורדת, ומתחרים חוטפים לקוחות. ב-1C-Bitrix אין מודול מובנה להנחות מדורגות — נדרשת לוגיקה מותאמת אישית בכל פעם. במשך שנים רבות, מפתחי Bitrix המוסמכים שלנו יישמו מכניקה זו ביותר מ-50 פרויקטים: מחנויות עם 10,000 לקוחות ועד קטלוגים עם מיליוני מוצרים. הפתרונות נבדקו תחת עומס וקאשינג, ולכן אנו חולקים גישות מוכחות בשטח. ערך הזמנה ממוצע עולה ב-15–20% לאחר היישום, והחיסכון בעדכונים במהלך שכפול מגיע ל-25%. עלות יישום טיפוסית מתחילה מ-$2,000, עם תוצאות מובטחות.

אילו גישות משמשות ב-Bitrix?

האפשרות הראשונה היא קבוצות משתמשים עם הצמדת מחיר. נוצרת היררכיה: "בסיסי", "כסף" (5% הנחה), "זהב" (10%), "פלטינה" (15%). כל קבוצה מקבלת מחיר משלה בקטלוג המסחר. המעבר בין קבוצות מתבצע באמצעות מטפל האירועים OnSaleOrderSaved.

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

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

כיצד להגדיר מעבר קבוצות אוטומטי?

השיטה האמינה ביותר היא מטפל OnSaleOrderSaved. דוגמת קוד:

AddEventHandler('sale', 'OnSaleOrderSaved', function(\Bitrix\Main\Event $event) {
    $order = $event->getParameter('ENTITY');
    $userId = $order->getUserId();
    // Посчитать сумму оплаченных заказов пользователя
    $totalPaid = \Bitrix\Sale\Order::getList([
        'filter' => ['USER_ID' => $userId, 'PAYED' => 'Y'],
        'select' => ['PRICE'],
    ])->fetchAll();
    $total = array_sum(array_column($totalPaid, 'PRICE'));
    // Перевести в нужную группу
    if ($total >= 50000) {
        CUser::SetUserGroup($userId, array_merge(CUser::GetUserGroup($userId), [PLATINUM_GROUP_ID]));
    } elseif ($total >= 20000) {
        CUser::SetUserGroup($userId, array_merge(CUser::GetUserGroup($userId), [GOLD_GROUP_ID]));
    }
});

התיעוד של 1C-Bitrix ממליץ להעביר לוגיקה כבדה לסוכנים. חשוב מכך, חישוב מחדש צריך להתבצע רק עבור הזמנות ששולמו; אחרת, מוענקות הנחות על רכישות שלא הושלמו. כמו כן, תמיד נקו את מטמון קבוצות המשתמשים באמצעות AddEventHandler('sale', 'OnSaleOrderSaved', function(\Bitrix\Main\Event $event) { $order = $event->getParameter('ENTITY'); $userId = $order->getUserId(); // Посчитать сумму оплаченных заказов пользователя $totalPaid = \Bitrix\Sale\Order::getList([ 'filter' => ['USER_ID' => $userId, 'PAYED' => 'Y'], 'select' => ['PRICE'], ])->fetchAll(); $total = array_sum(array_column($totalPaid, 'PRICE')); // Перевести в нужную группу if ($total >= 50000) { CUser::SetUserGroup($userId, array_merge(CUser::GetUserGroup($userId), [PLATINUM_GROUP_ID])); } elseif ($total >= 20000) { CUser::SetUserGroup($userId, array_merge(CUser::GetUserGroup($userId), [GOLD_GROUP_ID])); } }); .

מדוע קבוצות משתמשים מהירות יותר מהנחות על הזמנות?

בכל רינדור עגלה, הנחות על הזמנות שואלות את היסטוריית הרכישות. בקטלוג עם 50,000 פריטים, זה גורם לעיכוב ניכר. קבוצות שומרות את ההנחה פעם אחת בטבלת CCacheManager::ClearByTag("USER_GROUPS_".$userId) — המחירים נשלפים מיד. לפרויקטים עם תעבורה גבוהה, קבוצות הן האפשרות היחידה ללא פגיעה בביצועים.

כיצד להימנע מפגיעה בביצועים עם 10,000+ לקוחות?

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

תהליך הגדרת הנחות מצטברות: מניתוח ועד פריסה

1. ניתוח — אנו בוחנים ערך הזמנה ממוצע (לדוגמה, $720–1k), תדירות רכישות (2–3 הזמנות בחודש), מגדירים 5 ספי הנחה (5%, 10%, 15%, 20%, 25%).
2. עיצוב — בוחרים בגישה (קבוצות או הנחות), מתכננים את מבנה הקבוצות והצמדת מחירים ל-100,000 פריטים.
3. יישום — כותבים את המטפל או מגדירים הנחות, מוסיפים פס התקדמות בחשבון האישי המציג את הסכום הנוכחי (לדוגמה, "נשארו $45–65 עד להנחה של 15%").
4. בדיקות — מדמים 200+ הזמנות בסביבת בדיקה, מוודאים מעבר תקין עם 10,000 משתמשים.
5. פריסה — מעלים לסביבת הייצור, מגדירים קאשינג, מספקים המלצות ניטור.

תוצרים

• יצירת קבוצות משתמשים והצמדת מחירים (אם נבחרה שיטת הקבוצות).
• פיתוח מטפל USER_GROUPS_{userId} עם דה-דופליקציה וקאשינג.
• הגדרת הנחות על הזמנות (אם נבחרה שיטת ההנחות).
• פיתוח רכיב פס התקדמות לחשבון האישי.
• תיעוד טכני מפורט וגישת ניהול.
• חודש של תמיכה לאחר פריסה ותיקון באגים.
• הדרכה לעד 3 מנהלים בניהול הנחות ידני.

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

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

טעויות יישום טיפוסיות

1. כלילת כל ההזמנות, כולל כאלה שלא שולמו. זה מוביל להשגת סף שגויה. השתמשו בדגל OnSaleOrderSaved.
2. התעלמות מקאשינג. ללא ניקוי מטמון המשתמש, המחיר החדש לא יחול עד לכניסה הבאה.
3. חוסר יכולת מעבר ידני. מנהלים זקוקים לממשק לשדרוג ידני של סטטוס לקוח.

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