למה תרגיל ולא מבחן ידע?
הידע התיאורטי על GA4 נמצא בכל מקום. מה שמפריד בין צוות שמשתמש בכלי לצוות שמסתכל עליו הוא היכולת לפתוח דוח, לראות מספר שלא מסתדר ולדעת מה לעשות אחר כך. בתרגיל שלנו המשתתף לא נדרש להגדיר שום דבר. הוא נדרש לקרוא נתונים קיימים, לזהות פער בין שני מספרים שאמורים להיות קרובים ולהסביר מאיפה הפער מגיע. זו בדיוק העבודה שמנהל שיווק עושה כשהוא מקבל דוח חודשי שלא מסתדר עם הנתונים של מערכת הפרסום.
חשבון הדמו מתאים לזה משתי סיבות. הראשונה היא שכל אחד יכול להיכנס אליו תוך דקה, בלי להעניק הרשאות לנכס אמיתי של הארגון. השנייה היא שלפי התיעוד הרשמי, ההרשאה בחשבון היא Viewer בלבד: אפשר לסנן טבלאות, להוסיף מימד משני, ליצור Explorations אישיים, אבל אי אפשר לייצא דוחות, להשתמש בטכניקת User explorer או לשלוף נתונים דרך Data API. המגבלות האלה מכריחות את המשתתף לעבוד בתוך הממשק. זה בדיוק מה שאנחנו רוצים לבדוק.
הנתונים בחשבון משתנים כל יום. לכן המספרים שמופיעים במדריך הזה הם נתוני דמו להדגמת השיטה, לא ערכים שצריכים להתאים למה שהמשתתף יראה. הדבר שחוזר על עצמו הוא סוג הפער, לא גודלו.
איך מכינים את התרגיל?
לפני שמתחילים, מגדירים שלושה דברים זהים לכל המשתתפים. טווח תאריכים אחד של 28 ימים שהסתיים לפני לפחות 48 שעות, כי לפי Google נתוני היומיים האחרונים עדיין בעיבוד ויכולים להשתנות בין דוח ל-Exploration. נכס אחד, Google Merchandise Store בלבד, בלי נכס Flood-It של האפליקציה. ומסמך תשובות אחד, שבו המשתתף כותב לכל תחנה שלושה דברים: המספרים שמצא, ההסבר שלו לפער והפעולה שהיה מבצע בחשבון אמיתי. אנחנו מקצים לתרגיל 90 דקות ולא מאפשרים שימוש בחומר עזר, כי המטרה היא לראות איך המשתתף מתמצא בממשק ולא כמה מהר הוא מחפש בגוגל.
- תחנה 1 - סשנים מול משתמשים. פותחים את דוח User acquisition ואת דוח Traffic acquisition ומשווים את מספר המשתמשים לערוץ Organic Search בשני הדוחות.
- תחנה 2 - אירוע שנעלם. פותחים את דוח Events ובודקים את אירועי משפך הרכישה לאורך התקופה, יום אחרי יום.
- תחנה 3 - המרה שנספרת פעמיים. משווים את מספר אירועי purchase, את מספר אירועי המפתח ואת מספר העסקאות בדוח Ecommerce purchases.
- תחנה 4 - (not set) ו-Unassigned. בדוח Traffic acquisition מאתרים את שורת Unassigned ובדוח Landing page את שורת (not set) ומסבירים כל אחת.
- תחנה 5 - דוח רגיל מול Exploration. בונים Exploration חופשי עם אותם מימדים ומדדים של דוח Traffic acquisition ומסבירים כל הבדל במספרים.
איך נראית מפת התרגיל?
הדיאגרמה מציגה את חמש התחנות לפי הסדר, עם הדוח שבו עובדים בכל תחנה. הסדר מכוון: מתחילים ממדדי הבסיס, עוברים לאירועים ולהמרות ומסיימים בהשוואה בין שני משטחי הדיווח, שדורשת את כל מה שנלמד קודם.
מפת התרגיל
חמש תחנות אבחון בחשבון הדמו של GA4
חשבון הדמו: Google Merchandise Store, 28 ימים, הרשאת Viewer.
(not set) ו-UnassignedTraffic acquisition, Landing pageמה המשתתף אמור למצוא בכל תחנה?
תחנה 1: למה מספר המשתמשים שונה בין שני דוחות רכישה?
המשתתף פותח את דוח User acquisition ורואה את ערוץ Organic Search עם מספר משתמשים מסוים. אחר כך הוא פותח את Traffic acquisition ומוצא לאותו ערוץ מספר אחר, לרוב גבוה יותר. לצידו מופיע מספר סשנים גבוה עוד יותר. דוגמה לנתוני דמו: 18,400 משתמשים בדוח הראשון, 21,900 משתמשים ו-27,300 סשנים בשני. התשובה הנכונה מתחילה בהיקף המימד. User acquisition משתמש במימד First user default channel group, שמייחס את המשתמש לערוץ שדרכו הגיע בפעם הראשונה אי פעם. Traffic acquisition משתמש במימד Session default channel group, שמייחס כל סשן בנפרד. משתמש שהגיע לראשונה מפייסבוק וחזר מחיפוש אורגני נספר בפייסבוק בדוח הראשון ובאורגני בשני. התשובה המלאה מוסיפה שעמודת Users בדוחות הרגילים היא Active users, כלומר רק משתמשים שהיה להם סשן מעורב או אירוע first_visit או פרמטר engagement_time_msec. זה לא Total users.
תחנה 2: איזה אירוע במשפך נעלם ומתי?
המשתתף פותח את דוח Events, בוחר את אירועי משפך הרכישה (view_item, add_to_cart, begin_checkout, add_shipping_info, add_payment_info, purchase) ומוסיף מימד משני של תאריך או משווה בין שתי תקופות. המשימה היא לזהות אירוע שנפחו לא עקבי עם השלבים הסמוכים לו, למשל שלב באמצע המשפך שמציג בימים מסוימים נפח נמוך בהרבה משלב שבא אחריו, או אפס. במשפך תקין כל שלב קטן מהשלב שלפניו. אירוע באמצע שקטן מהאירוע שאחריו הוא אירוע שחסר, לא משתמשים שדילגו עליו. בחשבון אמיתי זה נראה כמו שינוי טריגר ב-GTM, גרסת אתר חדשה ששינתה את מבנה העמוד או טעינה של התג אחרי שהמשתמש כבר עבר לעמוד הבא. התשובה הטובה כוללת את התאריך שבו הפער התחיל, כי זו הנקודה שממנה מתחילים לחפש בהיסטוריית הגרסאות של הקונטיינר.
תחנה 3: האם המרה נספרת פעמיים?
כאן המשתתף משווה שלושה מספרים לאירוע purchase: Event count בדוח Events, Key events באותו דוח ו-Transactions בדוח Ecommerce purchases. במקביל הוא נכנס ל-Admin, לרשימת Key events ובודק את שיטת הספירה של purchase: Once per event או Once per session. התובנה שאנחנו מחפשים היא ש-GA4 מאחד אירועי purchase עם אותו transaction_id בזרמי web. לכן העסקאות יהיו נמוכות או שוות למספר האירועים, אבל לא גבוהות ממנו. פער גדול בין Event count לבין Transactions מעיד על purchase שנשלח יותר מפעם אחת עם מזהה שונה, או בלי מזהה בכלל. בחשבון הדמו הפער קטן. בחשבונות של ארגונים הוא לרוב התוצאה של תג רכישה שיורה גם מהקוד וגם מ-GTM, או של עמוד תודה שנטען מחדש. המשתתף שמוסיף שאירוע מפתח של ליד, שאין לו transaction_id, לא יקבל את ההגנה הזו, מראה שהוא מבין את המנגנון ולא רק את המקרה.
תחנה 4: מה מסתתר מאחורי Unassigned ו-(not set)?
בדוח Traffic acquisition המשתתף מאתר את שורת Unassigned ומוסיף מימד משני Session source / medium. בדוח Landing page הוא מאתר את שורת (not set). שתי השורות מופיעות בחשבון הדמו באופן קבוע. ההסבר הנכון מפריד בין שני מקרים. Unassigned הוא ערוץ: לפי Google, זהו הערך שמופיע כשאף חוק מחוקי קבוצת הערוצים לא מתאים לנתוני המקור והמדיום. מדיום כמו newsletter או banner שלא תואם לאף הגדרה ייפול לשם. (not set) הוא ערך של מימד: Google מגדירה אותו כשם מציין מקום שמופיע כש-Analytics לא קיבל מידע למימד. בעמוד נחיתה הוא מופיע כשלסשן אין אירוע page_view. במקור הסשן הוא מופיע כשחסר אירוע session_start. במקרה הזה הסשן גם נופל ל-Unassigned. המשתתף הטוב יודע להציע תיקון שונה לכל מקרה: תקנון UTM לערוץ ושינוי סדר הטעינה של התגים לסשנים.
תחנה 5: למה Exploration מראה מספר אחר מהדוח?
המשתתף בונה Free-form exploration עם המימד Session default channel group והמדדים Sessions ו-Total users ומשווה לדוח Traffic acquisition על אותו טווח. בדרך כלל הוא יראה שלושה הבדלים. הראשון הוא ש-Users בדוח הוא Active users ובחקירה הוא בחר Total users. לכן המספרים לא זהים. השני הוא שטווח התאריכים ב-Exploration מוגבל להגדרת שמירת הנתונים של הנכס, בעוד שהדוחות המצטברים לא מוגבלים אליה. השלישי הוא שחקירה שעוברת 10 מיליון אירועים בנכס רגיל נדגמת. בנוסף, סף פרטיות יכול להסתיר שורות בשני המשטחים. התשובה הטובה כוללת גם את ההערה ש-Google עצמה מציינת שנתוני 48 השעות האחרונות עלולים להיות שונים בין שני המשטחים. הערה נוספת: החיפוש בטבלת הדוח אינו רגיש לאותיות גדולות וקטנות, בעוד שסינון ב-Exploration רגיש.
איך נראית טבלת הפתרון?
הטבלה היא כלי לבודק, לא למשתתף. היא מרכזת לכל תחנה את מה שצריך להימצא, את ההסבר הנכון ואת התשובה השגויה שאנחנו שומעים לרוב.
| תחנה | מה אמור להימצא | ההסבר הנכון | תשובה שגויה שכיחה |
|---|---|---|---|
| 1 | משתמשים שונים לאותו ערוץ בשני דוחות, סשנים גבוהים משניהם | היקף משתמש (First user) מול היקף סשן (Session). Users בדוחות הם Active users | "יש באג בדוח" או "משתמש אחד נספר פעמיים" |
| 2 | שלב משפך קטן מהשלב שאחריו, החל מתאריך מסוים | האירוע לא נשלח, לא דילגו עליו. נקודת ההתחלה מצביעה על שינוי בהטמעה | "המשתמשים דילגו על השלב" או התעלמות מהתאריך |
| 3 | Event count, Key events ו-Transactions של purchase, שיטת הספירה ב-Admin | transaction_id מאחד רכישות כפולות בזרם web. פער בין אירועים לעסקאות הוא שליחה כפולה עם מזהה שונה או ריק | "אם זה Once per session אין בעיה" בלי לבדוק את המזהה |
| 4 | שורת Unassigned בערוצים ושורת (not set) בעמוד נחיתה | Unassigned: מדיום שלא תואם חוק ערוץ. (not set): סשן ללא page_view או ללא session_start | הסבר אחד לשני המקרים, או "זה בוטים" |
| 5 | Users שונים ולעיתים טווח תאריכים חסר ב-Exploration | Active מול Total users, שמירת נתונים, דגימה מעל 10 מיליון אירועים, סף פרטיות, 48 שעות עיבוד | "Exploration יותר מדויק" או "הדוח יותר מדויק" בלי לנמק |
איך מעריכים את התוצאות?
אנחנו נותנים לכל תחנה ציון בין 0 ל-3. נקודה אחת על מציאת הפער עם המספרים הנכונים, נקודה שנייה על הסבר המנגנון במונחים של היקף, ספירה או מקור. נקודה שלישית ניתנת על פעולה נכונה שהיה מבצע בחשבון אמיתי. סך הכול 15 נקודות. הטבלה הבאה היא הסקאלה שאנחנו משתמשים בה.
| ציון | רמה | מה זה אומר בפועל | המלצה |
|---|---|---|---|
| 0 עד 5 | קורא דוחות | מזהה מספרים, לא מזהה פערים. מסתמך על הדוח כפי שהוא | הדרכת בסיס במודל הנתונים של GA4 לפני עבודה עצמאית |
| 6 עד 10 | מתפעל | מזהה פערים ומסביר חלק מהם. מתבלבל בין היקפים או בין דוח ל-Exploration | עבודה עצמאית בדוחות, אימות של מסקנות על ידי גורם נוסף |
| 11 עד 15 | מאבחן | מסביר כל פער במונחי המנגנון ומציע תיקון ממוקד | יכול להוביל בדיקת מדידה ולהנחות מפתחים |
שני דברים שאנחנו לא מודדים: מהירות ושימוש במונחים באנגלית. משתתף שלוקח את כל 90 הדקות ומגיע לתשובות מנומקות מקבל ציון גבוה יותר ממשתתף שמסיים בחצי שעה עם הסברים כלליים.
איך מתאימים את התרגיל לחשבון של הארגון?
אחרי שהצוות עבר את התרגיל על חשבון הדמו, חוזרים עליו על הנכס של הארגון. השינוי המרכזי הוא בהרשאות: בנכס של הארגון המשתתף יכול לקבל הרשאת Editor או Marketer ולראות גם את DebugView, את הגדרת שמירת הנתונים ואת היסטוריית השינויים. זה פותח תחנה שישית, שבה המשתתף מבצע רכישת בדיקה או שליחת טופס באתר ומוודא ב-DebugView שהאירוע נשלח פעם אחת, עם הפרמטרים הנכונים.
בחשבון של הארגון התחנות משתנות מעט. בתחנה 2 בוחרים את אירוע ההמרה המרכזי של הארגון ואת האירועים שלפניו במשפך, במקום משפך הרכישה של החנות. בתחנה 3 בודקים גם אירוע ליד שאין לו transaction_id. משווים את Key events למספר הפניות במערכת ה-CRM. בתחנה 4 מוסיפים בדיקה של הקמפיינים הפעילים: האם כל מדיום שהצוות משתמש בו תואם לאחד מחוקי קבוצת הערוצים. בתחנה 5 בודקים קודם כול מה הגדרת שמירת הנתונים של הנכס, כי אם היא עומדת על ברירת המחדל של חודשיים, רוב ה-Explorations של הארגון עובדים על נתונים חלקיים בלי שאף אחד שם לב.
כלל אחד נשאר קבוע: בתרגיל לא משנים שום הגדרה בנכס. מי שרוצה לתקן, רושם את התיקון במסמך התשובות ומבצע אותו אחרי התרגיל, עם תיעוד תאריך. כך אפשר לחזור על התרגיל כעבור חצי שנה ולמדוד שיפור.
מהן הטעויות הנפוצות בהעברת התרגיל?
השוואה על טווחי תאריכים שונים
משתתף שמשווה דוח של 28 ימים ל-Exploration שנפתח עם ברירת המחדל שלו יראה פער שאין לו שום משמעות. לפני כל השוואה מוודאים טווח זהה, כולל שעת סיום של היומיים האחרונים.
הסתמכות על מספרי הדמו של המדריך
הנתונים בחשבון הדמו מתעדכנים ברציפות. המספרים שמופיעים כאן הם דוגמה. הבודק צריך להריץ את התרגיל בעצמו יום לפני ולרשום את המספרים העדכניים לטבלת הפתרון.
דרישה למצוא "באג" בחשבון הדמו
רוב הפערים בחשבון הדמו הם תוצאה של הבדלי הגדרה, לא של תקלה. משתתף שמסיים כל תחנה במילים "זה שגוי" מפספס את העיקר. הניסוח שאנחנו מחפשים הוא "שני המספרים נכונים ומודדים דברים שונים. זה מה שכל אחד מהם מודד".
הערכה לפי מספרים בלבד
שני משתתפים יכולים להגיע לאותו מספר, אחד בניחוש ואחד בהבנה. לכן ההסבר שווה נקודה והפעולה שווה נקודה. המספר לבדו שווה רק שליש מהציון.
איך בודקים שהתרגיל עובד?
הבדיקה הראשונה היא על הבודק עצמו. לפני ההעברה, מריצים את חמש התחנות על טווח התאריכים שנבחר ומוודאים שכל פער שמופיע בטבלת הפתרון אכן נראה בחשבון באותו שבוע. אם שורת Unassigned נעלמה או שהמשפך נראה חלק, מחליפים את טווח התאריכים או את האירוע הנבדק.
הבדיקה השנייה היא על התוצאות. אם כל המשתתפים נכשלים באותה תחנה, הבעיה היא לרוב בניסוח המשימה ולא בידע. אם כולם מצליחים בכל התחנות, התרגיל קל מדי ומוסיפים לו את התחנה השישית על חשבון הארגון. הסימן שהתרגיל ממלא את תפקידו הוא שהציון מתפלג. סימן נוסף הוא שמי שקיבל ציון מאבחן מצליח גם בפועל להסביר להנהלה פער בדוח החודשי בלי לקרוא לנו.
אם אתם רוצים לבדוק את הצוות שלכם, או להעביר את התרגיל כחלק מהדרכה מובנית על הנכס של הארגון, אנחנו מעבירים הדרכות GA4 שמבוססות על השיטה הזו. פרטים בעמוד הדרכות ובעמוד GA4, או דרך טופס הקשר.
עוד מדריכים בנושא למידה והדרכה
מקורות
Analytics Help: Demo account, Analytics Help: What the value (not set) means in your reports, Analytics Help: Default channel group, Analytics Help: Data differences between reports and explorations, Analytics Help: Minimize duplicate key events with transaction IDs
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי