ביקורת שמישות אתר על 1С-Битрикс: היכן אובדות פניות
ביקורת שמישות אתר אינה בחינה קוסמטית של הפריסה, אלא ניתוח של נתיב הלקוח שלב אחר שלב: מהכניסה מחיפוש ועד אישור ההזמנה. אנחנו בוחנים לא «האם זה מוצא חן בעיניי או לא», אלא היכן האדם עוצר וסוגר את הדף.
כל שלב נמדד לפי שיעור הפעולות הנטושות — כך הוויכוח על טעם מוחלף ברשימת נקודות אובדן המרות עם סדרי עדיפויות ברורים.
הקבוצה הראשונה של נקודות כאלה נמצאת בדרך כלל בתהליך השלמת ההזמנה. טופס עם שנים עשר שדות במקום שלושה, הרשמה חובה לפני חישוב משלוח, מחיר וזמני אספקה מוסתרים בעמוד נפרד — אלו חסמים אופייניים בתהליך ביצוע ההזמנה. אנחנו בודקים אותם בתרחישים אמיתיים: רכישה בפעולה אחת, הזמנה חוזרת, הזמנה ללא שיחת מנהל.
הקבוצה השנייה — ניווט בקטלוג. כאשר יש אלפי פריטים, המסננים מצטלבים כך שחלק מהמוצרים אינם נגישים בשני צעדים, ופירורי הלחם אינם מחזירים למבחר הרצוי. ביקורת שמישות לחנות מקוונת סופרת בנפרד את העומק: כמה פעולות עד למוצר היעד וכמה ענפים ללא מוצא בתפריט.
הקבוצה השלישית — תגובת הממשק. מסנן איטי, עגלת קניות עם השהיה בחישוב מחדש, חלון קופץ מעל כפתור «בצע הזמנה» — המשתמש תופס זאת כתקלה ועוזב. ב-1С-Битрикс זה לרוב תוצאה של הגדרות מטמון ותבניות עמוסות מדי, ולא של הפלטפורמה עצמה: זה מתוקן נקודתית, בלי לשכתב את האתר.
לאחר מכן אנו מכנסים את הממצאים למפה: שלב, שיעור האובדן, הסיבה, מה משנים. לפיה רואים מה לתקן קודם — בזה עוסקים המהנדסים שלנו.
מה משתנה לאחר הסרת החסמים בנתיב הלקוח
השינוי המדיד הראשון — קיצור הנתיב לפנייה. אנו סופרים לא «נהיה נוח יותר», אלא כמה שלבים ושדות חובה מפרידים בין המבקר לשליחת הטופס: בתבניות אופייניות של 1С-Битрикс יש שבעה-שמונה כאלה, לאחר התיקונים נשארים שלושה-ארבעה. שיעור המגיעים לקצה הטופס עולה מיד, בלי שינויים בערוצי הפרסום ובמחירים.
החתך השני — עגלות נטושות. לקוח עוזב לעתים קרובות לא בגלל המחיר, אלא מפני שאינו רואה את תנאי המשלוח, הזמנים ואמצעי התשלום לפני רגע ההשלמה.
אנו מעלים את הבלוקים האלה מעל הכפתור, מציגים עלות וזמן עד לתשלום, ומשכתבים את טקסטי השגיאה בשדות — העגלה מפסיקה להיות מבוי סתום, והאובדנים בשלב התשלום מצטמצמים באופן ניכר.
האפקט השלישי — העומס על שירות התמיכה. כאשר סטטוס ההזמנה, שלב האישור וסיבת הסירוב גלויים באזור האישי, הלקוח לא מתקשר עם השאלה «מה קורה עם ההזמנה שלי». רמזים ברורים בשדות מסירים ספקות אופייניים לפני הפנייה, זרם המיילים האחידים יורד, והזמן שהתפנה מוקדש למקרים מורכבים.
בנפרד אנו בוחנים פניות חוזרות של לקוחות. אם הנתיב לפנייה צפוי, וההיסטוריה של הזמנות ומסמכים נמצאת באזור האישי, האדם חוזר לשירות הבא באותו ממשק, ולא מחפש מחדש היכן להשאיר בקשה.
את כל התיקונים אנו בודקים על אותו חתך אנליטי לפני ואחרי — כך גידול ההמרות לאחר תיקוני השמישות נראה בנפרד מתנודות עונתיות.
פורמטים של ביקורת: מהיר, מחזור מלא, בקרה מתמשכת
מצב הביקורת נבחר לפי שני פרמטרים: כמה עמוק צריך לחפור וכמה מהר דרוש результат. מדידות אנו מבצעים לפני תחילת העבודה — אחרת לאחר התיקונים לא ניתן להבין מה בדיוק נתן את האפקט.
השוואת מצבים
| פורמט | מתי מתאים | מגבלות |
|---|---|---|
| ביקורת שמישות מזורזת | יש צורך להסיר במהירות אובדנים ברורים בתרחישי מפתח | לא יראה סיבות בעומק המשפך, ההשערות אינן נבדקות על אנשים |
| מחזור מלא של ביקורת שמישות | מתוכננת עיבוד מחדש של מדורים והיגיון ההזמנה | דורש גישה לאנליטיקה והשתתפות בעל המוצר, אורך יותר זמן |
| ביקורת עם בדיקה על משתמשים | ישנן השערות שנויות במחלוקת, יש צורך בהחלטה לפני שחרור | יש לאסוף נבדקים מהסגמנט הנדרש, לוח הזמנים תלוי בהם |
| בקרה מתמשכת של הממשק | האתר חי: שחרורים, מבצעים, טפסים חדשים | פועל כתקנון עם מדידות קבועות, ולא כפעולה חד-פעמית |
אפשר להתחיל בביקורת מזורזת: היא מראה היכן האובדנים נמצאים כעת, ונותנת בסיס להחליט אם נדרש מחזור מלא. את התוכנית והרכב העבודה אנו מקבעים לפני ההתחלה, ולכן ההיקף לא מתפשט תוך כדי.
איך עוברת העבודה: מנטילת מדדים ועד בדיקת התיקונים
ביקורת שמישות אתר על 1С-Битрикс מתחילה לא מדעות מומחים, אלא מנטילת מדדים: אנו בוחנים באילו שלבים המבקר עוזב, ומצליבים זאת עם הקלטות של התנהגות משתמשים. כך אנו מקבלים רשימה של נקודות אובדן מתוך עובדות, ולא מתוך שיקולים כלליים, וכבר עבורן מנסחים השערות לתיקונים.
- נטילת מדדים. אנו מתעדים את מדדי המשפך הנוכחיים: שיעור המגיעים להזמנה, עומק הצפייה, מקורות. זהו בסיס להשוואה — בלעדיו אין במה להוכיח את אפקט התיקונים.
- הקלטת התנהגות משתמשים. אנו בוחנים היכן הסמן קופא, אילו שדות בטופס נזנחים, אילו מסננים לא שמים לב אליהם. ההקלטות מראות את הרגע שבו האדם ויתר — במספרים זה לא נראה.
- תעדוף תיקונים. אנו מפרקים את הממצאים לפי השפעה על הפעולה הרצויה ועלות היישום. ראשית ניקח את מה שמסיר אובדנים בתרחישים ההמוניים ביותר.
- בדיקת השערות על אב-טיפוס. אנו בונים גרסה עובדת של הבלוק השנוי במחלוקת ונותנים למשתמש משימה: האם הגיע ליעד, כמה צעדים מיותרים עשה. פתרונות חלשים נפסלים לפני הפיתוח.
- יישום. את התיקונים מבצעים בחלקים, תוך שמירת גרסאות קודמות של תבניות ואפשרות חזרה: החלפה מלאה של הממשק באתר פעיל מסוכנת מדי.
- בקרה לאחר שחרור. כעבור שבועיים וחודש לאחר היציאה אנו נוטלים את אותם מדדים. אם המדדים לא זזו, אנו חוזרים להשערה, ולא משאירים את התיקון «ליתר ביטחון».
מה נשאר אצל המזמין: מפות, דוחות, תקנונים
התוצאה ההנדסית של הביקורת אינה מצגת, אלא סט חפצים שנשארים במאגר ובמסמכי הפרויקט. כעבור חצי שנה רואים לפיהם מדוע הבלוק בנוי דווקא כך, והתיקון הבא אינו שובר את מה שנמצא.
- מפת נתיב המשתמש לכל תרחיש מפתח: מהכניסה מחיפוש ועד שליחת טופס או השלמת הזמנה, עם שלבים שבהם המבקר עוזב.
- דוח נקודות אובדן עם סדרי עדיפויות: השערה, אפקט צפוי, מורכבות התיקון ודרך הבדיקה — מאימות שדות ועד סדר הבלוקים בנייד.
- רשימת תיקונים לפי תבניות עם קישור לכתובות עמודים: אילו רכיבים וכללי פלט משנים, כדי שהתיקון לא יתפשט למדורים שכנים.
- פריסות של תיקונים למסכים עיקריים: מצב לפני ואחרי, התנהגות השדות, טקסטי שגיאה ורמזים.
- תקנון בדיקת שחרור: רשימת בדיקות לפני העלאה — תרחישים, טפסים, יעדי אנליטיקה, התנהגות העגלה וההזדהות.
- תיעוד הממשק: מפת תבניות, ייעוד שדות והגדרות מותאמות אישית, נקודות חילוף עם מערכת חשבונאית.
- כללים לביצוע שינויים: מי מאשר את התיקון, באיזה ענף הוא חי ומה נבדק לפני הפרסום.
עם הסט הזה צוות המזמין מבצע שינויים בעצמו או מוסר אותם לנו — בשני המקרים אין צורך לברר מחדש איך בנוי התרחיש והיכן הוא נשבר.
מקרה בוחן: שיעור ההזמנות שהושלמו והזמן עד לפנייה
מה היה לפני התיקונים
חנות על 1С-Битрикс עם תנועה גדלה: שיעור ההזמנות שהושלמו החזיק מעמד סביב רבע מהעגלות, והשלמת ההזמנה ארכה בממוצע 4 דקות ו-20 שניות. ביקורת המשפך חשפה שלושה צווארי בקבוק — הרשמה חובה לפני בחירת משלוח, הזנה ידנית של כתובת וטופס תשלום שהודיע על שגיאה בלי לציין את השדה הבעייתי. התמיכה קיבלה למעלה מ-300 פניות בחודש, שני שלישים מהן — «ההזמנה לא עוברת».
מה שינו ומה נהיה
את השלמת ההזמנה קיצרנו מחמישה שלבים לשניים: ההרשמה הועברה לסוף והיא נטענת לפי מספר טלפון, הכתובת מזוהה לפי מיקוד, ושדות עם שגיאה מודגשים יחד עם הסיבה. בשלב נפרד שוכתבו טקסטי הכפתורים והרמזים — «המשך» המופשט הוחלף בפעולה קונקרטית, וסטטוס ההזמנה הועלה למסך הראשון.
לאחר התיקונים שיעור ההזמנות שהושלמו עלה מ-24% ל-41%, זמן ההשלמה הצטמצם לדקה ו-40 שניות, ופניות לתמיכה בנושא השלמת הזמנה פחתו בשני שלישים. בנפרד נעלם סוג של כפילויות: קודם 12% מההזמנות נוצרו פעמיים בגלל שליחה חוזרת של הטופס, כעת אין כמעט כפילויות.
את המדידות נטלנו בתקופות ברות השוואה ובמקור תנועה אחד, כדי לא לבלבל בין אפקט התיקונים לעונתיות.
במה שמישות נבדלת מאנליטיקת ווב
אנליטיקה עונה על השאלה «היכן»: כמה אנשים הגיעו לעגלה, באיזה שלב של ההשלמה נשרו, כיצד השתנה שיעור הנטישה לאחר התיקונים. זהו רובד כמותי — הוא מראה באופן מהימן את היקף האובדן ואת מקומו במשפך, אך שותק לגבי הסיבה.
ביקורת שמישות עונה על «מדוע»: האדם לא מוצא שדה, לא מבין את ניסוח התנאי, מהסס לגבי זמן האספקה ועוזב לפני שהמערכת תיעדה את הכישלון. המונה רואה את עובדת העזיבה, אך אינו רואה את הספק שקדם לה.
תצפית וסקרים נותנים דברים שונים. סקר מתעד מה האדם חושב על התנהגותו, ולעתים קרובות סוטה מהמציאות: הוא יאמר שלא מצא את הכפתור, אף ששלוש פעמים פספס אותו. תצפית מראה את המסלול בפועל — לאן הוא מסתכל, היכן קופא, מה מנסה ללחוץ ומדוע נוטש.
השאלה «האם נדרשת ביקורת אם יש אנליטיקת ווב» נפתרת בפשטות. אנליטיקה מצמצמת את החיפוש לשלב מסוים, הביקורת מסבירה מדוע השלב לא עובר. נתונים כמותיים בלי איכותניים נותנים רשימת בעיות בלי סדרי עדיפויות, ותצפית בלי מספרים — אוסף דעות פרטיות. עובד השילוב: המספרים מצביעים על נקודת האובדן, התצפית והסקרים מסבירים את החלטת המשתמש.
ספקות נפוצים: טפסים, מטמון, תבניות, אינטגרציות
לפני ההתחלה עולים בדרך כלל אותם שאלות טכניות: מה צריך מהמזמין, האם אפשר לעבוד על עותק, האם התיקונים לא יפגעו בחילוף עם המערכת החשבונאית. אנו עונים לפני תחילת העבודה, כדי שהביקורת תתנהל בלי סיכון לסביבת הייצור.
אילו הרשאות נדרשות והאם אפשר להסתפק בעותק?
לצורך הביקורת מספיק עותק של האתר בסביבה נפרדת: אנו מורידים את מסד הנתונים ואת קובצי התבנית, פורשים מקומית ועובדים שם. גישה לפאנל הניהול נדרשת כדי לבדוק את הגדרות הטפסים, כללי המטמון ותרחישי ההזמנה האמיתיים. בסביבת הייצור לא נוגעים עד לאישור התיקונים — החילוף עם המערכת החשבונאית ממשיך לעבוד כרגיל.
האם התיקונים ישברו את החילוף עם המערכת החשבונאית?
תיקונים בתבניות, בפריסה ובסקריפטים של טפסים אינם נוגעים בחילוף — הם חיים בנפרד מהמטפלים בייצוא. אם התיקון נוגע למקומות שמעבירים הזמנות למערכת החשבונאית, תחילה מריצים את התרחיש על עותק עם ייצוא בדיקה: משווים את הרכב השדות, יומני החילוף והתנהגות בשליחה חוזרת. לייצור מעבירים רק לאחר שהרכב הנתונים תאם.
מדוע לאחר התיקון רואים גרסה ישנה של העמוד?
חלק מהעמודים נבנים מהמטמון, ולכן השינויים עשויים לא להופיע מיד. לפני ההעלאה אנו מתעדים אילו כללי מטמון ורכיבים נפגעו, ומנקים נקודתית לפי מדורים, ולא את כל האתר — אחרת העומס יגדל. לאחר מכן בודקים את הטפסים ואת השלמת ההזמנה בשלמותם: מהוספת מוצר ועד אישור, בדפדפנים שונים.
נדון במשימה: מה נראה ובאיזה אופן
השיחה מתחילה במשימה שלכם, ולא ברשימת שירותים תבניתית. כדי לחזור עם הערכה ממוקדת, די בגישה לאנליטיקה, רשימת תרחישים שבהם לפי תצפיותיכם אובדות פניות, ותיאור קצר של מה שכבר ניסיתם לשנות בממשק. זה מספיק כדי לדון במשימת השמישות באופן ענייני ולנקוב בלוחות זמנים אמיתיים לביקורת, ולא ממוצעים.
מה נראה בפגישה ובאיזה אופן נחזור עם תוכנית:
- מפת נקודות אובדן המרות: היכן בדיוק במשפך המשתמש עוזב — לפי שלבי השלמת הפנייה, טפסים, עמודי קטלוג ועגלה.
- ניתוח נתיבי משתמשים על תנועה חיה והקלטות סשנים, עם ציון איזה שלב שובר את התרחיש ובאיזה מסך זה קורה.
- הערכת לוחות זמנים לביקורת: כמה זמן ייקח כל שלב ומאילו נתונים הוא תלוי, כדי שתוכלו לתכנן את העבודה.
- תוכנית תיקונים לאחר הביקורת — עם סדרי עדיפויות לפי השפעה על המרות וחלוקה לשינויים מהירים ולעיבוד מחדש של תבניות.
- הרכב העבודה על הממשק: אילו רכיבים וטפסים אנו נוגעים, מה עושים בצד התבניות ומה בצד הלוגיקה.
- סט מדדים לפני ואחרי התיקונים, כדי שהאפקט יימדד ולא יידון במילים.
תארו את המשימה בצורה נוחה לכם — שלחו קישור לאתר ובשני-שלושה פסקאות ספרו מה לא מתאים. נחזור עם הערכה ותוכנית עבודה: מה עושים ראשון, מה אפשר לדחות ואיזה תוצאה תראו בכל שלב.