תמחור דינמי: מחוקים למנגנון טיפול
דמיינו פלטפורמת מסחר אלקטרוני לאלקטרוניקה על 1C-Bitrix עם 10,000 פריטים. מוצר אחד — כונן SSD. כאשר רמת המלאי יורדת מתחת ל-10 יחידות, המחיר עולה אוטומטית ב-20% — ללא הנחות ידניות, רק לוגיקה בקוד. ניתן ליישם הגדרת תמחור דינמי זו על ידי חיבור לאירוע OnGetOptimalPrice — אנו עוקפים את המחיר תוך כדי תנועה מבלי לגעת בטבלת b_catalog_price. יישמנו למעלה מ-40 פרויקטים עם תמחור מבוסס ביקוש לחנויות בגדלים שונים, תוך ניצול מקדמי גמישות מחירים. הלקוחות שלנו מקבלים ביקורת שקופה: כל השינויים מתועדים בטבלה נפרדת. https://en.wikipedia.org/wiki/Dynamic_pricing
כיצד Bitrix מחשב את המחיר הסופי
שרשרת החישוב: מחיר בסיס (b_catalog_price) → הנחות קטלוג (b_catalog_discount) → כללי סל (b_sale_discount) → סה"כ. תמחור דינמי פועל ברמה הראשונה — הוא משנה את המחיר הבסיסי או מיירט אותו דרך אירוע OnGetOptimalPrice ומחזיר ערך שונה. אירוע Bitrix מופעל בכל בקשה למחיר: ברשימת המוצרים, בעמוד הפרטים, בעגלה. ללא אופטימיזציה, שאילתת DB אחת עולה 0.3 אלפיות השנייה, אבל עמוד קטלוג עם 48 פריטים פירושו 48 שאילתות, עם סיכון ל-cache stampede. הפתרון הוא שמירת מחירים במטמון עם TTL של 5 דקות, תוך שימוש בעדכוני מטמון אטומיים למניעת נתונים מיושנים. זה מפחית את העומס פי 10.
גישה מבוססת אירועים לעומת כתיבות DB ישירות
| קריטריון | דרך אירוע OnGetOptimalPrice |
שינוי מחיר ישיר ב-b_catalog_price |
|---|---|---|
| ניקיון היסטוריית מחירים | המחיר נשאר ללא שינוי, המקדם מוחל תוך כדי תנועה | ממלא את ההיסטוריה בערכים מיותרים |
| מהירות החזרה למצב קודם | מיידית — השבתת הכלל | דורש שחזור ערכים קודמים (עד שעתיים) |
| אינדוקס עדכון מחירים | ללא השפעה | עלול לעוות ייצואים |
| ביצועים | בקשת מטמון אחת למוצר | שאילתות כתיבה רבות בכל שינוי |
האירוע מקצר את זמן החזרה למצב קודם לדקה אחת, בעוד כתיבות ישירות דורשות שחזור מגיבוי. הגישה מבוססת האירועים מהירה פי 10 מכתיבות DB ישירות לחזרה למצב קודם. שמירת מחירים במטמון עם פסילת תג bl_dynamic_pricing_rules מאיצה את העבודה פי 10.
הגדרת כללי תמחור דינמי
הכללים מאוחסנים בטבלה מותאמת אישית rule_type. להלן השדות שלה עם דוגמאות:
| שדה | תיאור | דוגמה |
|---|---|---|
stock |
demand / competitor / time / stock |
iblock_id |
17 |
בלוק מידע או NULL (הכל) | product_id |
1234 |
מוצר ספציפי או NULL (הכל בקטע) | condition_json |
{"min_stock": 5} |
פרמטרי תנאי (מלאי, שעה, מקדם) | price_modifier |
1.2 |
מקדם (1.15 = +15%, 0.9 = -10%) | priority |
10 |
סדר יישום במקרה של התנגשות | active |
Y |
מופעל/מושבת | b_catalog_store_product |
כאשר יש התנגשות בין כללים, הכלל בעל העדיפות הגבוהה ביותר מוחל.
דוגמה: כלל מבוסס מלאי
כאשר מלאי המוצר יורד מתחת לסף, אנו מעלים את המחיר. זה מעודד רכישות מהירות יותר או מרסן עליות ביקוש. המלאי נשלף מ-$stock = \Bitrix\Catalog\StoreProductTable::getList([ 'filter' => ['PRODUCT_ID' => $productId], 'select' => ['AMOUNT'], 'runtime' => [new \Bitrix\Main\ORM\Fields\ExpressionField('TOTAL', 'SUM(%s)', 'AMOUNT')], ])->fetch()['TOTAL'] ?? 0; if ($stock < 5) return 1.2; // +20% при остатке < 5 шт if ($stock < 20) return 1.1; // +10% при остатке < 20 шт return 1.0; :
דוגמת קוד PHP
$stock = \Bitrix\Catalog\StoreProductTable::getList([ 'filter' => ['PRODUCT_ID' => $productId], 'select' => ['AMOUNT'], 'runtime' => [new \Bitrix\Main\ORM\Fields\ExpressionField('TOTAL', 'SUM(%s)', 'AMOUNT')], ])->fetch()['TOTAL'] ?? 0; if ($stock < 5) return 1.2; // +20% при остатке < 5 шт if ($stock < 20) return 1.1; // +10% при остатке < 20 шт return 1.0; ניתן להגדיר ספים ומקדמים בממשק הניהול.
שלבים להגדרת כלל מלאי
- צרו כלל בממשק הניהול (סעיף "תמחור דינמי").
- הגדירו סוג ל-
stock. - הגדירו ספי מלאי (לדוגמה,
<5,5-20). - הקצו מקדם שינוי מחיר (לדוגמה,
1.2עבור +20%). - הפעילו שמירת מטמון עם TTL של 300 שניות.
- בדקו על מוצר יחיד — בדקו את המחיר בחנות.
- הפעילו את הכלל על כל הקטלוג.
אופטימיזציית ביצועים
ללא שמירת מטמון, עמוד קטלוג עם 48 מוצרים מפעיל 48 קריאות לאירוע OnGetOptimalPrice ל-DB. עם שמירת מחירים במטמון, יש שאילתה אחת כל 5 דקות. העומס יורד פי 10, ואנו מונעים cache stampede באמצעות עדכונים אטומיים. אנו גם משתמשים במטמון המתויג של Bitrix (\Bitrix\Main\Data\Cache) עם TTL של 300 שניות ופסילת תג dynamic_price_{productId}. זה מאפשר תמיכה בקטלוגים של עד 100,000 מוצרים ללא ירידה בביצועים, אפילו עם עומס גבוה.
תהליך העבודה
- ניתוח: אנו לומדים את תוכנית התמחור הנוכחית, דרישות העסק ועומס האתר, תוך שילוב גמישות מחירים ומדדי מחזור מלאי.
- עיצוב: אנו יוצרים את מבנה הטבלה
bl_dynamic_pricing_rulesולוגיקת עדיפויות עם ארכיטקטורה מונעת אירועים. - פיתוח: אנו כותבים את המחלקה
DynamicPricingEngineעם שמירת מטמון, מצמידים את מנגנון הטיפולOnGetOptimalPriceב-init.php. - ממשק ניהול: אנו יוצרים טופס לניהול כללים (הוספה, עריכה, הפעלה/השבתה).
- תיעוד: אנו רושמים את כל יישומי הכללים ב-
bl_dynamic_pricing_logלצורך ביקורת. - בדיקות: בדיקות עומס על קטלוג של 100,000 מוצרים, בדיקות נכונות מחירים ובדיקות לחץ ל-cache stampede.
- פריסה ותיעוד: הוראות למפעילים להגדרת כללים.
מה כלול בתוצאה
לאחר סיום, תקבלו:
- מנוע תמחור דינמי פועל המבוסס על כללים;
- ממשק ניהול לניהול כללים ללא גישה לקוד;
- יומני כל שינויי המחירים לצורך ביקורת;
- תיעוד להגדרה ותפעול;
- בדיקות עומס על קטלוג של עד 100,000 מוצרים;
- חודש של תמיכת אחריות לאחר היישום.
לוח זמנים וייעוץ
ההגדרה אורכת בין 3 ל-10 ימי עסקים בהתאם למספר הכללים וגודל הקטלוג. הגדרת תמחור סטנדרטית עולה בין $1,500 ל-$4,000. העלות מחושבת באופן אישי — אנו נעריך את הפרויקט לאחר תיאור קצר. הלקוחות שלנו בדרך כלל רואים הפחתה של 20% בעלויות ניהול התמחור, המקבילה לחיסכון של $2,000–$5,000 בשנה לקטלוג בינוני. קבלו ייעוץ — צרו קשר, ונכין מפת דרכים. הזמינו יישום — והחנות שלכם תזכה לתמחור גמיש ללא ניהול ידני.
אנו מבטיחים שהפתרון יעבוד ביציבות: הוא יעמוד בעומסי שיא ולא יגרום לשגיאות בחנות. התעודות ותיק העבודות שלנו זמינים לפי בקשה.