גישור על הפער בין ממשק המשתמש של Google Analytics לבין BigQuery Export

מינהאז קזי, יועץ למפתחים, Google Analytics – אפריל 2023

"אבל למה המספרים לא תואמים לממשק המשתמש?"

אם עבדתם עם נתוני ייצוא האירועים ב-BigQuery עבור נכס GA4, בטוח ששאלתם את השאלה הזו בשלב כלשהו. או יותר גרוע - מישהו אחר שאל אתכם את זה. תוך כדי ניסיון להשיב עליה, סביר להניח שנשאלתם את שאלת ההמשך המדאיגה הזו:

"ואיפה זה אומר?"

בפוסט הזה, ננסה להסביר את שניהם.

לפני שנפרט את ההבדלים במספרים, חשוב להבין את המטרה של נתוני הייצוא של האירועים ב-BigQuery. משתמשי Google Analytics שולחים את הנתונים שנאספו אל Google Analytics באמצעות אחת משיטות האיסוף – Google Tag , Google Tag Manager , Measurement Protocol , ערכות SDK וייבוא נתונים. על סמך הגדרות הנכס ב-Google Analytics, מערכת Google Analytics מוסיפה ערך משמעותי לנתונים שנאספו לפני שהם מגיעים לפלטפורמות הדיווח הרגילות, כולל דוחות רגילים, כלי הניתוחים ו-Data API. התוספות האלה של הערך יכולות לכלול הכללה של Google Signals, בניית מודלים, שיוך (Attribution) תנועה, חיזוי וכו'.

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

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

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

דגימות

כדי לבצע השוואה מדויקת בין נתוני הייצוא מ-BigQuery לדוחות רגילים, לדוחות Data API או לדוחות כלי הניתוחים, צריך לוודא שהם לא מבוססים על נתונים שנדגמו. דגימת נתונים ב-GA4 מספקת פרטים נוספים ודרכים לטפל בדגימה.

משתמשים פעילים

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

הטמעה טכנית

בנתוני הייצוא של האירועים ב-BigQuery, אם תספרו את מספר מזהי המשתמשים הייחודיים, תקבלו את הספירה של סה"כ משתמשים. הנה שאילתה לדוגמה שמציגה גם את 'סה"כ משתמשים' וגם את 'משתמשים חדשים' על סמך user_pseudo_id:

-- Example: Get 'Total User' count and 'New User' count.

WITH
  UserInfo AS (
    SELECT
      user_pseudo_id,
      MAX(IF(event_name IN ('first_visit', 'first_open'), 1, 0)) AS is_new_user
    -- Replace table name.
    FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
    -- Replace date range.
    WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20201130'
    GROUP BY 1
  )
SELECT
  COUNT(*) AS user_count,
  SUM(is_new_user) AS new_user_count
FROM UserInfo;

כדי לבחור רק משתמשים פעילים, צריך להגביל את השאילתה לאירועים שבהם is_active_user הוא true:

-- Example: Get exact and approximate Active User count.

WITH
  ActiveUsers AS (
    SELECT
      user_pseudo_id
    -- Replace table name.
    FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
    -- Replace date range.
    WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20201130'
      AND is_active_user
    GROUP BY 1
  )
SELECT
  COUNT(DISTINCT user_pseudo_id) AS exact_active_user_count,
  APPROX_COUNT_DISTINCT(user_pseudo_id) AS approx_active_user_count
FROM ActiveUsers;

HyperLogLog++

ב-Google Analytics נעשה שימוש באלגוריתם HyperLogLog++ (HLL++ ) כדי להעריך את העוצמה של מדדים נפוצים, כולל משתמשים פעילים וסשנים. כלומר, כשמציגים את המספר הייחודי של המדדים האלה בממשק המשתמש או דרך ה-API, מדובר באומדן עם רמת דיוק מסוימת. ב-BigQuery, מאחר שיש לכם גישה לנתונים המפורטים, אתם יכולים לחשב את העוצמה המדויקת של המדדים האלה. לכן המדדים יכולים להשתנות באחוז קטן. ברווח בר-סמך של 95%, הדיוק בספירת הסשנים עשוי להיות ±1.63%. רמות הדיוק ישתנו בהתאם למדדים שונים וישתנו בהתאם לרווחים ברי-הסמך. ראו את המאמר HLL++ Sketches לרמות הדיוק ברווחי בר-סמך שונים כדי לבדוק פרמטרים שונים של דיוק ב-HLL++.

הטמעה טכנית

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

עיכוב באיסוף הנתונים

הטבלאות של הייצוא היומי נוצרות אחרי שמערכת Google Analytics אוספת את כל האירועים שהתרחשו באותו יום. הטבלאות היומיות יכולות להתעדכן עד 72 שעות מעבר לתאריך הטבלה, ולכלול אירועים עם חותמת זמן של תאריך הטבלה. כאן תוכלו לקרוא פרטים נוספים ודוגמאות. זוהי בעיה גדולה יותר אם ההטמעה של Firebase SDK או Measurement Protocol שולחת נתונים על אירועים אופליין או אירועים עם עיכוב. יכול להיות שתראו הבדלים ביניהם במהלך 72 השעות האלה, בהתאם למועד שבו פלטפורמת הדיווח הרגילה ו-BigQuery מתעדכנים. לצורך הטמעה כזו, צריך להשוות בין נתונים מלפני יותר מ-72 שעות.

דוחות בעלי עוצמה גבוהה

נניח שאתם מציגים דוח דרך דוחות רגילים או דרך Data API. בדוח מוצגת כמות גדולה של נתונים ומאפיינים עם עוצמה (cardinality) גבוהה. מאפיינים בעלי עוצמה גבוהה עלולים לגרום לדוח לחרוג ממגבלת העוצמה של הטבלה הבסיסית. במקרה כזה, מערכת Google Analytics תקבץ ערכים בתדירות נמוכה יותר ותתייג אותם כ-(אחר).

בעזרת דוגמה פשוטה בקנה מידה קטן, אם מגבלת העוצמה של טבלת הבסיס היא 10 שורות, זה מה שצפוי לקרות:

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

קיבוץ השורה (other) מתבצע רק במודול הדיווח וב-Data API כשהדוח חורג ממגבלת העוצמה. אם תבצעו את החישובים מ-BigQuery, תמיד תקבלו את הנתונים האמיתיים – השורות המפורטות ביותר. מידע נוסף על השורה (אחר) ושיטות מומלצות למניעת ההצגה שלה

Google Signals

להפעלת Google Signals בנכס GA4 יש כמה יתרונות, כולל ביטול כפילויות של משתמשים בפלטפורמות ובמכשירים שונים. אם לא נאספים מזהי משתמשים או מפעילים את Google Signals ומשתמש מסוים צופה באתר שלכם בשלושה דפדפני אינטרנט שונים, מערכת Google Analytics תשייך את הפעילות הזו לשלושה משתמשים שונים, וב-BigQuery Export יהיו שלושה סוגים של user_pseudo_id. לעומת זאת, כש-Google Signals מופעל והאדם שמחובר לחשבון Google היחיד שלו בכל שלושת הדפדפנים, מערכת Google Analytics משייכת את הפעילות הזו למשתמש אחד ומשקף את המספר הזה בפלטפורמות הדיווח הרגילות. עם זאת, BigQuery עדיין יציג שלושה פריטי user_pseudo_id נפרדים כי המידע של Google Signals לא זמין בייצוא ל-BigQuery. לכן, סביר להניח שבדוחות עם נתונים של Google Signals תהיה פחות משתמשים בהשוואה ל-BigQuery Export.

הדרך הטובה ביותר לצמצם את ההשפעה הזו היא להטמיע מזהי User-ID בנכס GA4 ולהפעיל את Google Signals. כך תוכלו להבטיח שביטול הכפילויות יתבצע קודם בהתאם ל-user_id. עבור משתמשים שמחוברים לחשבון, השדה user_id יאוכלס ב-BigQuery ואפשר להשתמש בו למטרות חישוב. עם זאת, עבור משתמשים שלא מחוברים (כלומר סשנים ללא user_id), עדיין ייעשה שימוש ב-Google Signals לביטול כפילויות.

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

סטטוס הסכמה ונתונים לפי מודל

סטטוס ההסכמה באתרים ובאפליקציות לנייד מאפשר להעביר ל-Google את סטטוס ההסכמה של המשתמשים לשימוש בקובצי cookie או במזהי אפליקציות. אם המבקרים מסרבים להביע הסכמה, מערכת GA4 ממלאת את הפערים באיסוף הנתונים באמצעות בניית מודלים של אירועים מרכזיים ובניית מודלים התנהגותיים. הנתונים לפי מודל לא זמינים בייצוא האירועים ב-BigQuery. כשסטטוס ההסכמה מוטמע, מערך הנתונים ב-BigQuery יכיל פינגים ללא קובצי cookie שנאספו על ידי Google Analytics, ולכל סשן יהיה user_pseudo_id שונה. בעקבות בניית המודלים, יהיו הבדלים בין פלטפורמות הדיווח הרגילות לבין הנתונים המפורטים ב-BigQuery. לדוגמה, בגלל בניית מודל התנהגותי, יכול להיות שיכול להיות שתראו פחות מספר של משתמשים פעילים בהשוואה ל-BigQuery Export, מאחר שהמודלים עשויים לנסות לחזות שיהיו מספר סשנים ממשתמשים ספציפיים שלא הביעו הסכמה.

שוב, כדי לצמצם את ההשפעה הזו, כדאי להטמיע User-IDs בנכס GA4. user_id ומאפיינים מותאמים אישית מיוצאים ל-BigQuery ללא קשר לסטטוס ההסכמה של המשתמשים.

נתוני שיוך (Attribution) של תנועת גולשים

נתוני השיוך (Attribution) של תנועת גולשים ב-BigQuery זמינים ברמת המשתמש (ביקור ראשון) וברמת האירוע. אלה הנתונים שנאספים. עם זאת, מכיוון שמערכת Google Analytics מטמיעה מודל שיוך משל עצמה ברמת הסשן, המידע הזה לא זמין ישירות ב-BigQuery Export ולא ניתן לחשב אותו ברמת דיוק מלאה עם הנתונים הזמינים. בהתאם לתרחיש לדוגמה שלכם, תוכלו לשלב את מערך הנתונים ב-BigQuery עם כל הנתונים הרלוונטיים מאינטראקציה ישירה (First-Party) וליצור מודל שיוך משלכם. בעתיד, ייתכן שנתונים נוספים שייאספו לצורך שיוך תנועת גולשים יהיו זמינים דרך ייצוא האירועים ב-BigQuery.

שגיאות חישוב נפוצות

• שיטת חישוב: כשמחשבים מדדים שונים ב-BigQuery, צריך לוודא שאתם משתמשים במתודולוגיה הנכונה. לדוגמה:
  • השיטה הרגילה לספירת סשנים בנכסי Google Analytics 4 היא ספירה של השילובים הייחודיים של user_pseudo_id/user_id ו-ga_session_id, ללא קשר למסגרת הזמן. ב-Universal Analytics, הסשנים יתאפסו בחצות. אם משתמשים במודל UA, מחשבים סשנים לכל יום ומוסיפים אותם כדי לקבל את המספר הכולל של הסשנים, סופרים פעמיים את הסשנים שמתפרשים על פני כמה ימים.
  • בהתאם לזיהוי של מי שמדווח, תצטרכו לעדכן את שיטת החישוב של מספר המשתמשים.
• היקף מאפיין ומדד: מוודאים שהחישובים משתמשים בהיקף הנכון ברמת המשתמש, הסשן, הפריט או האירוע.
• Time Zone: בייצוא ב-BigQuery, הערך event_date מייצג את אזור הזמן לדיווח, ואילו event_timestamp היא חותמת זמן לפי שעון UTC במיליוניות השנייה. לכן, במקרה שבו משתמשים בערך event_timestamp בשאילתה, צריך להתאים אותו לאזור הזמן הנכון לדיווח כשמשווים אותו למספרים בממשק המשתמש.
• מגבלות לסינון ולייצוא של נתונים: אם הגדרתם סינון נתונים לייצוא האירועים ב-BigQuery, או שנפח הייצוא היומי של האירועים שלכם חרג מהמגבלה, נתוני הייצוא של האירועים ב-BigQuery לא יתאימו לפלטפורמות הדיווח הרגילות.

עם כל זה, יש קצת על UNNEST בפוסט הזה. אני מקווה שתוכלו לבחור את הפתרונות המתאימים לפרויקט DISTINCT שלכם מההנחיות שכאן. אם יש לכם שאלות, אתם יכולים להצטרף לשרת GA Discord שבו שאילתות יתקבלו בברכה.