בקטלוג 1C-Bitrix טיפוסי, אין מנגנון מובנה למעקב אחר צפיות בקטגוריות—רק צפיות במוצרים. נתקלנו פעמים רבות במצבים שבהם לקוח ביקר בקטגוריית "מחשבים ניידים" שלוש פעמים מבלי לפתוח דגמים ספציפיים ועזב ללא רכישה. האות הזה אובד ללא טריגר. הניסיון שלנו מראה שטריגר קטגוריה מוגדר כראוי מעלה את שיעור ההמרה לעגלה ב-15–20% הודות להצעות חלופיות בזמן. יתרה מכך, הפיתוח מחזיר את עצמו תוך 2–3 חודשים דרך מכירות נוספות—ההזמנה הממוצעת בתרחישים כאלה גדלה ב-25%, ו-CPA לריטרגטינג יורד ב-30%. ההכנסה הנוספת מהטמעת הטריגר נעה בין $2k–5k לחודש עבור חנות עם מחזור של $45k–65k.
הטבלה הסטנדרטית b_catalog_viewed_product מאחסנת רק PRODUCT_ID, וקטגוריות (b_iblock_section) אינן כלולות בה. הרכיב bitrix:catalog.section אינו כותב היסטוריית צפיות. הפתרון הוא ליצור טבלת ORM מותאמת אישית ולתעד כל ביקור באמצעות בקשת AJAX.
לכידת צפיות בקטגוריות
נקודת הכניסה היא התבנית של הרכיב bitrix:catalog.section או bitrix:catalog.section.list. ב-result_modifier.php או דרך JavaScript בעת טעינת העמוד, נשלחת בקשת POST לנקודת קצה מותאמת אישית. נקודת הקצה מוסיפה רשומה לטבלה החדשה שנוצרה bl_catalog_viewed_section.
מחלקת ORM עבור הטבלה:
class ViewedSectionTable extends \Bitrix\Main\ORM\Data\DataManager { public static function getTableName(): string { return 'bl_catalog_viewed_section'; } public static function getMap(): array { return [ new \Bitrix\Main\ORM\Fields\IntegerField('ID', ['primary' => true, 'autocomplete' => true]), new \Bitrix\Main\ORM\Fields\IntegerField('FUSER_ID', ['required' => true]), new \Bitrix\Main\ORM\Fields\IntegerField('SECTION_ID', ['required' => true]), new \Bitrix\Main\ORM\Fields\StringField('SITE_ID', ['size' => 2]), new \Bitrix\Main\ORM\Fields\DatetimeField('DATE_VISIT'), ]; } } בכל כניסה—class ViewedSectionTable extends \Bitrix\Main\ORM\Data\DataManager { public static function getTableName(): string { return 'bl_catalog_viewed_section'; } public static function getMap(): array { return [ new \Bitrix\Main\ORM\Fields\IntegerField('ID', ['primary' => true, 'autocomplete' => true]), new \Bitrix\Main\ORM\Fields\IntegerField('FUSER_ID', ['required' => true]), new \Bitrix\Main\ORM\Fields\IntegerField('SECTION_ID', ['required' => true]), new \Bitrix\Main\ORM\Fields\StringField('SITE_ID', ['size' => 2]), new \Bitrix\Main\ORM\Fields\DatetimeField('DATE_VISIT'), ]; } } עם ViewedSectionTable::add() (מתוך FUSER_ID או CSaleUser::GetAnonymousUserID() בפועל).
קביעת "נטישה" של קטגוריה
הלוגיקה מורכבת יותר מאשר עבור מוצר. אפשרויות קריטריונים:
- פשוט: המשתמש צפה בקטגוריה X אך לא נווט לאף מוצר (אין רשומה ב-
USER_IDעם מוצר מאותה קטגוריה באותה תקופה). - התנהגותי: המשתמש פתח את אותה קטגוריה 2+ פעמים ב-24 שעות ללא רכישה—סימן לחוסר החלטיות.
SELECT fuser_id, section_id, COUNT(*) as visits FROM bl_catalog_viewed_section WHERE date_visit > NOW() - INTERVAL '24 hours' GROUP BY fuser_id, section_id HAVING COUNT(*) >= 2; | קריטריון | תיאור | מתי ליישם |
|---|---|---|
| פשוט | אין מעברים למוצרים | קטלוגים עם מעט SKU |
| התנהגותי | ביקורים חוזרים בקטגוריה | קטגוריות רחבות (100+ מוצרים) |
| משולב | שני התנאים + סף זמן | נישות תחרותיות מאוד |
השוואה בין הגישה שלנו לגישה הטיפוסית: שימוש בטבלת ORM מותאמת אישית במקום HL-blocks מקצר את זמן ביצוע השאילתה פי 2 הודות לאינדקסים ישירים. בקטלוג עם 30,000 קטגוריות, השאילתה רצה ב-0.3 שניות, בעוד שב-HL-block היא אורכת 0.7 שניות. זה מפחית את העומס על מסד הנתונים ומאיץ את הסוכן.
| אחסון | זמן שאילתה (30k קטגוריות) | מורכבות הגירה |
|---|---|---|
| טבלת ORM מותאמת אישית | 0.3 שניות | נמוכה |
| HL-block | 0.7 שניות | בינונית |
למה דדופליקציה היא קריטית
ללא דדופליקציה, הסוכן היה שולח הודעה בכל ריצה, מה שמוביל לספאם וביטולי מינויים. טבלת הדדופליקציה b_catalog_viewed_product עם מפתח ייחודי על SELECT fuser_id, section_id, COUNT(*) as visits FROM bl_catalog_viewed_section WHERE date_visit > NOW() - INTERVAL '24 hours' GROUP BY fuser_id, section_id HAVING COUNT(*) >= 2; מבטיחה לא יותר מטריגר אחד ליום לכל זוג. ניואנס מפתח לקטלוגים רב-רמתיים: אם משתמש צפה בתת-קטגוריה "מחשבים ניידים לגיימינג," הטריגר לא אמור לפעול פעמיים—גם על תת-הקטגוריה וגם על קטגוריית האב. פתרון: בעת חיפוש כפילויות, יש לעבור על עץ הקטגוריות דרך bl_abandoned_section_sent.
סוכן ודדופליקציה
סוכן ב-(fuser_id, section_id, DATE(sent_at)) עם מרווח של 20 דקות. הגדרת הטריגר כוללת:
- יצירת מחלקת סוכן עם המתודה
b_iblock_section.IBLOCK_SECTION_ID. - במתודה, ביצוע שאילתה ל-
b_agentעל סמך קריטריוני נטישה. - עבור כל משתמש שנמצא, קבלת 3 המוצרים המובילים של הקטגוריה דרך
checkAbandonedSections(). - בדיקת היעדר כפילות בטבלת
bl_catalog_viewed_section. - שליחת הודעה מותאמת אישית (אימייל או push) עם ההצעה.
- תיעוד השליחה בטבלת הדדופליקציה.
- רישום הסוכן עם מרווח של 20 דקות.
התאמה אישית של תוכן הטריגר
טריגר הקטגוריה צריך לכלול את 3 המוצרים המובילים מאותה קטגוריה. בחירה דרך CIBlockElement::GetList() עם פילטר על bl_abandoned_section_sent ומיון לפי מספר הזמנות מ-CIBlockElement::GetList(). אם מודול ההמלצות מופעל, ניתן לבקש הצעות אישיות לפי SECTION_ID.
מה כלול בעבודה
- יצירת טבלת
b_sale_order_basketדרך מיגרציית ORM ופריסה בסביבת staging - טיפול AJAX לכתיבת צפיות בתבנית רכיב הקטלוג
- לוגיקת סוכן לבחירת קטגוריות נטושות ודדופליקציה לפי היררכיה
- שאילתה למוצרים המובילים בקטגוריה להחדרה לתקשורת
- טבלת דדופליקציה המתחשבת במוצרים שנרכשו ובקטגוריות אב
- תיעוד ארכיטקטורה והוראות למפעילים
טעויות הגדרה טיפוסיות
- התעלמות מהיררכיית קטגוריות—הטריגר פועל בכל רמה, מה שגורם לספאם.
- אין בדיקה למוצרים שכבר נרכשו מהקטגוריה.
- ריצת סוכן תכופה מדי (פעם בדקה)—עומס על מסד הנתונים.
אנחנו צוות עם 9 שנות ניסיון בפיתוח ב-1C-Bitrix וב-Bitrix24. השלמנו מעל 50 אינטגרציות עם 1C, CRM ושערי תשלום. אנו מבטיחים יציבות טריגר תחת עומס של עד 100,000 סשנים ביום.
כדי לדון במקרה שלך, צור איתנו קשר—נעריך את הפרויקט שלך תוך יום עסקים אחד.
הזמן הגדרת טריגר turnkey, ואנו ניישם תקשורת מותאמת אישית שלא מאבדת המרות. קבל ייעוץ—נספר לך אם הטריגר מתאים לקטלוג שלך.