ניתוח Dead Clicks (קליקים על אלמנטים לא לחיצים)

ניתוח dead clicks: היכן הממשק מאבד משתמשים

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

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

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

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

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

מה נותן ניתוח לחיצות על רכיבים לא פעילים

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

בЯндекс Метрика אירועים כאלה נאספים לדוח מפת הלחיצות, שבו שוכבים זה לצד זה כשלי ממשק אמיתיים ורעש — ומשימת המהנדס היא להפריד בין השניים.

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

לאחר הגדרת הדגימה מאומת רוב האותות בדוח במקום כעשירית בלבד — מעצב ה-HTML כבר לא מבזבז משמרת על ניתוח התראות שווא.

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

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

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

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

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

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

כיצד בנויה העבודה: שלבים מסקר תגיות ועד מסירה

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

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

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

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

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

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

מקרה בוחן: הסרנו אותות שווא והשבנו את האמון בנתונים

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

הפרדנו את האותות לפי סוגים (לחיצה על טקסט בלי קישור, על תמונה בכרטיס, על כפתור שנראה פעיל אך אינו פעיל), סיננו בוטים ולחיצות עם חפיפת רכיב, והשווינו את הנותר לתגיות העמודים בЯндекс Метрике. לדוח נכנס רק מה שחזר אצל כמה משתמשים על אותו רכיב בדיוק.

מה אומת ומה הוסר

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

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

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

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

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

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

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

מהימנות המדידות נשענת על כך שכל מערכת אנליטיקה, כולל Яндекс Метрику, רושמת רק את האירוע שנשלח, ולא את כוונת המשתמש. לכן לפני הסקות אנחנו משווים את המשפך להקלטות המפגשים ולתגיות ה-handlers — סטייה במקום אחד בדרך כלל משמעה שחלק מהלחיצות כלל לא נכנס למדידה.

ספקות נפוצים: דיוק המדידות והתראות שווא

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

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

כבר יש לנו תגיות אירועים משלנו — יהיה צורך לזרוק אותן?

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

אילו נתונים אישיים נכנסים לדוח?

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

האם יהיה צורך לעדכן את קוד המוצר וכמה זמן זה ייקח?

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

נדון במשימה: אילו נתונים נדרשים לתחילת הפרויקט

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

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

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

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