בנצ'מרק ה-70% — ומה "נורמלי" באמת אומר
מחקר Baymard משנת 2024 מציב את שיעור נטישת העגלה הממוצע הגלובלי על 70.19% בכל הענפים. לחנויות WooCommerce בישראל, נטישה במובייל גבוהה ב-8 – 12% מהמחשב השולחני, בעיקר בשל עיכוב הפניה משערי תשלום ובעיות UX בטפסי מובייל הייחודיות לגופי תשלום מקומיים.
המטרה אינה אפס נטישה. קונים שמשווים, גולשים לחלון, ואנשים שמורים פריטים לאחר כך לעולם לא ימירו בביקור הראשון — ואין כמות אופטימיזציה של תהליך התשלום שתשנה זאת. המטרה היא לזהות את החלק מהנטישה שנגרם מחיכוך טכני ולסלק אותו. חלק זה נע בדרך כלל בין 18 – 35% מסך הנטישה, בהתאם לכמה זנוח תהליך התשלום כיום.
סדר האבחון חשוב: זמן טעינה תחילה, אחר כך שדות טופס, אחר כך אותות אמון, אחר כך UX מובייל. כל בעיה מרכיבה את הבאה — דף תשלום איטי שיש בו גם 12 שדות מיותרים וגם לוגו תשלום לא מהימן אינו שלוש בעיות נפרדות בעלות משקל שווה; הטעינה האיטית היא הסיבה שהאחרות בכלל נראות.
זמן טעינת דף התשלום הוא הפילטר הראשון
מחקר Google מכמת את העלות במדויק: כל עיכוב של שנייה אחת בטעינת דף התשלום מקטין המרות ב-7%. דף התשלום של WooCommerce פגיע במיוחד כי הוא טוען שלושה סקריפטים נפרדים לפני שכפתור "בצע הזמנה" הופך לניתן ללחיצה: ה- של שער התשלום, מחשבון המשלוח, ופעימת לב הסשן של WooCommerce. כל אחד מהם יכול להיות צוואר הבקבוק.
כלי האבחון הנכון הוא פאנל הביצועים של Chrome DevTools, לא ציון מהירות דף. טענו את דף התשלום על חיבור מובייל מוגבל (ה"4G איטי" של Chrome), פתחו את לשונית Network, ומיינו לפי משך זמן. הבקשה הארוכה ביותר היא התיקון הראשון שלכם. מחשבון משלוח שמבצע מסע הלוך-חזור לשרת בכל שינוי מדינה/מיקוד הוא אשם שכיח — החליפו אותו באפשרות משלוח בתעריף קבוע ומדדו את ההשפעה.
לתוספי מטמון כמעט אין השפעה על זמן טעינת דף התשלום כי לא ניתן לשמור אותו במטמון — הוא ספציפי לסשן. תיקון הביצועים הוא ברמת הסקריפטים: דחו JavaScript לא קריטי, טענו את ה-iframe של שער התשלום בצורה עצלה רק כשהמשתמש גולל לקטע התשלום, והסירו כל תוסף שמוסיף סקריפטים לכל דף כשהוא צריך לפעול רק בדפי חנות.
שדות טופס: חשבון החיכוך
מחקר השימושיות של Baymard משנת 2024 מצא שלתהליך התשלום הממוצע יש 39 שדות או שלבים, מהם 24 מיותרים. מחקרם מכמת את עלות ההמרה: כל שדה מיותר מסיר 2 – 4% מתהליכי התשלום המושלמים. תשלום עם 8 שדות הניתנים להסרה מאבד בין 16 – 32% מהמרות דרך חיכוך בלבד.
הביקורת המעשית לחנות WooCommerce: שם חברה (הסירו לחלוטין לחנויות B2C — כמעט אף אחד לא ממלא אותו בדיוק והוא מסמן "האתר הזה לעסקים"), מספר טלפון (הפכו לאופציונלי, לא חובה — רוב הלקוחות נוטשים כשמופיע שדה טלפון חובה באמצע התשלום), כתובת חיוב כשמשלוח וחיוב זהים (אחדו עם תיבת סימון שמסומנת כברירת מחדל).
לחנויות בישראל: שדה מספר תעודת הזהות הנדרש להפקת חשבוניות מס אינו ניתן למשא ומתן מבחינה משפטית — אבל המיקום חשוב. מקמו אותו כשדה האחרון לפני שליחה, תייגו אותו במפורש כנדרש לצרכי חשבונית, ומלאו מראש מחשבון המשתמש אם הוא מחובר. כל נקודת חיכוך בסוף תהליך תשלום עולה יותר מאותה חיכוך בהתחלה, כי המשתמש כבר השקיע זמן.
אותות אמון בשערי תשלום — ומה פוגע באופן פעיל
שלושה אותות אמון שמשפרים המרה כשממוקמים נכון: תג SSL גלוי מעל הקפל בדף התשלום (לא בכותרת התחתית — מעל טופס התשלום), לוגואים של כרטיסי אשראי מקובלים מיד מעל כפתור "בצע הזמנה", והצהרת החזר כספי או תשלום מאובטח במשפט אחד ליד כפתור הפעולה. כל אחד מאלה הוא שיפור המרה של 1 – 3% בנפרד; יחד הם יכולים להזיז את המחט 5 – 8%.
האות שמשמיד אמון באופן פעיל: הפניה של שער תשלום לדומיין צד שלישי עם עיצוב ויזואלי שונה. המשתמש רואה את ה-checkout שלכם, לוחץ "לתשלום", ומגיע לדף שלא נראה בכלל כמו החנות שלכם — צבעים שונים, גופנים שונים, URL שהוא לא מזהה. זה הגורם העיקרי לנטישה ברגע האחרון. התיקון הטכני: השתמשו במצב הטמעת ה- של שער התשלום במקום הפניה.
לחנויות WooCommerce בישראל ספציפית: Tranzila ו-Cardcom תומכים שניהם באינטגרציית הטמעת iframe. מצב ההפניה הוא תצורת ברירת המחדל כי אינו דורש ניהול תעודת SSL בצד החנות — אבל עלות הנטישה של ההפניה בדרך כלל עולה על מורכבות הגדרת ה-SSL תוך חודשיים מהפעלת החנות.
תשלום במובייל: היכן רוב חנויות WooCommerce נכשלות בשקט
iOS Safari מבצע זום אוטומטי לכל אלמנט קלט עם גודל גופן מתחת ל-16px. בטופס תשלום, הזום הזה של תצוגה מזיז את הפריסה, מכווץ את האזור הנראה, וגורם לעתים קרובות לטופס התשלום לעצב מחדש תוך כדי הקלדה — המשתמש מאבד את מקומו ולעתים קרובות נוטש. התיקון הוא כלל CSS יחיד: הגדירו font-size ל-16px על כל אלמנטי קלט של תהליך התשלום. זה לא משפע על פריסת שולחן עבודה ומבטל את הזום האוטומטי בכל מכשיר iOS.
Android Chrome נכשל אחרת: מקלדת מספרית לא מופיעה לשדות מספר כרטיס אלא אם הקלט נושא את המאפיין inputmode="numeric". בלעדיו, המשתמש מקבל את המקלדת האלפביתית המלאה על מסך של 10 סנטימטר, מנסה למצוא את לוח המספרים, ולעתים קרובות מוותר. שדות תהליך התשלום המוגדרים כברירת מחדל של WooCommerce אינם כוללים מאפיין זה — נדרש תוסף מותאם או פילטר PHP ישיר לארגומנטי שדה תהליך התשלום.
שני אלה הם כשלים שקטים. שגיאת JavaScript לא מופיעה בקונסול, לא נרשם שגיאה. האות היחיד הוא הקלטות סשן המציגות משתמשים שנוטשים בשלב התשלום במובייל. בדקו את שניהם לפני שמניחים שה-checkout שלכם מוכן למובייל.
מציאת צוואר הבקבוק הספציפי שלכם
אנדקסו שלושה אירועים ב-Google Analytics 4: טעינת דף תשלום, בחירת שיטת משלוח, ולחיצת כפתור תשלום. אחוז הנפילה בין שני אירועים עוקבים הוא שלכם באותו שלב — וזה השלב שצריך לתקן ראשון.
אם הנפילה היא בין טעינת דף תשלום לבחירת שיטת משלוח, הבעיה היא זמן טעינה או מורכבות טופס (יותר מדי שדות לפני שהמשתמש אפילו מגיע למשלוח). אם הנפילה היא בין בחירת משלוח ללחיצת תשלום, הבעיה היא אותות אמון או בחירת אמצעי תשלום. אם הנפילה היא לאחר לחיצת תשלום, הבעיה היא שער התשלום עצמו — הפניה, השהיית iframe, או חווית דחיית כרטיס.
WooCommerce כולל משפך בסיסי בדוחות WooCommerce Analytics. למעקב אירועים מפורט יותר, הוסיפו אירועי GA4 מותאמים באמצעות ה-JavaScript hooks של WooCommerce (add_to_cart, begin_checkout, purchase). Google Tag Manager הופך זאת לניתן לניהול ללא נגיעה ב-PHP. לאחר האינדוקס, תהיה לכם נתוני המרה ספציפיים לחנות שלכם — לא בנצ'מרקים של ענף.
כמה ה-checkout שלכם באמת מפסיד?
ספרו לי את שיעור ההמרה הנוכחי של ה-checkout שלכם ואיפה המשתמשים נוטשים. אאבחן את צוואר הבקבוק הספציפי ואגיד לכם מה לתקן ראשון.
התחילו את הבריףמקורות
- 1Baymard Institute — 2024 E-Commerce Checkout Usability Study — ממוצע נטישת עגלה גלובלי: 70.19%. לתהליך תשלום ממוצע יש 39 שדות; 24 מיותרים. כל שדה שהוסר מקטין נטישה ב-2 – 4%.
- 2Google / SOASTA — The State of Online Retail Performance — כל עיכוב של שנייה בטעינת דף תשלום מקטין המרות ב-7%. לסשני מובייל עם זמני טעינה מעל 3 שניות יש שיעור יציאה של 53%.
- 3Tranzila — תיעוד מפתחים: מצב אינטגרציית iframe — מצב הטמעת ה-iframe של Tranzila שומר את טופס התשלום בתוך דף הסוחר, ומבטל את גורם נטישת שינוי הדומיין של מצב ההפניה הסטנדרטי.
- 4Apple — Safari mobile text size adjustment — iOS Safari מבצע זום אוטומטי לאלמנטי קלט עם font-size מתחת ל-16px. הזום האוטומטי מפריע לתהליך ה-checkout ולא ניתן להשביתו מבלי לפגוע בנגישות.
- 5WHATWG — HTML inputmode attribute specification — inputmode="numeric" מפעיל את המקלדת המספרית ב-iOS וב-Android לקלטים טקסטואליים — נדרש לשדות מספר כרטיס, CVV ומיקוד כדי למנוע הצגת מקלדת אלפביתית במובייל.