יש הוספות לסל אבל אין רכישות: איך מאבחנים איפה המכירה נתקעת?

המשפט ״יש לנו הוספות לסל, אבל אין רכישות״ נשמע כמו אבחנה. בפועל, הוא מתאר רק שתי נקודות בקצה של מסלול ארוך. יכול להיות שהגולשים מוסיפים מוצר, פותחים סל ולא מצליחים לעבור לקופה. יכול להיות שה־checkout נפתח, אבל עלות המשלוח מתגלה מאוחר מדי. יכול להיות שהתשלום נכשל. ויכול להיות שהרכישות קיימות במערכת החנות, אך אירוע purchase לא מגיע ל־GA4.

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

שלוש השערות שצריך לבדוק לפני שמשנים

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

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

מפת הדליפה: איפה בדיוק הרכישה נתקעת?

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

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

קודם מאמתים את חוזה המדידה

Google מגדירה ב־GA4 אירועים נפוצים למדידת מסחר: צפייה בפריט, הוספה או הסרה מסל, צפייה בסל, התחלת checkout, הוספת פרטי משלוח, הוספת פרטי תשלום ורכישה. האירועים כוללים מערך items, ובאירוע רכישה גם transaction_id. התיעוד הרשמי של Google למדידת איקומרס ב־GA4 מפרט את השמות והפרמטרים.

המשמעות המעשית היא שאירוע צריך לתאר פעולה שהצליחה, לא כוונה ללחוץ. אם add_to_cart נשלח מיד עם הלחיצה, לפני שהווריאנט נבחר או לפני שהשרת אישר את ההוספה, הנתון עלול להיות מנופח. אם purchase נשלח בדף תודה שניתן לרענן, אותה הזמנה עלולה להיספר שוב בלי מזהה עסקה שמונע כפילויות.

עברו על מסלול אחד מלא ובדקו:

• האם כל אירוע נשלח בנקודה שבה הפעולה באמת הצליחה.
• האם אותו item_id, מחיר, מטבע וכמות ממשיכים בין הסל, ה־checkout והרכישה.
• האם כפתור מהיר, סל צדדי, שינוי כמות והסרה משתמשים באותו חוזה.
• האם אפליקציה, Tag Manager וקוד Theme עלולים לשלוח את אותו אירוע במקביל.
• האם אירוע purchase כולל מזהה עסקה יציב ואינו נשלח בכל רענון.

רק אחרי שהבסיס אמין אפשר להשוות שיעורי מעבר. מי שרוצה להעמיק בהגדרת האירועים יכול להשתמש ב־מדריך אירועי איקומרס ב־GA4; במאמר הזה האירועים משמשים ככלי אבחון של המשפך, לא כרשימת הטמעה בפני עצמה.

מפרידים בין מה ש־GA4 אומר לבין מה שנמכר

הבדיקה החשובה ביותר היא פיוס מול מערכת המסחר. אם ב־GA4 מופיעות הוספות רבות אך במערכת ההזמנות אין רכישות, זה עדיין לא מוכיח שהלקוחות נוטשים. ייתכן שהרכישה נרשמת בספק התשלום או במערכת החנות אך אינה חוזרת לדף תודה, שההסכמה למדידה ניתנת בשלב מאוחר, או שאירוע הרכישה חסר במסלול חיצוני.

השוו באותו טווח תאריכים ובאותה הגדרת אזור זמן:

1. מספר הזמנות במערכת המסחר.
2. מספר אירועי purchase עם transaction_id ייחודי.
3. ערך ההזמנה והמטבע בשתי המערכות.
4. מספר עסקאות שבוטלו או הוחזרו, כדי לא לבלבל בין מכירה לבין הכנסה נטו.
5. מסלול התשלום: ספק פנימי, ספק חיצוני, ארנק דיגיטלי או תשלום טלפוני.

אם קיימות הזמנות במערכת החנות אבל חסרים אירועי רכישה, מטפלים במדידה לפני שמחליטים שה־checkout לא ממיר. אם גם המערכת העסקית וגם הבדיקה הידנית מצביעות על כשל, עוברים לאבחון UX, תפעול ותשלום. שתי המסקנות דורשות פעולה שונה.

אבחון לפי השלב שבו יש נפילה

מהוספה לסל לצפייה בסל

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

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

מהסל להתחלת checkout

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

עלות משלוח אינה תמיד ״בעיית checkout״ בלבד. כאשר אי אפשר להציג מחיר מדויק לפני כתובת, הציגו לפחות את התנאי, האזור או טווח הזמן הידוע, בלי להבטיח מה שאי אפשר לקיים. מחקרי השימושיות של Baymard על נטישת סל וקופה ממחישים מדוע עלויות, זמן אספקה, אמון ומורכבות טופס הם חלק מאותה החלטת רכישה. ודאו שהניסוח בסל, בדף המוצר ובקופה אינו סותר.

מהתחלת checkout לפרטי משלוח

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

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

מפרטי תשלום לרכישה

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

ב־Shopify, תיעוד הזמנת בדיקה ממליץ לבצע עסקת בדיקה כדי לוודא את תהליך הקופה, המלאי, המשלוח, ההתראות והמסים. בתיעוד ה־checkouts הנטושים Shopify מתארת גם צפייה באירועי תשלום שעשויים לעזור לזהות כרטיס שנדחה, שגיאה טכנית, בעיית כתובת, מלאי או חזרת ספק תשלום חיצוני. זה אינו תחליף לבדיקה בחנויות אחרות, אך הוא מדגים מדוע לא נכון לסווג כל נשירה כ״חוסר אמון״.

מובייל אינו רק מסך קטן

פער במובייל יכול להיווצר בכל שלב: סל צדדי שנפתח מחוץ ל־viewport, מקלדת שמסתירה הודעת שגיאה, שדה כתובת שקופץ בעת autofill, כפתור תשלום שנמצא מתחת ל־sticky bar או מעבר לספק חיצוני שמאבד את ההקשר. לכן לא מספיק לפתוח את האתר בחלון צר בדסקטופ.

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

סולם הראיות ותעדוף התיקון

כדי להימנע מוויכוח של דעות, מדרגים כל חשד לפי ארבע שכבות ראיה:

המלצה טובה דורשת לפחות נתון אחד ודרך לבדוק אותו. לפני שינוי יקר, רצוי להוסיף שחזור או ראיית מערכת. לדוגמה, שיעור נמוך של purchase במובייל הוא אות. הוא הופך להשערה חזקה יותר אם רכישת בדיקה נכשלת ב־Safari או אם יש פער בין הזמנות לבין אירועים.

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

דוגמה היפותטית: הבעיה לא הייתה בעיצוב הסל

נניח חנות שבה נרשמו בתקופה מסוימת 1,200 אירועי add_to_cart, 820 אירועי begin_checkout ורק 96 אירועי purchase. המספרים בדוגמה היפותטיים ואינם נתוני לקוח. היחס בין הוספה להתחלת checkout נראה סביר יותר מהיחס בין התחלת checkout לרכישה, ולכן מתחילים אחרי הסל.

בפילוח מתברר ש־80% מה־checkout במובייל נעצרים לפני בחירת משלוח. בדיקה ידנית מגלה ששדה המיקוד מחזיר שגיאה באנגלית, ולאחר תיקון המדינה המסך קופץ לראש העמוד. במקביל, מספר הזמנות החנות גבוה ממספר אירועי purchase משום שספק התשלום מחזיר את הלקוח לדף אחר.

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

מתי לא נכון לעצב מחדש

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

• כאשר ההזמנות קיימות, אך אירוע purchase חסר או כפול. מתקנים את המדידה.
• כאשר התנועה קטנה מדי כדי להסיק ממעבר יחיד, ומדובר בפלח זעיר בלי שחזור. אוספים עוד ראיות.
• כאשר המלאי, אזור השירות או אמצעי התשלום אינם מאפשרים את העסקה. זו בעיה עסקית או תפעולית לפני שהיא בעיית UX.
• כאשר ההוספות לסל מגיעות משאילתות או קהלים שאינם מתאימים להצעה. בודקים גם את איכות התנועה והנחיתה, לא רק את הקופה.
• כאשר כמה שינויים גדולים כבר רצים במקביל. עוצרים ומייצרים נקודת בסיס, אחרת אי אפשר לדעת מה גרם לתוצאה.

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

סדר יישום ו־QA לפני שמסיקים שההמרה השתפרה

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

הצלחה אינה רק יותר purchase בדוח. אם האירוע הוכפל, אם ההזמנות בוטלו, אם ההנחה אכלה את המרווח או אם שיעור ההחזרות עלה, השיפור לכאורה אינו בהכרח שיפור עסקי.

שאלות נפוצות

יש הרבה add_to_cart אבל אין begin_checkout. מה לבדוק?

מתחילים באימות שהסל נפתח ומתעדכן, ואז בודקים מחיר כולל, משלוח, קופון, עריכת כמות, כפתור מעבר לקופה וחוויית מובייל. במקביל מוודאים ש־begin_checkout נשלח רק כאשר הקופה באמת נפתחה.

האם הוספה לסל אומרת שהלקוח התכוון לקנות?

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

איך יודעים אם הבעיה היא בתשלום?

מחפשים נפילה אחרי התחלת תשלום, שגיאות מספק התשלום, דחיות, כשלי 3-D Secure, חזרה שלא הושלמה או פער בין הזמנות למערכת לבין אירועי purchase. עסקת בדיקה במסלול הרלוונטי היא ראיה חזקה יותר מהנחה לפי שיעור נטישה.

האם כדאי להציע קופון למי שנטש?

לא כתגובה ראשונה. קופון יכול להסתיר בעיית UX, להפחית מרווח וללמד לקוחות לחכות להנחה. קודם בודקים אם מדובר בתשלום, משלוח, מידע חסר או מדידה, ורק אחר כך בוחנים תמריץ לפי פלח וכלכלה.

האם צריך למדוד את כל שלבי checkout ב־GA4?

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

מה עושים אם יש רכישות בחנות אבל אין purchase ב־GA4?

לא משנים את הקופה על סמך הדוח. בודקים את דף האישור, ספקי תשלום חיצוניים, consent, מזהה עסקה, כפילויות ומסלול שבו לקוח לא חוזר לאתר. לאחר תיקון המדידה מריצים עסקאות בדיקה ומשווים שוב.

האם בעיה במובייל מצדיקה עיצוב מחדש?

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

כמה נתונים צריך לפני תיקון?

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

מה הקשר בין SEO לבעיה של הוספות לסל בלי רכישות?

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

מתי לפנות לאבחון CRO?

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

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

אם החנות כבר מקבלת תנועה והוספות לסל, אבל אין תמונה אמינה של המקום שבו הרכישה נעצרת, זהו מצב מתאים ל־שיפור יחס המרה לאתרי איקומרס: בדיקת מדידה, מיפוי משפך, QA של המסלול ותעדוף תיקונים לפי השפעה ולא לפי תחושת בטן.