בעיה: כל הזמנה שלישית אובדת
שיעור נטישת עגלות הקנייה הממוצע במסחר אלקטרוני הוא 65–70%. מתוך 1000 סשנים עם פריטים שנוספו, 650–700 הזמנות לא הושלמו. עם ערך עגלה ממוצע של $40, מדובר בהפסד של עד $28,000 בהכנסות. החדשות הטובות: ניתן לשחזר עד 15% מההזמנות הללו באמצעות מעקב נכון והודעות אוטומטיות. אנו מקימים את המחזור המלא: מזיהוי בצד השרת ועד לדוחות המרה. מניסיוננו, הפתרון מחזיר את עצמו תוך 2–3 חודשים. אנו מבטיחים שחזור של עד 15% מההזמנות האבודות אם יבוצעו ההמלצות שלנו.
מדוע לקוחות נוטשים עגלות?
הסיבות העיקריות הן עלויות משלוח בלתי צפויות, טופס הזמנה מסובך, או היעדר אמצעי תשלום נוח. ללא נתונים, לא תדעו את הסיבה. מעקב אחר עגלות נטושות נותן לכם מספרים מדויקים: מי, מתי, ועם איזה מוצר עזב. אנו משתמשים בשילוב של שיטות בצד השרת ואירועים בצד הלקוח לנתונים מלאים. בנוסף, אנו מנתחים נקודות נטישה באמצעות אירועי UX.
כיצד להקים מעקב בצד השרת ב-Bitrix?
נתוני העגלה נמצאים בטבלאות b_sale_fuser (משתמש וירטואלי) ו-b_sale_basket (פריטים). כדי למצוא עגלות נטושות, יש לשאול את \Bitrix\Sale\BasketTable. הקוד שלהלן בודק עגלות שלא עודכנו במשך יותר משעה, ואם קיים משתמש מורשה, דוחף משימה לתור ההודעות. לפי תיעוד מודול המכירות, גישה זו מומלצת לעומס מינימלי.
<?php $cutoffTime = new \Bitrix\Main\Type\DateTime(); $cutoffTime->add('-1 hour'); $abandonedFusers = \Bitrix\Sale\BasketTable::getList([ 'filter' => [ '<DATE_UPDATE' => $cutoffTime, '=ORDER_ID' => false, ], 'group' => ['FUSER_ID'], 'select' => ['FUSER_ID'], ])->fetchAll(); foreach ($abandonedFusers as $row) { $fuser = \Bitrix\Sale\FuserTable::getList([ 'filter' => ['=ID' => $row['FUSER_ID']], 'select' => ['USER_ID', 'DATE_UPDATE'], ])->fetch(); if (!$fuser || !$fuser['USER_ID']) continue; $user = \Bitrix\Main\UserTable::getById($fuser['USER_ID'])->fetch(); $email = $user['EMAIL'] ?? ''; if (!$email) continue; AbandonedCartQueue::push($fuser['USER_ID'], $row['FUSER_ID']); } לאחר קבלת FUSER_ID, אנו בודקים אם המשתמש מורשה (USER_ID לא ריק). אם כן, מקבלים את הדוא"ל ודוחפים את המשימה לתור.
פרטי הגדרת הסוכן
הפעל את הסוכן כל 30–60 דקות כדי לא לפספס עגלות נטושות.
// Агент (Настройки -> Агенты) function checkAbandonedCarts(): string { AbandonedCartService::processNew(); return __FUNCTION__ . '();'; } <?php $cutoffTime = new \Bitrix\Main\Type\DateTime(); $cutoffTime->add('-1 hour'); $abandonedFusers = \Bitrix\Sale\BasketTable::getList([ 'filter' => [ '<DATE_UPDATE' => $cutoffTime, '=ORDER_ID' => false, ], 'group' => ['FUSER_ID'], 'select' => ['FUSER_ID'], ])->fetchAll(); foreach ($abandonedFusers as $row) { $fuser = \Bitrix\Sale\FuserTable::getList([ 'filter' => ['=ID' => $row['FUSER_ID']], 'select' => ['USER_ID', 'DATE_UPDATE'], ])->fetch(); if (!$fuser || !$fuser['USER_ID']) continue; $user = \Bitrix\Main\UserTable::getById($fuser['USER_ID'])->fetch(); $email = $user['EMAIL'] ?? ''; if (!$email) continue; AbandonedCartQueue::push($fuser['USER_ID'], $row['FUSER_ID']); } הוא המחלקה שלך שבוחרת עגלות נטושות חדשות (לא מסומנות כמעובדות) וכותבת אותן לתור ההודעות.
לאופטימיזציה של ביצועים, השתמש באינדקסים על // Агент (Настройки -> Агенты) function checkAbandonedCarts(): string { AbandonedCartService::processNew(); return __FUNCTION__ . '();'; } ו-AbandonedCartService::processNew() ב-DATE_UPDATE, ועל ORDER_ID ב-b_sale_basket. זה מפחית עומס בעבודה עם קטלוגים גדולים.
אילו נתונים לנתח בדוח?
לאחר מספר שבועות, יהיו לך נתונים: מספר העגלות שזוהו, ההודעות שנשלחו, וההזמנות ששוחזרו. שאילתת SQL פשוטה מראה את המגמה.
SELECT DATE(detected_at) AS date, COUNT(*) AS detected, SUM(CASE WHEN status = 'recovered' THEN 1 ELSE 0 END) AS recovered, ROUND(SUM(CASE WHEN status = 'recovered' THEN 1 ELSE 0 END) * 100.0 / COUNT(*), 1) AS recovery_rate FROM local_abandoned_cart GROUP BY DATE(detected_at) ORDER BY date DESC; לדוגמה, עם 1000 עגלות שזוהו ו-150 הזמנות ששוחזרו בערך הזמנה ממוצע של $40, ההכנסה הנוספת היא $6,000.
השוואה בין מעקב בצד השרת למעקב בצד הלקוח
זיהוי בצד השרת מוצא פי 1.2–1.3 יותר עגלות נטושות מאשר בצד הלקוח, כפי שאושר בפרויקטים שלנו. אבל אירועים בצד הלקוח עוזרים לנתח UX ונקודות נטישה.
| קריטריון | צד השרת | צד הלקוח |
|---|---|---|
| דיוק | גבוה (מבוסס על מסד נתונים) | בינוני (תלוי בביצוע JS) |
| זיהוי | כל העגלות הנטושות | רק במהלך סשן פעיל |
| עומס נוסף | מינימלי (שאילתות מסד נתונים) | תלוי בנפח האירועים |
| שימוש בדוחות | כן, לשחזור | כן, לניתוח UX |
מה כלול
| תוצר | תיאור |
|---|---|
| הגדרת סוכן לחיפוש עגלות נטושות | הגדרת מרווח, מסננים, תור הודעות |
| טבלת סטטוס לכל עגלה | רישום תאריך זיהוי, הודעות שנשלחו, סטטוס שחזור |
| אינטגרציה עם GA4 ו-Yandex Metrica | שליחת אירועים על הוספה לעגלה ותחילת תשלום |
| דוח המרת עגלות נטושות | סטטיסטיקה יומית עם מדדי זיהוי, שליחה ושחזור |
| תיעוד והדרכת מנהל | תיאור פעולת המערכת והוראות הגדרה |
תהליך היישום: איך אנחנו עובדים
- ביקורת על יישום העגלה הנוכחי וזיהוי צווארי בקבוק.
- הקמת מעקב בצד השרת: שאילתות, סוכן, טבלת סטטוס.
- אינטגרציה של אירועים בצד הלקוח (GA4, Yandex Metrica).
- פיתוח דוח המרת עגלות נטושות.
- מסירת תיעוד והדרכת המנהל שלך.
לוח זמנים משוער
| שלב | זמן |
|---|---|
| מעקב בצד השרת + סוכן | 1–2 ימים |
| אירועים בצד הלקוח | 4 שעות |
| טבלת סטטוס ודיווח | יום אחד |
מחזור היישום המלא אורך עד 3 ימים. תקבל את הדוח הראשון שבוע לאחר ההתחלה. צור קשר להערכה ראשונית של הפרויקט שלך. הזמן את היישום וראה את המערכת מחזירה את עצמה על ידי שחזור של עד 15% מההזמנות האבודות.
הגישה שלנו
כל משימה דורשת ניתוח אישי ותכנון קפדני. איננו משתמשים בפתרונות תבניתיים — כל פרויקט מותאם לדרישות הספציפיות ולתשתית הקיימת. לצוות שלנו ניסיון עם פרויקטים בקנה מידה שונים: מחנויות קטנות ועד פלטפורמות בעומס גבוה עם מיליוני פעולות ביום.
אחריות ותמיכה
אנו מספקים אחריות ל-12 חודשים על העבודה שבוצעה. בתקופה זו, אנו מתקנים כל בעיה ללא עלות. לאחר סיום הפרויקט, אנו מספקים תיעוד מלא והדרכה לצוות שלך. תמיכה טכנית זמינה למשך 30 יום לאחר ההשקה — נעזור לפתור כל שאלה.