למה הדשבורד ב-Looker Studio לא תואם לדוח ב-GA4?
GA4 שומר את הנתונים של כל נכס בשתי קבוצות טבלאות. קבוצה אחת היא טבלאות מצטברות (aggregate tables) שמחזירות תשובה מהירה ולא מדוגמת לשאלות הנפוצות. הקבוצה השנייה היא טבלאות ברמת האירוע והמשתמש, שמשרתות שאלות גמישות וחד פעמיות. הדוחות הסטנדרטיים בממשק נשענים על הטבלאות המצטברות. Explorations נשענים על הטבלאות הגרנולריות. Data API, שדרכו עובד מחבר GA4 של Looker Studio, בוחר לכל בקשה את הטבלה שתיתן את התוצאה המדויקת ביותר במסגרת הגדרות הדגימה של הנכס.
המשמעות היא ששלושה משטחי דיווח של אותו נכס עוברים שלושה מסלולי עיבוד שונים. התיעוד של Google למחבר מנסח את זה במשפט אחד: Looker Studio תואם לנתונים בדוחות של Google Analytics, לא ל-Explorations. מי שמשווה דשבורד ל-Exploration מתחיל מנקודת פתיחה שבה פער הוא התוצאה הצפויה.
בפרויקטים שלנו הממצא החוזר הוא שרוב הפער נוצר בתוך Looker Studio ולא בתוך GA4. ההגדרות של הדשבורד, השדות המחושבים, ה-blending ובחירת הממדים אחראים לרוב נקודות האחוז. הגורמים שמקורם ב-GA4 עצמו, דגימה וספי פרטיות, מייצרים בדרך כלל פער קטן ויציב שאפשר להסביר אבל לא לסגור. לכן סדר האבחון חשוב: קודם מנקים את הדשבורד, אחר כך מסבירים את מה שנשאר.
איך הנתונים זורמים מ-GA4 ל-Looker Studio?
הדיאגרמה מתארת את מסלול הנתונים מאיסוף האירועים ב-GA4 עד לגרף בדשבורד. ארבעת משטחי הדיווח של GA4 מופיעים באמצע: דוחות סטנדרטיים, Explorations, Data API ויצוא ל-BigQuery. רק שניים מהם מגיעים ל-Looker Studio. חמש הנקודות הממוספרות הן המקומות שבהם המספר משתנה בדרך.
מסלולי נתונים
ארבעה מסלולים מ-GA4 ומה משתנה בכל אחד
- 1זהות דיווח: Blended מוסיף משתמשים ממודלים, Device-based לא
- 2בחירת טבלה: דגימה מעל 10 מיליון אירועים, שורת
(other) - 3ספי פרטיות על ממדים דמוגרפיים, מכסות Data API
- 4מטמון 12 שעות, שדות מחושבים, blending, scope של ממדים
- 5BigQuery: בלי מידול, בלי Google signals, בלי ייחוס מבוסס נתונים
מהם תשעת הגורמים לפער ואיך מאבחנים כל אחד?
הטבלה הבאה היא כלי האבחון שאנחנו עובדים איתו. מתחילים מהסימפטום שרואים בדשבורד, מזהים את הגורם ומקבלים סדר גודל של הפער שהוא אמור להסביר. אם הפער בפועל גדול בהרבה מהצפוי, הגורם הזה לא מספיק ויש לעבור לשורה הבאה. גדלי הפער הם הערכות אוריינטציה מהניסיון שלנו ולא מספרים מהתיעוד. הם משתנים בין נכסים.
| הסימפטום בדשבורד | הגורם | גודל פער צפוי | מה עושים |
|---|---|---|---|
| סכומים גדולים כמו סשנים ואירועים נמוכים מהדוח, בעיקר כשיש פילטר לפי מדינה או טווח תאריכים ארוך | דגימה. השאילתה דרך Data API עברה את מכסת 10 מיליון האירועים לנכס סטנדרטי (100 מיליון כברירת מחדל ב-360). Looker Studio לא מציג אייקון דגימה | 1 עד 5 אחוז, גדל עם מורכבות הפילטר | מקצרים את טווח התאריכים, מורידים ממדים מהטבלה, פותחים את הדוח המקביל ב-GA4 ובודקים אם אייקון איכות הנתונים מציג דגימה. בנכסים גדולים עוברים ל-BigQuery |
| שורות נעלמות בטבלה עם גיל, מגדר או תחומי עניין. סכום השורות נמוך מהסה"כ | ספי פרטיות (data thresholds). GA4 מסתיר שורות עם מעט משתמשים כדי שלא ניתן יהיה לזהות אדם. התיעוד מציין במפורש שהספים חלים גם על קריאות API | בשורות הקטנות עד 100 אחוז. בשורת הסה"כ אפס | מרחיבים טווח תאריכים, מוציאים ממדים דמוגרפיים מטבלאות מפולחות, לא מסכמים שורות ידנית. הספים נקבעים על ידי המערכת ואי אפשר לשנות אותם |
| מספר המשתמשים הפעילים שונה בין הדשבורד לדוח. הפער משתנה מיום ליום | זהות דיווח. ב-Blended נכנסים משתמשים ממודלים עבור מי שדחה עוגיות. Observed לא כולל מידול. Device-based סופר רק Client ID. הדשבורד מציג את ההגדרה הנוכחית אבל מהמטמון | 5 עד 15 אחוז במשתמשים באתר עם באנר הסכמה (הערכה) | מתעדים את הגדרת זהות הדיווח ואת תאריך כל שינוי. מרעננים את הדשבורד אחרי שינוי. משווים רק כששתי המערכות באותה הגדרה |
| שורת (other) בטבלת עמודים או מוצרים, או ערכים שקיימים בדוח וחסרים בדשבורד | קרדינליות. ממד עם יותר מ-500 ערכים ייחודיים ביום מעלה את מספר השורות, הטבלה חורגת ממגבלת השורות והערכים הנדירים מתאחדים | הסה"כ נכון. הפילוח חסר בזנב הארוך | מקצרים טווח, מצמצמים ממדים משניים, לא רושמים ממדים מותאמים לערכים ייחודיים כמו מזהה הזמנה. לפילוח מלא עוברים ל-BigQuery |
| הפילוח לפי מקור ומדיום שונה לחלוטין מדוח Traffic acquisition, אבל הסה"כ זהה | scope שגוי של הממד. Source / medium הוא ברמת אירוע ומתאים לאירועי מפתח. Session source / medium הוא ברמת סשן. First user source / medium הוא ברמת משתמש | עשרות אחוזים בשורות הפילוח. אפס בסה"כ | לסשנים משתמשים רק ב-Session source / medium. לרכישת משתמשים ב-First user. בממד ברמת אירוע משתמשים רק עם אירועי מפתח ועם מודל הייחוס של הנכס בראש |
| שיעור המרה, Engagement rate או ממוצע בשורת הסיכום לא תואמים לאף מספר ב-GA4 | שדה מחושב על מדד יחס. SUM על אחוז, ממוצע של ממוצעים, או שימוש במדד שה-Auto aggregation שלו קבוע בתוך נוסחה | לא ניתן לחיזוי. יכול להיות קטן בשורה ועצום בסיכום | מחשבים כל יחס מהרכיבים: SUM של אירועי מפתח חלקי SUM של סשנים. לא משנים אגרגציה של מדדי GA4, Looker Studio לא מאפשר את זה בכל מקרה |
| סשנים קפצו אחרי blending עם נתוני עלות, או שגיאת "Unable to aggregate ratio metrics" | blending מצרף שורות לפי מפתח ומסכם מחדש. סשן שמתאים לכמה שורות בצד השני נספר כמה פעמים. מדדי יחס לא ניתנים לצירוף כלל | 10 עד 100 אחוז כלפי מעלה | בודקים את המספר בטבלה פשוטה בלי blending לפני הצירוף. מצרפים רק לפי תאריך או מפתח ייחודי אחר. מעבירים מדדי יחס לחישוב אחרי הצירוף |
| הדשבורד "מאחר" אחרי GA4, או שהמספרים של היום ושל אתמול לא תואמים | מטמון ועיבוד. מחבר GA4 מתרענן כל 12 שעות כברירת מחדל. ל-GA4 עצמו נדרשות עד 48 שעות לסיים עיבוד של יום | עד כמה אחוזים ב-48 השעות האחרונות, אפס בחודש סגור | לא משווים את היום הנוכחי ואת אתמול. משווים חודש קלנדרי שנסגר לפני לפחות שלושה ימים. לפני בדיקה מרעננים ידנית את הנתונים |
| גרפים לא נטענים, שגיאת quota, חלק מהכרטיסיות ריקות אחרי שהדשבורד נפתח אצל כמה צופים | מכסות Data API: 40 אלף טוקנים לשעה ו-200 אלף ליום לנכס סטנדרטי, 10 בקשות במקביל. כל גרף שלא נטען מהמטמון צורך טוקנים | אין פער, יש חוסר. חלק מהנתונים לא מוצגים | עוברים ל-credentials של הבעלים כדי שכל הצופים יחלקו מטמון, מאחדים למקור נתונים אחד, מצמצמים גרפים בעמוד, או מעבירים ל-Extract Data או ל-BigQuery |
איך נראית בדיקת התאמה בטבלה פשוטה? (נתוני דמו)
לפני שמחפשים גורם מתוך התשעה, צריך נקודת ייחוס. אנחנו בונים בכל דשבורד עמוד נסתר עם טבלה אחת: מקור הנתונים הוא אותו נכס GA4, הממד היחיד הוא תאריך, המדדים הם Sessions, Total users, Event count ו-Key events. בלי פילטר, בלי blending, בלי שדה מחושב, בלי בקרת טווח תאריכים. טווח התאריכים קבוע לחודש קלנדרי שנסגר. את שורת הסיכום משווים לשורת הסה"כ של דוח Traffic acquisition ב-GA4 באותו טווח. את המשתמשים משווים מול דוח User acquisition.
הטבלה הבאה היא דמו, לא נתוני לקוח. היא מראה איך הטבלה הפשוטה מתאימה ואיך כל תוספת לטבלה פותחת פער שאפשר לשייך לגורם אחד.
| המדד והמצב | GA4, דוח סטנדרטי | Looker Studio | פער | פירוש |
|---|---|---|---|---|
| Sessions, טבלה פשוטה | 48,210 | 48,210 | 0 | תקין. סשנים נספרים זהה בשני המסלולים |
| Event count, טבלה פשוטה | 612,884 | 612,884 | 0 | תקין |
| Key events, טבלה פשוטה | 1,942 | 1,942 | 0 | תקין |
| Total users, טבלה פשוטה | 31,560 | 31,398 | 0.5 אחוז למטה | תקין. ספירת משתמשים ייחודיים היא הערכה (HLL++) עם סטייה של פחות מאחוז לפי Google |
| Total users, אחרי הוספת ממד Gender | 31,560 | 27,980 (סכום השורות) | 11 אחוז למטה | ספי פרטיות הסתירו שורות קטנות. גורם 2 בטבלת האבחון |
| Sessions, אחרי blending עם עלות לפי קמפיין | 48,210 | 57,340 | 19 אחוז למעלה | סשנים שהתאימו לכמה שורות עלות נספרו שוב. גורם 7 |
| Sessions לפי Source / medium, שורת google / cpc | 12,400 (Session source / medium) | 9,150 | 26 אחוז למטה | scope ברמת אירוע במקום ברמת סשן. גורם 5 |
המסקנה מהדמו היא שהטבלה הפשוטה היא מכשיר המדידה, לא הדשבורד. כשארבעת המספרים הבסיסיים תואמים, GA4 ו-Looker Studio מסתכלים על אותם נתונים. כל פער שמופיע אחרי כן נוצר בשלב שהוספנו. לכן אפשר לבודד אותו. כשהטבלה הפשוטה עצמה לא תואמת, הבעיה היא במקור הנתונים: נכס שגוי, זרם נתונים שונה, אזור זמן או טווח תאריכים שלא נבחר נכון.
מתי עוברים ל-BigQuery כמקור לדשבורד?
יצוא GA4 ל-BigQuery הוא המסלול היחיד שלא עובר דגימה, לא מסתיר שורות בגלל ספי פרטיות ולא מאחד ערכים לשורת (other). הוא גם לא מקבל את התוספות ש-GA4 מוסיף לנתונים. לפי טבלת ההשוואה של Google בין משטחי הדיווח, ב-BigQuery אין מידול התנהגותי, אין מידול של אירועי מפתח ואין ייחוס מבוסס נתונים. הייחוס ביצוא היומי הוא קליק אחרון נצפה בלבד. נתוני Google signals לא מיוצאים. היצוא היומי לנכס סטנדרטי מוגבל למיליון אירועים ביום, היצוא הרציף (streaming) לא מוגבל אבל מוגדר כשירות best effort.
על החיבור עצמו, מה בדיוק מקבלים בו ומה הוא עולה כתבנו בהרחבה במדריך ייצוא GA4 ל-BigQuery. על שלושת המנגנונים שמשנים את המספר בממשק עצמו אפשר לקרוא בספי נתונים, דגימה ושורת (other) ב-GA4.
| מאפיין | מחבר GA4 (Data API) | מחבר BigQuery |
|---|---|---|
| דגימה | אפשרית מעל 10 מיליון אירועים לשאילתה | אין |
| ספי פרטיות | חלים על ממדים דמוגרפיים | אין, אבל גם אין נתונים דמוגרפיים |
| שורת (other) | אפשרית בממדים בקרדינליות גבוהה | אין |
| מידול התנהגותי וזהות דיווח | כלול לפי הגדרת הנכס | לא כלול. משתמשים שדחו עוגיות מופיעים כפינגים ללא עוגייה |
| ייחוס | מבוסס נתונים או לפי הגדרת הנכס | קליק אחרון נצפה בלבד |
| עדכניות | מטמון 12 שעות, עיבוד GA4 עד 48 שעות | יצוא יומי פעם ביום, streaming תוך דקות |
| מגבלות | מכסות טוקנים לשעה וליום | מיליון אירועים ביום ביצוא היומי, עלויות אחסון ושאילתות |
| תחזוקה | אין | SQL, טבלאות ביניים, בדיקות שלמות |
ההמלצה שלנו היא לעבור ל-BigQuery כמקור לדשבורד בארבעה מצבים. הראשון: אייקון הדגימה מופיע באופן קבוע בדוחות המקבילים ב-GA4, או שהנכס מייצר יותר מ-10 מיליון אירועים בטווח התאריכים שהדשבורד מציג. השני: שורת (other) מופיעה בטבלאות עמודים, מוצרים או קמפיינים שההנהלה צריכה לקרוא עד השורה האחרונה. השלישי: שגיאות מכסה חוזרות למרות credentials של הבעלים ומקור נתונים מאוחד, בדרך כלל בדשבורדים עם עשרות צופים. הרביעי: צורך לחבר נתוני GA4 ברמת האירוע לנתוני CRM, מלאי או עלות, או לבנות הגדרת סשן ומסע משתמש שונים מאלה של GA4.
לא עוברים ל-BigQuery כשהדשבורד נועד למדידת מדיה ולייחוס. במקרה הזה המרות ממודלות וייחוס מבוסס נתונים הם לב הדיווח. הם קיימים רק במסלול של Data API. גם לא עוברים כשהטבלה הפשוטה תואמת והבעיה היא בשדות מחושבים: BigQuery לא מתקן נוסחה שגויה, הוא רק מייקר אותה. בכל מקרה חשוב להבין שהמספרים מ-BigQuery לא ישתוו למספרים בממשק GA4 בתכנון. מי שעובר צריך להחליט מקור אמת אחד לכל דוח ולכתוב אותו בכותרת.
אילו טעויות נפוצות מגדילות את הפער שלא לצורך?
השוואה ל-Exploration במקום לדוח סטנדרטי
Explorations נשענים על טבלאות ברמת האירוע ומוסיפים segments ו-comparisons שלא קיימים במחבר GA4 כלל. התיעוד של Google מציין במפורש ש-Looker Studio תואם לדוחות ולא ל-Explorations. הבסיס להשוואה הוא תמיד דוח סטנדרטי באותו טווח תאריכים.
סיכום של משתמשים לאורך ימים
Total users של חודש הוא לא סכום Total users של 30 ימים, כי אותו משתמש חוזר בימים שונים. Looker Studio מחשב את שורת הסיכום מחדש מול ה-API על כל הטווח. לכן היא נכונה. מי שמייצא את הטבלה ל-Google Sheets ומסכם את העמודה מקבל מספר גבוה בעשרות אחוזים. אותו דבר קורה בשדה מחושב שמסכם משתמשים.
שימוש ב-Source / medium בלי לבדוק scope
ברשימת השדות של מחבר GA4 יש שלוש גרסאות לכל ממד תנועה. השדה הקצר Source / medium נראה כמו הבחירה הטבעית אבל הוא ברמת אירוע. הוא מחולק לפי מודל הייחוס של הנכס. פילוח סשנים לפי השדה הזה יניב מספרים שלא קיימים באף דוח ב-GA4.
פילטרים ובקרות ששכחו
פילטר ברמת הדוח, פילטר ברמת העמוד, בקרת טווח תאריכים עם ברירת מחדל שונה ו-credentials של הצופה במקום הבעלים משנים את המספר בלי שרואים זאת בגרף. לפני כל השוואה פותחים את הגדרות הדשבורד ועוברים על שלוש השכבות.
אזורי זמן ב-BigQuery
בטבלאות היצוא event_date הוא לפי אזור הזמן של הנכס, אבל event_timestamp הוא ב-UTC. שאילתה שמחלקת ימים לפי timestamp בלי המרה תזיז אירועים בין ימים ותיצור פער יומי שנעלם בסיכום החודשי. בנוסף, שינוי אזור הזמן של הנכס עצמו משפיע על היצוא ועלול לייצר יום חסר או כפול.
איך בודקים שזה עובד?
הבדיקה שלנו היא שגרה חודשית קצרה ולא פרויקט. היא נשענת על עמוד ההתאמה הנסתר שתואר למעלה ועל שלוש פעולות בממשק GA4.
- קובעים את החודש. בוחרים חודש קלנדרי שנסגר לפני לפחות שלושה ימים. מרעננים ידנית את הנתונים בדשבורד כדי לעקוף את המטמון של 12 השעות.
- משווים ארבעה מספרים. Sessions, Event count, Key events ו-Total users בטבלה הפשוטה מול שורת הסה"כ בדוחות Traffic acquisition ו-User acquisition. סשנים ואירועים צריכים להתאים בדיוק. במשתמשים מקבלים סטייה של עד אחוז.
- בודקים את אייקון איכות הנתונים ב-GA4. אם הדוח המקביל מציג דגימה או ספים, הפער בדשבורד הוא תוצאה של GA4 ולא של Looker Studio. מתעדים את זה ולא מנסים לתקן בדשבורד.
- פותחים את Token Usage. בתפריט הדשבורד בודקים כמה טוקנים צרך הדף וכמה גרפים נטענו מהמטמון. גרף עם סימון אדום פנה ישירות ל-API. אם המספר קרוב למכסה השעתית, מצמצמים לפני שהצופים מגיעים.
- מתעדים הגדרות. זהות הדיווח הנוכחית, מודל הייחוס, אזור הזמן של הנכס ותאריך הבדיקה נכנסים לשורת טקסט בעמוד הנסתר. בחודש הבא משווים קודם את ההגדרות ורק אחר כך את המספרים.
הסימן שהעבודה הושלמה הוא לא התאמה מושלמת. הסימן הוא שהטבלה הפשוטה תואמת, שכל פער בגרפים המורכבים משויך לאחד מתשעת הגורמים ושההנהלה יודעת איזה מספר להסתכל עליו ולמה הוא שונה ממה שרואים בממשק GA4.
אם הדשבורד שלכם מציג מספרים שאף אחד לא מצליח להסביר, או שאתם שוקלים לעבור ל-BigQuery ולא בטוחים אם זה פותר את הבעיה הנכונה, אנחנו בונים ובודקים דשבורדים ב-Looker Studio עם עמוד התאמה מובנה ומתעדים כל פער עד לגורם הבודד. פרטים על השירות בעמוד דשבורדים ובעמוד GA4, או דרך טופס הקשר.
מקורות
Analytics Help: About data sampling, Analytics Help: About data thresholds, Analytics Help: Reporting identity, Analytics Help: Reporting surfaces comparison, Looker Studio Help: Connect to Google Analytics
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי