מדידה של אפליקציות בדף יחיד

המסמך הזה מיועד למפתחים שרוצים למדוד צפיות בדפים באפליקציית דף יחיד באמצעות Google Analytics.

אפליקציות בדף יחיד (SPA) הן אתרים שטוענים מסמך HTML פעם אחת ומביאים תוכן נוסף באמצעות ממשקי API של JavaScript.

דוגמה: נניח שיש לכם טופס לאיסוף לידים. הטופס כולל שלושה מסכים:

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

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

לפני שמתחילים

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

הטמעה של מדידה באפליקציה בדף יחיד

כדי להטמיע מדידה מדויקת של SPA, צריך להשתמש באחת מהשיטות הבאות כדי להפעיל צפייה וירטואלית חדשה בדף:

  • שינויים בהיסטוריית הדפדפן (מומלץ): אם ה-SPA שלכם משתמש ב-History API, ובמיוחד בשיטות pushState() ו-replaceState() לעדכון מסכים, כדאי להשתמש באפשרות הזו.

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

הטמעה של שינוי בהיסטוריית הדפדפן

אם ה-SPA שלכם משתמש ב-History API, אתם יכולים להפעיל מדידה משופרת ב-Google Analytics כדי לעקוב באופן אוטומטי אחרי צפיות בדפים על סמך אירועים בהיסטוריית הדפדפן.

הפעלת מדידה משופרת ב-GA4

כדי למדוד את page_views באופן אוטומטי על סמך היסטוריית הגלישה:

  1. פותחים את Google Analytics.

  2. בדף ניהול, בקטע איסוף נתונים ושינוי שלהם, לוחצים על מקורות נתונים > אתר.

  3. בקטע מדידה משופרת מעבירים את המתג למצב מופעל כדי להפעיל את כל האפשרויות.

  4. לוחצים כדי לערוך אפשרויות ספציפיות. בקטע צפיות בדף, לוחצים על הצגת הגדרות מתקדמות. חשוב להפעיל גם את Page loads (טעינות דפים) וגם את Page changes based on browser history events (שינויים בדפים שמבוססים על אירועים בהיסטוריית הדפדפן).

    תמונה שמציגה את ההגדרה של צפיות בדף

  5. שומרים את השינויים.

הערה: כשהמדידה המשופרת מופעלת עבור 'שינויים בדף על סמך אירועי היסטוריית הדפדפן', מערכת Google Analytics מאזינה באופן אוטומטי לאירועי היסטוריה (כמו אלה שמשמשים ב-SPA) ושולחת אירועי page_view. לא צריך להגדיר משתני היסטוריה או טריגרים ספציפיים ב-Google Tag Manager כדי לשלוח צפיות בדפים ל-GA4.

שימוש בטריגרים של Google Tag Manager לאירועים בהיסטוריה

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

כשמגדירים תגים או משתנים שיפעלו עם הטריגר History Change, חשוב להשתמש במשתנים מובנים הנכונים שמופיעים ב-Google Tag Manager:

  • History New URL Fragment: הפרגמנט של כתובת ה-URL אחרי אירוע ההיסטוריה.
  • History Old URL Fragment: הפרגמנט של כתובת ה-URL לפני אירוע ההיסטוריה.
  • History New State: אובייקט חדש של מצב ההיסטוריה.
  • History Old State: אובייקט המצב הישן של ההיסטוריה.
  • History Source: המקור של אירוע ההיסטוריה (למשל popstate,‏ pushState, ‏ replaceState).

יכול להיות שצריך להפעיל את המשתנים המובנים האלה ב-Google Tag Manager קודם, בקטע Variables (משתנים) > Configure (הגדרה).

מידע נוסף על הטריגר הזה זמין במאמר בנושא טריגר של שינוי בהיסטוריה.

אימות הגדרת המדידה

כדי לוודא שהאפליקציה של דף יחיד מודדת צפיות בדפים בצורה נכונה:

  1. מפעילים את מצב ניפוי הבאגים לכל תג בהגדרת המדידה של ה-SPA. איך עוקבים אחרי אירועים ב-DebugView

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

שיקולים נוספים לגבי SPAs

בנוסף לשליחת אירועים של page_view, כדאי לשקול את ההיבטים הבאים כדי לשפר את השילוב של אפליקציות SPA עם Google Analytics ואת חוויית המשתמש:

ניהול מיקום הגלילה

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

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

// Example: Reset window scroll position on a route change in your SPA
window.scrollTo(0, 0);

// Or, if your content is within a specific element:
// document.getElementById('main-content').scrollTo(0, 0);

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

הקפדה על נגישות התוכן לתכונות הדפדפן

אם משתמשים מדווחים על בעיות בתכונות של הדפדפן, כמו חיפוש בדף (Ctrl+F), שלא פועלות אחרי טעינת דף וירטואלי, יכול להיות שזה מעיד על האופן שבו ה-SPA מעדכן את ה-DOM.

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

השפעה על אירועים אוטומטיים

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

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

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

  • האירוע user_engagement נשלח כשהמשתמש מנווט מדף וירטואלי אחד לדף וירטואלי אחר.
  • משך ההתעניינות בדף הווירטואלי הקודם מחושב ונשלח יחד עם האירוע user_engagement, בדרך כלל ממש לפני שהאירוע page_view של הדף הווירטואלי החדש מעובד.
  • אירועים אחרים, כמו קליקים או גלילה, משויכים ל-page_location של הדף הווירטואלי שהמשתמש צופה בו כרגע.

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