יש כמה אפשרויות להגדרת תגי Google Analytics 4 שיכולות להשפיע על זהות המשתמש והסשן. אם ההגדרות לא נכונות, יכול להיות שלא תהיה אפשרות לזהות או לסווג מקורות תנועה, או שיהיו בעיות אחרות בדוחות. הבעיות האלה כוללות שורות ללא הקצאה בקבוצות ערוצים בדוחות, ערכי (not set), ומקרים בהם חלק גדול במיוחד מהתנועה מסווג כתנועה ישירה.
בדוחות של Google Analytics 4, שורה ללא הקצאה מופיעה כשמערכת Analytics לא יכולה לסווג את מקור התנועה. מערכת Analytics מסווגת מקורות תנועה לערוצים לפי כללים קבועים. לדוגמה, הערוץ 'חיפוש אורגני' כולל תנועה מכל מנועי החיפוש. הערוצים מאורגנים בקבוצות ערוצים. אם אתם משתמשים בקבוצות הערוצים שמוגדרות כברירת מחדל, אתם יכולים לקרוא על הלוגיקה הספציפית לסיווג התנועה בקטע ההגדרות של ערוצי ברירת המחדל. אפשר לראות את קבוצות הערוצים ברמת המשתמש, הסשן או האירוע.
אם מקור תנועה לא מתאים להגדרה של שום ערוץ בקבוצת הערוצים שמוצגת בדוח, הוא יופיע כמקור ללא הקצאה. יכול להיות שהוא לא מתאים לשום כלל קבוע כי התנועה מגיעה מאמצעי הגעה לאתר או ממקור שהוגדר על ידי המשתמש. זה גם יכול לקרות אם ערך המקור הוא (not set) כי חסר מידע על זהות המשתמש או הסשן.
שיטות מומלצות לסידור נכון של תגים
ריכזנו כאן כמה שיטות מומלצות לסידור התגים:
| סוג התג | הוראות | שיטות מומלצות |
|---|---|---|
|
Google Tag |
מומלץ לאתחל את Google Tag לפני שמשתמשים בשיטה שמוגדרת בה הפעלת אירועים בעקבות התווספות לקהל. |
|
|
Google Tag Manager |
מומלץ לפעול לפי 4 השלבים להגדרת GTM. |
|
|
תיוג בצד השרת |
חשוב לא לדלג על הגדרות התגים הספציפיות האלה. לא מומלץ שאותו נכס GA4 יהיה מוטמע באותו דף גם בצד השרת וגם בצד הלקוח. אם אתם משתמשים ב-GTM בצד השרת, חשוב לוודא שבכל התגים הפעילים מוגדרת שליחת אירועים דרך מאגר התגים בצד השרת. |
גם אם אתם לא יכולים ליישם את השיטות המומלצות האלה, כדאי לפעול לפי שתי ההמלצות הבאות, אחרת צפויות בעיות בדוחות.
- מומלץ לספק את כל ההגדרות הרלוונטיות לדף במסגרת הפקודה
config(במקרה של שימוש ב-Google Tag) או בהגדרות של Google Tag (במקרה של שימוש ב-Google Tag Manager). בשני המקרים, צריך למקם את ההגדרות האלה במיקום העליון ביותר האפשרי בדף, לפני כל האירועים. - ההפעלה של אירועים בהתאמה אישית לא אמורה להתבצע לפני הפקודה
config, אחרת האירועים יקובצו עם האירועsession_start. הפקודהconfigיכולה להשפיע על זהות המשתמש והסשן בכל שאר חלקי הדף, כלומר לא ניתן יהיה לשייך את הצפייה בדף ואת האירועים שיקרו אחר כך אל תחילת הסשן ואל האירוע המותאם האישית.
מה קורה אם סדר האירועים לא נכון?
אם תגי GA4 מוגדרים בזמנים לא צפויים (למשל, אם הפקודה config או Google Tag מופעלים אחרי אירועים אחרים בדף), עלולה להיות לכך השפעה על מזהה המשתמש, מזהה הסשן או שניהם. אלה התוצאות האפשריות:
- נתונים מופיעים כערך (not set) ב-Analytics
- מספרים שגויים של משתמשים וסשנים
- חישוב שגוי של מדדים ברמת המשתמש והסשן
- מדידה לא תקינה של משתמשים וסשנים
מה יכול לגרום לסדר שגוי של אירועים?
אלה חלק מהסיבות הנפוצות לתזמון לא צפוי:
| התכונה | הסיבה | התוצאה | שיטות מומלצות |
|---|---|---|---|
|
תיוג בצד השרת הגדרה בניהול השרת (מזהה לקוח בניהול השרת) הגדרות בניהול הלקוח |
סימון של תיבת התיוג בצד השרת בהגדרה 'בניהול השרת' (האפשרות מופעלת כברירת מחדל). כשאירועים מ-GA4 עוברים עיבוד דרך תג שרת, המשתמשים יכולים להשתמש בזהות משתמש ששונה ממזהה הלקוח שנכלל בתג האתר. |
אם מגדירים את האפשרות 'בניהול השרת' בתפריט הנפתח העליון, התיוג בצד השרת ינהל מזהה לקוח נפרד ויחליף אותו במדידות שעוברות עיבוד על ידו. בנוסף, ההגדרה הזו מספקת כמה אפשרויות לאופן הכתיבה של קובץ ה-Cookie הזה. היא גם מספקת אפשרות להעברה הדרגתית בשביל לקוחות שיש להם תנועה ישירה ב-GA ולא רוצים שיבושים חדים בקהלים ובדוחות, בעקבות שינוי פתאומי של כל מזהי המבקרים בבת אחת. |
אם משתמשים באפשרות הזו, צריך לוודא שכל פעולות המדידה של מקור הנתונים יעברו דרך תג השרת, וששום פעולה כזו לא תישלח ישירות לשרתים של Google. השיטה הכי קלה היא לוודא שהתג הראשון במאגר התגים בצד השרת הוא תמיד Google Tag Manager. אם משתמשים ב-Google Tag, מוודאים שהפקודה הראשונה במאגר התגים בצד השרת היא הפקודה config של תג האתר ששולח נתונים למאגר הזה. |
|
התאמה אישית של שמות קובצי Cookie |
במקרה כזה משתנה השם של קובץ ה-Cookie מהדומיין הנוכחי שמשויך למצב הסשן ומזהה הלקוח. |
לא ניתן לקשר בין משתמשים בסשנים שונים, ולא ניתן לכלול אירועים בסשנים. כשמנתחים את מדדי האירועים עם מאפייני משתמש או סשן, הערך (not set) מופיע במדדים האלה. |
מומלץ להשתמש באותה תוספת לשמות של קובצי Cookie באתר. כשמשתמשים בתוספת לשמות של קובצי Cookie ב-Analytics, מומלץ ליצור שם בהתאמה אישית לקובץ ה-Cookie, ולא ליצור כמה מאגרי סילו של קובצי Cookie (זה מה שקורה אם משתמשים בתוספות שונות או לא עקביות לשמות של קובצי ה-Cookie). |
|
מנגנון אוטומטי לקישור בין דומיינים |
ההגדרה הזו מנחה את התג לעבד את נתוני הסשן והלקוח מהדף הקודם (אם הם זמינים) ולהתחיל להשתמש בהם. כשהתג מתחיל להשתמש בנתונים המקושרים, ההנחה היא שהסשן כבר התחיל בדף הקודם. |
אם מנגנון הקישור יופעל מאוחר ויזהה משתמש מדומיין שונה דרך פקודת config מאוחרת, זהות המשתמש תשתנה באופן פתאומי ברגע הזה. במקרה הכי קל, פקודות config מאוחרות מובילות לסשנים קצרים שנמחקים כשהמערכת מתחילה להשתמש בערכים של פרמטר הקישור. כל מאפייני המשתמש או הסשן שכבר נשלחו עד לשלב הזה לא ישויכו יותר למשתמש האמיתי או לסשן האמיתי. |
אל תתאימו אישית את מזהה הסשן או הלקוח. פעולה כזו מובילה להנחות שגויות בתגים ובתהליך העיבוד לגבי המבנה של הסשנים, והיא יכולה גם לגרום לבעיות. |
|
מנגנון ידני לקישור בין דומיינים |
כדי לאפשר ללקוחות להטמיע מדידה בכמה דומיינים באופן ידני, לתג GA4 יש ממשקי API כדי לקבל ולהגדיר את מזהה הלקוח ואת מזהה הסשן. שינוי בלתי מכוון של הערכים האוטומטיים של |
אם אירועים לא מקושרים יותר למזהים המקוריים של הלקוח והסשן, ייתכן שיהיה חסר בהם מידע חשוב ושייגרמו בעיות בלתי צפויות בשיוך (Attribution). |
מומלץ להשתמש ב- אל תשתמשו בממשקי ה-API האלה כדי לשנות את מזהה הלקוח או מזהה הסשן. לא כדאי להגדיר את המזהים האלה באופן ידני, אלא אם מדובר במקרים חריגים שדורשים הגדרה ידנית בכמה דומיינים. |
1 linker הוא הפרמטר מקישור אוטומטי בין דומיינים. אם באתר שלכם אי אפשר לבצע קישור אוטומטי בין דומיינים, אפשר להגדיר ידנית מזהה לקוח ומזהה סשן. אל תשנו את הערכים האלה אף פעם. מערכת GA4 מצפה לקבל ערכים בפורמט מסוים, וערכים בלתי צפויים עלולים לגרום לשיבושים. מידע נוסף על פרמטר הקישור