הגדרת Microsoft Clarity: ניתוח התנהגות משתמשים

Microsoft Clarity מותקן, אך התנהגות המשתמשים אינה נקראת

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

הסיבה אינה בכלי, אלא בכך ש-Microsoft Clarity רואה כברירת מחדל את העמוד כיחידה אחת שלמה.

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

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

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

חמישה אפקטים מדידים מאנליטיקת התנהגות מסודרת

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

שיעור המגיעים לשלב התשלום

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

זמן חקירת תקלה

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

סוג הנטישות שנפתרו

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

מהירות בדיקת השערות

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

שלמות התמונה במובייל

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

Microsoft Clarity: אפשרויות לאיסוף נתוני התנהגות

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

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

סדר העבודות: מביקורת תיוג ועד מסירת דוחות

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

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

מפת אירועים, תקנוני תיוג ותיעוד

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

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

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

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

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

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

מה גילה הבדיקה

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

מה קרה אחרי התיקון

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

מה לעשות אם המונה כבר מותקן, אך הנתונים אינם נקראים

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

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

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

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

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

פרטיות, עומס ודיוק: ספקות טכניים

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

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

כיצד להחריג בלוקים רגישים בשלמותם?

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

עד כמה הנתונים מדויקים וכמה זמן נשמרות ההקלטות?

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

נדון במשימה: אילו נתונים נדרשים להערכה

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

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

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

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