אינטגרציית Hotjar למפות חום של אפליקציית מובייל

Hotjar SDK לנייד: היכן נשבר איסוף מפות החום

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

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

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

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

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

מה נותנת מפת חום תקינה באפליקציה

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

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

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

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

דרכי איסוף: שירות ענן, איסוף עצמי, היברידי

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

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

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

הטמעת איסוף מפות חום: שלבי העבודה

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

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

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

סכימת אירועים, מיסוך שדות ותקנונים

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

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

בנפרד אנחנו מקבעים אילו דוחות ב־Hotjar נבנים על האירועים האלה — כדי שהפאנל לא יהפוך למזבלה.

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

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

הצוות קיבל החלטות לפי תמונה מעוותת: אזורים "מתים" במפה התבררו כאזורים שפשוט לא היו בהם נתונים.

מה שינו

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

מדדים לפני ואחרי

שיעור הסשנים האבודים ירד מ־40% ל־3-4%, ושלמות שרשרת המסכים בתרחיש המרכזי עלתה מ־58% ל־96%. פריסת מסך חדש מוציאים כיום תוך יום-יומיים במקום שבועיים: מזהים ואירועים מתוארים באופן דקלרטיבי, בלי תיקונים בקוד הניווט.

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

מה עושים אם Hotjar כבר פרוס באפליקציה?

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

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

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

ספקות לגבי דיוק הנתונים והפרטיות

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

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

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

האם נתונים אישיים עלולים לדלוף להקלטה?

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

האם גודל הבנייה יגדל?

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

נדון במשימה — נחזור עם הערכה ותוכנית עבודה

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

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

כדאי לדעת לפני שמתחילים:

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

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

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