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

ריק בכרטיס מוצר או בלוק "דומה לפי מאפיינים" – ההמרה צונחת. הקונה לא רואה ערך: מוצרים עם מאפיינים דומים לא משקפים התנהגות אמיתית. בלוק הרכישה המשותפת פותר זאת אחרת – הוא מסתמך על סטטיסטיקות הזמנות. גישה זו מניבה פי 2–3 יותר קליקים ומגדילה את הסל הממוצע ב-15–30%. יישמנו זאת על 1C-Bitrix בעשרות פרויקטים – מקטלוגים של 500 מוצרים ועד מרקטפלייסים עם מיליון פריטים. הפתרון מתאים לכל מהדורה: 'Small Business', 'Business' או 'Enterprise'. רוצים להעריך את ההשפעה על הקטלוג שלכם? צרו קשר – נראה לכם הדגמה.

איך עובד הבלוק "לקוחות שקנו זאת קנו גם"?

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

מקורות נתונים ו-SQL

המידע העיקרי נמצא בטבלאות b_sale_order (הזמנות) ו-b_sale_basket (פריטים). השאילתה אוספת מוצרים שנרכשו יחד ב-90 הימים האחרונים – זה מספיק כדי ששינויי המבחר ישתקפו במהירות.

SELECT b2.product_id AS recommended_id, COUNT(DISTINCT b2.order_id) AS co_purchase_count FROM b_sale_basket b1 JOIN b_sale_order o ON b1.order_id = o.id AND o.canceled = 'N' AND o.status_id NOT IN ('F') JOIN b_sale_basket b2 ON b1.order_id = b2.order_id AND b2.product_id != b1.product_id AND b2.product_id IS NOT NULL WHERE b1.product_id = :productId AND o.date_insert >= DATE_SUB(NOW(), INTERVAL 90 DAY) GROUP BY b2.product_id HAVING co_purchase_count >= 3 ORDER BY co_purchase_count DESC LIMIT 20; 

התוצאות נשמרות בטבלה נפרדת SELECT b2.product_id AS recommended_id, COUNT(DISTINCT b2.order_id) AS co_purchase_count FROM b_sale_basket b1 JOIN b_sale_order o ON b1.order_id = o.id AND o.canceled = 'N' AND o.status_id NOT IN ('F') JOIN b_sale_basket b2 ON b1.order_id = b2.order_id AND b2.product_id != b1.product_id AND b2.product_id IS NOT NULL WHERE b1.product_id = :productId AND o.date_insert >= DATE_SUB(NOW(), INTERVAL 90 DAY) GROUP BY b2.product_id HAVING co_purchase_count >= 3 ORDER BY co_purchase_count DESC LIMIT 20; עם מפתח ראשי (product_id, recommended_id). זה מאפשר חיפושים מהירים ללא שאילתות כבדות בכל פעם. פרטים נוספים על מבנה הטבלאות של מודול המכירות נמצאים בתיעוד Bitrix.

חישוב מוקדם באמצעות סוכן

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

// Агент в local/php_interface/init.php function RecalcCoPurchasesAgent(): string { $topProducts = getTopSellingProducts(500); foreach ($topProducts as $productId) { $recs = calcCoPurchases($productId); saveToCoPurchases($productId, $recs); } return 'RecalcCoPurchasesAgent();'; } 

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

רכיב עם מטמון מתויג

פלט הבלוק מיושם באמצעות הרכיב custom_co_purchases. הרכיב משתמש במטמון מתויג כך שדפי כרטיסי המוצר לא מחושבים מחדש בכל ביקור. המטמון מקושר לתג // Агент в local/php_interface/init.php function RecalcCoPurchasesAgent(): string { $topProducts = getTopSellingProducts(500); foreach ($topProducts as $productId) { $recs = calcCoPurchases($productId); saveToCoPurchases($productId, $recs); } return 'RecalcCoPurchasesAgent();'; } , מה שמאפשר פסילה כאשר ההזמנות משתנות.

// component.php if (!\Bitrix\Main\Loader::includeModule('iblock') || !\Bitrix\Main\Loader::includeModule('catalog')) { return; } $productId = (int)$arParams['PRODUCT_ID']; $limit = (int)($arParams['LIMIT'] ?? 8); $cache = \Bitrix\Main\Data\Cache::createInstance(); if ($cache->initCache(3600, "co_purchases_{$productId}_{$limit}", '/co_purchases')) { $arResult = $cache->getVars(); } elseif ($cache->startDataCache()) { $cache->registerTag('co_purchases'); $recommendedIds = getFromCoPurchasesTable($productId, $limit); $arResult = getProductsByIds($recommendedIds); $cache->endDataCache($arResult); } $this->IncludeComponentTemplate(); 

סינון והתחלה קרה

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

function getRecommendations(int $productId, int $limit): array { $coPurchases = getFromCoPurchasesTable($productId, $limit); if (count($coPurchases) >= $limit) { return $coPurchases; } $needed = $limit - count($coPurchases); $exclude = array_merge([$productId], $coPurchases); $categoryFill = getSameCategoryProducts($productId, $needed, $exclude); return array_merge($coPurchases, $categoryFill); } 

בלוק עגלת קניות

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

$basketItems = \Bitrix\Sale\Basket::loadItemsForFUser(\Bitrix\Sale\Fuser::getId()); $basketIds = []; foreach ($basketItems as $item) { $basketIds[] = $item->getProductId(); } $allRecs = []; foreach ($basketIds as $id) { $recs = getFromCoPurchasesTable($id, 20); foreach ($recs as $rec) { $allRecs[$rec['recommended_id']] = ($allRecs[$rec['recommended_id']] ?? 0) + $rec['score']; } } foreach ($basketIds as $id) unset($allRecs[$id]); arsort($allRecs); $topRecs = array_slice(array_keys($allRecs), 0, 8); 

מדוע רכישות משותפות יעילות יותר ממוצרים דומים?

השוואת גישות בטבלה למטה. בלוק הרכישה המשותפת מסתמך על התנהגות קונים אמיתית, לא על מאפיינים פורמליים. אנו מבטיחים פעילות יציבה בכל גרסת Bitrix (החל מ-17.0) ומספקים אחריות לקוד.

אנו ממליצים להריץ מבחן A/B: הציגו רכישות משותפות לחצי מהתנועה והמלצות סטנדרטיות לחצי השני. ב-80% מהפרויקטים, בלוק הרכישה המשותפת מנצח עם CTR גבוה ב-30-50%.

מה כלול בעבודה?

1. ניתוח הזמנות קיימות ומבנה נתונים
2. שאילתת SQL מותאמת לנפח שלכם
3. פיתוח סוכן חישוב מוקדם
4. רכיב עם מטמון וחלופה
5. אינטגרציה של בלוק עגלת הקניות
6. תיעוד פריסה ותצורה
7. ייעוץ לאחר השחרור

לוח זמנים לפיתוח

דוגמה לחישוב: עם עלייה של 20% בסל הממוצע, ההכנסה הנוספת מכל 1000 מבקרים גדלה משמעותית. במשך שנה עם תנועה של 10,000 מבקרים בחודש, זה מניב גידול ניכר.

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