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

Minhaz Kazi, יועץ למפתחים, Google Analytics – אפריל 2023

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

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

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

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

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

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

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

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

דגימות

להשוואה מדויקת בין נתוני הייצוא ב-BigQuery לדוחות רגילים, דוחות ה-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 שעות אחרי תאריך הטבלה עם אירועים שחותמים בחותמת זמן עם תאריך הטבלה. לקריאת פרטים נוספים בנושא הזה וראו דוגמאות. זאת בעיה גדולה יותר אם שה-SDK של Firebase או Measurement Protocol שולח אופליין או אירועים שמתעכבים. בהתאם לפלטפורמת הדיווח הרגילה ול-BigQuery מתעדכנים במהלך 72 השעות האלה, עשויים להיות הבדלים ביניהם. להטמעה כזו, צריך לבצע השוואות על נתונים ישנים יותר יותר מ-72 שעות.

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

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

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

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

הקיבוץ של השורה (other) קורה רק במודול הדיווח Data API כשהדוח חורג ממגבלת העוצמה (cardinality). אם מ-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 Export.

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

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

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

נתוני שיוך (Attribution) של תנועה

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

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

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

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