מדוע עגלה נטושה הולכת לאיבוד ללא הודעות דוא"ל
ב-1С-Битрикс העגלה וההזמנה הן שתי ישויות נפרדות, וזו הסיבה המרכזית לאובדנים. הקונה מוסיף מוצר, מגיע לעמוד התשלום, אך אינו מאשר את ההזמנה: הרשומה נשארת בעגלה, ואירוע ביצוע ההזמנה כלל אינו מתרחש.
מנגנון ההתראות המובנה קשור לשינוי סטטוס ההזמנה, ולכן ההודעה אינה נשלחת — לא ללקוח ולא למנהל. העגלה הנטושה מצטברת בשקט, ואובדן ההזמנות מתגלה רק בסיכום החודש, כאשר כבר מאוחר מדי להחזיר את הקונה.
לאחר מכן פועל אפקט מצטבר. ככל שיש יותר עגלות לא מושלמות, כך גדל הפער בין הביקוש האמיתי להכנסות: המוצר מונח בהזמנה מוקדמת או חוזר למלאי, המנהל מתקשר ללקוחות "חמים" באופן עיוור, והביקורים החוזרים של הקונה נותרים בלתי מורגשים.
ללא התראות על עגלה נטושה, העסק מאבד לא עסקאות חד-פעמיות, אלא את כל זרם אלה שהיו מוכנים לקנות, אך הוסחו דעתם בשלב התשלום.
מבחינה טכנית, הבעיה נפתרת לא על ידי עריכת תבנית ההודעה, אלא על ידי הגדרת מודל אירועים של החנות. יש לתעד את הרגע שבו הקונה השאיר את העגלה ללא השלמת הזמנה, לשמור את הרכב ההזמנה ואת פרטי הקשר, ולאחר מכן להפעיל לפי לוח זמנים שרשרת התראות — עם השהיה הקשורה להתנהגות הלקוח. בנפרד מוגדר אות למנהל: עליו לראות את העגלה הנטושה ברגע האובדן, ולא בדוח.
מפרקים כיצד זה נסגר: אילו אירועים יש לעקוב אחריהם, כיצד לקשר את העגלה לסטטוס ההזמנה וכיצד לבנות את ההתראות כך שיחזירו את הקונה לפני שהוא עבר למתחרים.
מה נותנת שרשרת מיילים מוגדרת
שרשרת מיילים מוגדרת הופכת סל נטוש מעסקה אבודה לעסקה נדחית. המייל הראשון נשלח 30-60 דקות לאחר שהקונה סגר את הלשונית בעמוד התשלום: ברגע זה המוצר עוד בזיכרון, וההחלטה עוד לא התקררה.
אם אין תגובה, כעבור יממה נשלח מייל שני — עם תזכורת על תוכן הסל, וכעבור שלושה ימים — שלישי, עם תמריץ עדין לחזור. רצף כזה מכסה את הסיבה העיקרית לאובדנים: לא "התחרט", אלא "הוסח דעתו".
שיעור ההחזרה תלוי לא במספר המיילים, אלא בפגיעה ברגע הנכון. קונה שקיבל תזכורת בשעות הראשונות חוזר בתדירות גבוהה noticeably יותר מזה שנכתב לו כעבור שבוע יחד עם דייג'סט מבצעים.
לכן בבסיס השרשרת — טריגר לפי אירוע, ולא תפוצה לפי לוח זמנים: המייל נשלח רק למי שהסל שלו באמת לא הושלם, ואינו משוכפל אם ההזמנה כבר בוצעה.
תזכורות ידניות — הדרך היקרה ביותר להחזיר קונה: המנהל מבזבז זמן על ייצוא סלים, בדיקת סטטוסים והודעות אישיות, וחצי מהנמענים כבר קנו במקום אחר. שרשרת אוטומטית מסירה את העבודה הזו כולה: נשאר רק פיקוח על הדוח והתערבות ממוקדת בהזמנות גדולות, שבהן שיחה טלפונית מתאימה.
מהירות התגובה כאן — величина מדידה. אנחנו מגדירים יומן שליחות ודוח המרה של השרשרת: ניתן לראות באיזה שלב הקונה חזר, כמה סלים נסגרו לאחר המייל הראשון, וכמה — לאחר השלישי.
זה מאפשר לשנות מרווחים וטקסט לפי העובדות, ולא לפי תחושות, ולהעלות בהדרגה את שיעור ההחזרה בלי גידול בעומס על המנהלים.
דרכים למעקב אחר סל נטוש
תיעוד סל נטוש מבוסס על שלושה מקורות נתונים: סטטוס הזמנה, אירוע סל וסגמנט משתמשים. הראשון פועל ברמת ביצוע ההזמנה, השני — ברמת הפעולות בקטלוג, השלישי — ברמת ההיסטוריה המצטברת של הלקוח. בחירת המקור קובעת עד כמה מוקדם נדע על רכישה שלא הושלמה ועד כמה מדויק יהיה הטריגר.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| לפי סטטוס הזמנה | נדרש תרחיש פשוט: ההזמנה נוצרה אך לא שולמה או לא אושרה | תופסת רק את אלה שהגיעו לביצוע ההזמנה; סלים ללא הזמנה נשארים מחוץ למדגם |
| לפי אירוע סל | נדרש לתעד נטישה בשלב הוספת המוצר | נדרשת הגדרת מטפלים באירועי הסל והגנה מפני התראות שווא בעת ניקוי |
| לפי סגמנט משתמשים | חשובה התאמה אישית: לקוחות קבועים, סוחרים סיטונאיים, מבקרים חדשים | דורש היסטוריה מצטברת והסכמה לעיבוד נתונים; התחלה קרה מביאה תועלת מועטה |
סטטוס הזמנה מספק את נקודת האחיזה האמינה ביותר: ההזמנה כבר במסד הנתונים, יש הרכב, סכום ופרטי קשר. אך בין "הוספת מוצר" ל"ביצוע הזמנה" אובדת עיקר הנטישות — פער זה הגישה אינה סוגרת.
אירוע סל פועל מוקדם יותר ורחב יותר: לוכדים הוספה, שינוי כמות, מחיקת פריט ועזיבת עמוד ביצוע ההזמנה. כאן חשוב להבחין בין נטישה מכוונת לבין התראות טכניות — כניסה חוזרת, רענון עמוד, ניקוי סל ידני. ללא סינון, התראות נשלחות למי שלא נטש דבר, והאמון בדיוור יורד.
סגמנט משתמשים מוסיף הקשר: ללקוח אחד די בתזכורת, לאחר — הצעת חלופה, ולשלישי כלל אין טעם לכתוב. בפועל משלבים בין הגישות — סטטוס הזמנה כבסיס, אירוע סל כאות מוקדם, סגמנט כמסנן נמענים. בהמשך נבחן כיצד זה מתחבר ללוגיקת התראות אחודה.
שלבי הגדרת התראות
הגדרת התראות על עגלה נטושה אינה "סימון תיבת סימון בהגדרות", אלא בניית שרשרת מאירוע באתר ועד להודעה שנשלחת לאדם הנכון בזמן הנכון. מתחילים בביקורת: בודקים אילו אירועים כבר נרשמים במערכת, כיצד נשמרות העגלות והאם הן מקושרות למשתמש או רק לסשן.
לעתים קרובות מתברר שחלק מהנתונים הולכים לאיבוד כאשר אורח יוצא — זה הדבר הראשון שצריך לסגור לפני הפעלת הדיוור.
בהמשך מתכננים סכימת טריגרים: כמה הודעות, באילו מרווחים, באילו תנאים השרשרת נעצרת (ההזמנה בוצעה, המוצר הוסר, הלקוח ביטל את המנוי). בנפרד מפרטים כיצד ההתראות מתנהגות עבור עגלות מאומתות ועגלות אורחים — ההיגיון שונה.
- ביקורת אירועים — ספירת מלאי של מה שכבר נרשם באתר: הוספה לעגלה, שינוי בהרכב, ביצוע הזמנה, כניסה לאזור האישי. מגדירים אילו נתונים חסרים לטריגר תקין.
- סכימת טריגרים — מתאמים את מספר ההודעות בשרשרת, המרווחים ביניהן, תנאי העצירה והעדיפויות. מתעדים בטבלה "אירוע → פעולה → הודעה".
- תבניות הודעות — מכינים טקסטים ותצוגה: נושא, תוכן העגלה, כפתור החזרה, קישור לביטול מנוי. מתחשבים באופן שבו ההודעה מוצגת בתוכנות דואר ובמכשירים ניידים.
- הגדרת שליחה — מחברים שירות דואר, מגדירים דומיין וחתימה כדי שההודעות לא יגיעו לספאם. בודקים שהדיוור אינו מתנגש עם התראות טרנזקציוניות של החנות.
- שליחת בדיקה — מריצים תרחיש מלא: מדמים עגלה נטושה, בודקים כל הודעה בשרשרת, תנאי עצירה ונכונות הנתונים בתבנית.
- הפעלה ומעקב — מפעילים את השרשרת על תעבורה אמיתית, עוקבים אחר מסירת ההודעות ותגובת הלקוחות בימים הראשונים.
- מסירה — מראים לצוות הלקוח היכן לשנות טקסטים, מרווחים ותנאים, משאירים תיעוד של סכימת הטריגרים והוראות לעריכות.
כל שלב מתאמים לפני המעבר לשלב הבא — כך בסופו של דבר מתקבלת שרשרת עובדת, ולא אוסף הודעות שנשלחות לאנשים הלא נכונים ובזמן הלא נכון.
מה הלקוח מקבל לידיו
בסיום העבודה — לא "הגדרנו והלכנו", אלא ערכה שהצוות שלכם יוכל ללוות ולפתח בלעדינו. כל מה שקשור לסל נטוש מתועד בקונפיגורציה ובתיעוד: טריגרים, תבניות, סגמנטים וסדר העבודה איתם.
- קונפיגורציית טריגרים: תנאי הפעלה לפי אירועי הסל, השהיות בין הודעות בשרשרת, מגבלות על שליחות חוזרות ללקוח אחד וכללי עצירה בעת ביצוע הזמנה.
- תבניות הודעות: טקסטים ועיצוב לכל שלב בשרשרת, משתני השמה (מוצרים, סכומים, קישור לחזרה לסל), דוגמאות בדיקה לבדיקה לפני ההפעלה.
- כללי סגמנטציה: חלוקה לפי סוג לקוח, הרכב הסל ופעילות — למי ובאיזו תדירות נשלחת תזכורת, את מי מחריגים מהתפוצה.
- תרשים לוגיקה: כיצד קשורים אירועי הסל, תור השליחה וסטטוסי ההזמנה — כדי שבעת שינויים בקטלוג או בתהליך ההזמנה יהיה ברור היכן לתקן.
- תיעוד: תיאור כל ההגדרות, ייעוד כל תבנית וסגמנט, רשימת נקודות האינטגרציה עם שירות הדואר ומודול ההזמנות.
- נוהל ליווי: מי ומתי בודק את מסירת ההודעות, כיצד להגיב להסרות מדיוור ותלונות, כיצד להוסיף שלב חדש לשרשרת או לשנות טקסט.
- הרשאות ומסירה: ההגדרות נשארות במערכת שלכם, אנו מעבירים הרשאות ומסבירים בקצרה לאחראי כיצד הכל בנוי.
בנפרד אנו מסכמים אילו מדדים יש לבחון לאחר ההפעלה — שיעור החזרות לסל ופתיחות ההודעות — כדי שתוכלו להעריך את האפקט ולתקן את השרשרת בזמן. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית עבודה.
מקרה בוחן: כיצד גדל שיעור הסלים המוחזרים
הלקוח — חנות מקוונת למוצרי אלקטרוניקה על 1С-Битрикс עם קטלוג של כמה אלפי פריטים. את הסל נטשו בשלב בחירת המשלוח: הקונה הוסיף מוצר, הגיע לתהליך התשלום וסגר את הלשונית.
התראות לא היו כלל — מנהלים התקשרו לסלים הנטושים ידנית, לפי ייצוא פעם ביום, והספיקו להתקשר לחלק מהלקוחות רק לאחר שכבר רכשו במקום אחר.
מה היה לפני
שיעור הסלים המוחזרים עמד ברמת שגיאת מדידה סטטיסטית, וזמן התגובה נמדד בימים. מנהל השקיע כמה דקות בכל פנייה, אך כיסה רק חלק קטן מהסלים הנטושים — השאר просто התקררו. מנהל התחום לא ראה באיזה שלב בתהליך התשלום אנשים נושרים לרוב: הנתונים לא נאספו.
מה שינו
הגדירו מודל אירועים בצד החנות: המערכת מתעדת את עצם נטישת הסל, הרכב ההזמנה והשלב שבו הקונה עצר. לאחר מכן מופעלת שרשרת מיילים — הראשון נשלח לאחר פרק זמן קצר מרגע היציאה מהאתר, השני לאחר כמה שעות, השלישי למחרת. התבניות נבנות מנתוני הסל: תמונת המוצר, המחיר, קישור לחזרה לתהליך התשלום בקליק אחד.
מה נהיה
זמן התגובה הצטמצם מימים לדקות — המייל נשלח אוטומטית, ללא מעורבות המנהל. שיעור הסלים המוחזרים גדל פי כמה: חלק מהקונים חוזרים דרך הקישור שבמייל ומשלימים את ההזמנה.
התזכורות הידניות כמעט נעלמו לחלוטין — מנהלים מתחברים רק לאותם סלים שבהם הופעלה השרשרת והלקוח פתח את המייל, אך לא השלים את הרכישה.
בנפרד הגדירו דיווח: ניתן לראות באיזה שלב בתהליך התשלום אובדים הכי הרבה סלים ואיזה מייל בשרשרת מניב החזרה. זה איפשר לסדר מחדש את שדות הטופס ולהסיר שלב מיותר — ההמרה בתהליך התשלום גדלה עוד לפני שהתפוצה הופעלה.
במה שונה מייל על עגלה נטושה ממייל על הזמנה?
מייל על הזמנה הוא טרנזקציוני: הלקוח עצמו ביצע פעולה, המערכת מתעדת את העובדה ושולחת אישור. מייל על עגלה נטושה הוא ריאקטיבציה: האירוע לא הושלם, והמייל צריך להחזיר את האדם לשלב שהופסק. מכאן נבדל כל השאר.
טריגר. עבור הזמנה זהו עובדת התשלום או ביצוע ההזמנה — אירוע חד-משמעי ומיידי. עבור עגלה נטושה הטריגר מורכב: המוצר נוסף, אך ביצוע ההזמנה לא הושלם בתוך חלון זמן מוגדר (בדרך כלל בין 30 דקות למספר שעות).
החלון מוגדר בנפרד עבור משתמשים מזוהים ואורחים: לאורח אין סשן עבור מייל השלמה, ולכן או שמבקשים ממנו להתחבר, או ששולחים לו מייל עם קישור לעגלה משוחזרת לפי מזהה.
תוכן. במייל על הזמנה — הרכב, סכומים, סטטוס, מספר למעקב. במייל על עגלה נטושה — אותם פריטים, אך עם דגש על כך שהם עדיין זמינים, ועם קישור ישיר לחזרה לביצוע ההזמנה. אם העגלה מכילה מוצרים עם מלאי מוגבל, כדאי להראות שהפריט נשמר לזמן קצר — זהו טיעון הוגן, לא לחץ.
רגע השליחה והתדירות. מייל הזמנה נשלח פעם אחת, מיד. מייל על עגלה נטושה — סדרה: הראשון אחרי שעה-שעתיים מהנטישה, השני אחרי יממה, השלישי אחרי כמה ימים. כל אחד קצר מקודמו ומשנה את העילה.
המפתח — השרשרת נעצרת אוטומטית ברגע שההזמנה בוצעה או שהלקוח הסיר את עצמו מהרשימה, אחרת המיילים מגיעים על גבי הזמנה שכבר שולמה והורסים את האמון.
מבחינה טכנית מדובר בשני מנגנונים שונים: תבנית טרנזקציונית מופעלת על אירוע ביצוע ההזמנה, ושרשרת העגלה הנטושה — על משימה מושהית עם בדיקת מצב העגלה לפני כל שליחה. מפרטים כיצד זה מוגדר ב-1С-Битрикс ללא כפילויות והפעלות שווא.
ספקות טכניים נפוצים
לפני הפעלת התרחיש, לקוחות בדרך כלל שואלים שלוש שאלות: האם זה ישבור את ההגדרות הנוכחיות, האם העומס על השרת יגדל, וכיצד ניתן לוודא שהמיילים אכן נשלחים. אנו מנתחים כל נושא לגופו.
האם זה תואם להגדרות הנוכחיות של החנות ולתבניות המייל?
כן. התרחיש פועל מעל המנגנונים הסטנדרטיים: סוכן לפי לוח זמנים בוחר עגלות שלא הושלמו במרווח זמן מוגדר, ומכניס את המייל לתור השליחה. תבניות המייל הקיימות, הנושאים והחתימות נשמרים — אנו מוסיפים תבנית נפרדת עבור עגלה נטושה, מבלי לגעת במיילים העסקיים על הזמנה, הרשמה ותשלום.
אם החנות כבר שולחת מיילים דרך שירות דיוור חיצוני, אנו מחברים אותו כתעבורה, כדי לא ליצור נקודת כשל שנייה.
האם העומס על השרת יגדל באלפי עגלות?
השליפה מתבצעת במנות לפי אינדקס תאריך השינוי של העגלה, ולא בסריקה מלאה של טבלאות — בעשרות אלפי רשומות אלו שאילתות בודדות אחת למרווח זמן, ולא עומס מתמשך. השליחה מועברת לתור ומעובדת במנות, ולכן שיא המיילים אינו חופף לשיא ההזמנות.
בפרויקטים עם תנועה גבוהה, אנו תחילה מבצעים מדידות על עותק של מסד הנתונים, ורק לאחר מכן מפעילים את התרחיש בסביבת הייצור.
כיצד בודקים שהמיילים נשלחים ולא נכנסים לספאם?
הבדיקה מתבצעת על עגלות בדיקה: יוצרים עגלה נטושה, ממתינים להפעלת הכלל ובודקים את עצם המסירה, את תקינות החלפת המוצרים ואת הקישור לחזרה להשלמת ההזמנה.
בנפרד אנו בודקים את כותרות המייל ואת דומיין השולח — ללא הגדרה תקינה של דומיין המייל, חלק מהמיילים נכנסים לספאם, וזה נראה רק בלוגים של השליחה, ולא לפי העובדה ש"המייל נשלח". הגדרות המרווחים, מספר התזכורות ותנאי ההחרגה מתועדים במסמכים, כדי שניתן יהיה לשנותם ללא עריכת קוד.
מה יקרה אם הלקוח יחזור וישלים הזמנה?
התרחיש מסיר את העגלה מתור התזכורות מיד לאחר השלמת ההזמנה או ההתחברות עם אותו מזהה — מייל חוזר לא יישלח. במידת הצורך, אנו מוסיפים החרגות לפי קטגוריות מוצרים, סכום עגלה מינימלי וסטטוס הלקוח, כדי לא להטריד את אלה שממילא יחזרו.
בואו נדון במשימה שלכם
לפני שמתחילים, כדאי להבין איך אצלכם בנוי כיום החשבונאות של עגלות נטושות: האם עצם ההוספה לעגלה נכתב למסד הנתונים, האם יש קישור למשתמש מאומת או רק לסשן, והאם שליחת המיילים מוגדרת דרך שירות דואר או ישירות מהשרת. מכך תלוי אילו נתונים בכלל זמינים לתרחיש וכמה זמן ייקח להגדיר.
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים סט מינימלי של נתוני פתיחה:
- כיצד כיום נרשמת הוספת מוצר לעגלה והניקוי — האם יש היסטוריה לפי סשנים ומשתמשים.
- אילו ערוצי התראות בעדיפות: מייל, SMS, מסנג'ר — ודרך איזה שירות שליחה הם עוברים.
- האם יש הסכמה של לקוחות לדיוור שיווקי וכיצד היא נשמרת במסד הנתונים.
- לפי איזה אירוע אנחנו מחשיבים עגלה כנטושה: לפי זמן חוסר פעילות, לפי עזיבת האתר, לפי שינוי סטטוס הזמנה.
- אילו תבניות מייל כבר בשימוש והאם צריך לעשות בהן שימוש חוזר או ליצור חדשות.
- מי מצד הלקוח מקבל את התוצאה וכיצד אנחנו בודקים שהמיילים מגיעים ולא נופלים לספאם.
- האם יש סביבת בדיקה שבה אפשר להריץ את התרחיש בלי סיכון ללקוחות פעילים.
מכאן העבודה מתנהלת בשלבים ברורים: מפרקים את הלוגיקה הנוכחית של העגלה, מתאמים את תנאי ההפעלה ותדירות המיילים, מכינים תבניות, מגדירים שליחה ותור, בודקים בתרחישי בדיקה, מוציאים לפעולה ומסתכלים על המדדים הראשונים של חזרה.
הבהרות תוך כדי הן חלק נורמלי מהתהליך: ככל שפרטים על הסכמות, אזורי זמן ושליחות חוזרות יצופו מוקדם יותר, כך יהיו פחות תיקונים אחרי ההשקה.
תארו את המשימה בצורה חופשית — מה כבר עובד, מה מפריע ואיזו תוצאה נדרשת. נחזור עם הערכת לוחות זמנים ותוכנית עבודה לפי המעגל שלכם.