למה לשים אפליקציה ואתר באותו נכס?
לפי התיעוד של Google, נכס מייצג בסיס משתמשים אחד. כשהנתונים שייכים לבסיס משתמשים לוגי אחד, למשל מותג או מוצר, יוצרים נכס אחד. הדוגמאות בתיעוד שמות אתר ואת האפליקציות שלו באותו נכס, כדי שכל הנתונים יהיו זמינים באותם דוחות ואפשר יהיה לראות שימוש חוצה מכשירים.
ההיגיון ההפוך נכון באותה מידה: אם האפליקציה משרתת קהל אחר לגמרי מהאתר, למשל אפליקציה לנהגים ואתר ללקוחות, אלה שני בסיסי משתמשים ושני נכסים. השאלה היא לא טכנית אלא עסקית: האם הייתם רוצים לראות את האנשים האלה באותו משפך.
כמה data streams צריך וכמה מותר?
data stream הוא מקור הנתונים בתוך הנכס: אתר או אפליקציה. לפי התיעוד של Google כך נראה המבנה המומלץ:
| Stream | כמה | מה התיעוד אומר |
|---|---|---|
| Web | אחד | ברוב המקרים stream אחד לכל מסע המשתמש באתר, גם כשהוא חוצה דומיינים, בשילוב מדידה חוצת דומיינים |
| iOS | אחד לכל אפליקציה | stream נפרד לכל שילוב של מזהה אפליקציה ופלטפורמה |
| Android | אחד לכל אפליקציה | אותו כלל. אותה אפליקציה בשתי הפלטפורמות היא שני streams |
ההמלצה של Google היא עד שלושה streams לנכס: web, iOS ו-Android. המגבלה הטכנית גבוהה בהרבה: לפי התיעוד נכס יכול להכיל עד 50 data streams, מתוכם עד 30 של אפליקציות. כל app stream יכול להיות מקושר לנכס GA4 אחד בלבד. מחיקה של stream שומרת את הנתונים ההיסטוריים שלו, אבל העיבוד נפסק ואי אפשר להשתמש בו במסנני דוחות.
טעות נפוצה היא stream נפרד לכל תת-דומיין או לכל שפה של האתר. זה מפצל את מסע המשתמש בדיוק במקום שרוצים לראות אותו רציף. את ההגדרה הנכונה לכמה דומיינים פירטנו במדריך מדידה חוצת דומיינים.
איך מוסיפים אפליקציה לנכס קיים?
נתוני אפליקציה מגיעים ל-GA4 דרך ה-SDK של Firebase. לפי התיעוד, פרויקט Firebase אחד מקושר לנכס GA4 אחד בלבד, כך שכל האפליקציות שבפרויקט שולחות נתונים לאותו נכס. זה הכלל שקובע את סדר הפעולות.
- בודקים אם כבר קיים פרויקט Firebase. אם המפתחים כבר משתמשים ב-Firebase, למשל להתראות push, מתחילים את הקישור מתוך Firebase ולא מתוך Analytics: Project settings, לשונית Integrations, כפתור Link בכרטיס של Google Analytics. שם בוחרים את הנכס הקיים של האתר.
- אם אין פרויקט, מוסיפים stream מתוך GA4. ב-Admin נכנסים ל-Data Streams, לוחצים Add stream ובוחרים iOS או Android. לפי התיעוד, במקרה הזה Analytics יוצר פרויקט Firebase תואם ומקשר אותו לנכס.
- רושמים את האפליקציה. מזינים bundle ID ל-iOS או package name ל-Android ואת שם האפליקציה. ל-iOS מזינים גם App Store ID.
- מורידים את קובץ ההגדרות ומוסיפים את ה-SDK. זה שלב של המפתחים, לפי ההוראות שעל המסך.
- מריצים את האפליקציה ובודקים. לפי התיעוד איסוף הנתונים עשוי להתחיל רק אחרי עד 30 דקות. אחר כך בודקים בדוח Realtime. בקישור שנעשה מ-Firebase הזרמת הנתונים עשויה לקחת עד 24 שעות.
השלב הראשון הוא זה שחוסך את התקלה הנפוצה: מישהו יוצר stream מתוך GA4 ונוצר פרויקט Firebase חדש, בזמן שהאפליקציה ממשיכה לשלוח נתונים לפרויקט הישן, שמקושר לנכס אחר או לא מקושר בכלל.
שני מזהים, אדם אחד
איך משתמש מהאתר ומהאפליקציה הופך לשורה אחת בדוח
איך GA4 מזהה משתמש באתר ובאפליקציה?
לפי התיעוד של Google, כשאין User-ID הזיהוי נעשה לפי Device ID. באתר הערך מגיע מה-client ID שבעוגייה _ga. באפליקציה זה app-instance ID, מזהה של התקנה אחת של האפליקציה. אלה שני מזהים שאין ביניהם שום קשר, כך שבלי User-ID אדם שגלש באתר במובייל ואז התקין את האפליקציה באותו טלפון הוא שני משתמשים מבחינת GA4.
הדרך שבה GA4 משלב את המזהים בדוחות נקבעת בהגדרה Reporting identity, ב-Admin תחת Data display:
| אפשרות | סדר הזיהוי |
|---|---|
| Blended | קודם User-ID, אחריו Device ID. כשאין אף מזהה, מידול |
| Observed | קודם User-ID, אחריו Device ID |
| Device-based | רק Device ID. מזהים אחרים שנאספו לא משמשים |
לפי התיעוד הבחירה לא משפיעה על איסוף הנתונים או על העיבוד שלהם, כך שאפשר להחליף אותה בכל רגע בלי השפעה קבועה על הנתונים. מה שחשוב לענייננו: בנכס עם אתר ואפליקציה, Device-based מבטיח ספירה כפולה גם אם הטמעתם User-ID. את שלושת המצבים ואת Google signals פירטנו במדריך User-ID וזהות הדיווח.
מה צריך כדי שאותו אדם ייספר פעם אחת?
User-ID הוא מזהה שאתם יוצרים ומצמידים למשתמש מחובר. כדי שהוא יחבר בין הפלטפורמות, אותו ערך בדיוק חייב להישלח גם מהאתר וגם מהאפליקציה. באפליקציה שולחים אותו בקריאה setUserId של ה-SDK של Firebase. הכללים מתוך התיעוד של Google:
| נושא | הכלל |
|---|---|
| אורך המזהה | עד 256 תווים |
| מידע אישי | המזהה לא יכול להיות מידע שמזהה אדם, כמו כתובת מייל. משתמשים במזהה פנימי |
| אירועים לפני ההתחברות | משויכים למזהה ברגע שהוא מוגדר |
| אירועים אחרי התנתקות | נשלחים בלי מזהה ולא משויכים עוד למזהה הקודם |
| נתוני עבר | מה שנאסף לפני ההטמעה לא מעובד מחדש ולא מקושר למזהה |
| התנתקות באתר | שולחים null. ערכים אחרים, כולל המחרוזת "null", נחשבים מזהה אמיתי |
המגבלה המהותית היא עסקית: User-ID קיים רק למשתמש מחובר. אתר שרוב הגולשים בו אנונימיים ואפליקציה שכולה אחרי התחברות יתחברו רק אצל מי שהתחבר גם באתר. לכן שיעור ההתחברות באתר הוא התקרה של האיחוד בין הפלטפורמות.
מה לא מתחבר לבד?
הנכס המשותף פותר את שאלת המקום. את השאר צריך לתכנן. אלה הפערים שחוזרים בכל הטמעה, כולם מתוך התיעוד של Google ושל Firebase:
| נושא | הפער בין האתר לאפליקציה | מה עושים |
|---|---|---|
| זהות משתמש | client ID מהעוגייה באתר, app-instance ID באפליקציה | User-ID זהה בשתי הפלטפורמות |
| צפייה בתוכן | page_view באתר, screen_view באפליקציה | מנתחים במימדים המשולבים, למשל Page title and screen class |
| אירועים אוטומטיים | באתר enhanced measurement, למשל גלילה והורדת קובץ. באפליקציה first_open, app_update ואירועי מחזור חיים | לא מניחים שאירוע קיים בצד השני |
| מכסת שמות אירועים | באתר אין מגבלה, באפליקציה 500 שמות שונים | אותם שמות לאותן פעולות, בלי וריאציות |
| זמן קצוב לסשן | באתר מוגדר ב-Admin, בהגדרות התג של ה-stream. באפליקציה בקוד, בקריאה setSessionTimeoutDuration | מוודאים שהערך זהה. ברירת המחדל בשניהם 30 דקות |
| WebView בתוך האפליקציה | קריאות Analytics מתוך WebView לא מגיעות ל-Google Analytics ישירות | מעבירים את האירועים לקוד המקורי של האפליקציה, שישלח אותם דרך ה-SDK |
| תיוג קמפיינים | auto-tagging של Google Ads לא נתמך בהתקנות של אפליקציות iOS | בודקים בנפרד את מקורות ההתקנה באפליקציה |
השורה שהכי משפיעה על איכות הדוחות היא שמות האירועים: אם באתר הרכישה נשלחת כ-purchase ובאפליקציה כ-order_completed, המשפך המשותף לא יעבוד בלי תיקון ידני בכל דוח. הפתרון הוא להשתמש באותם אירועים מומלצים ובאותם שמות פרמטרים בשתי הפלטפורמות. את סוגי האירועים באפליקציה פירטנו במדריך האירועים ב-Firebase Analytics.
יש גם יתרון בצד הזה: מימדים ומדדים מותאמים נרשמים ברמת הנכס, במכסה משותפת לשתי הפלטפורמות (לפי התיעוד 50 מימדים מותאמים ברמת האירוע ו-25 ברמת המשתמש בנכס רגיל). לכן פרמטר בשם זהה באתר ובאפליקציה צורך רישום אחד ולא שניים.
איך מנתחים את שתי הפלטפורמות יחד ולחוד?
שלושה מימדים שמתמלאים אוטומטית עושים את רוב העבודה. Platform מחזיר Web, iOS או Android. המימדים Stream name ו-Stream ID מזהים את ה-stream המדויק, שימושי כשיש יותר מאפליקציה אחת. כדי להשוות בין משתמשים מחוברים ללא מחוברים, התיעוד מציע לבנות השוואה על המימד Signed in with user ID.
סדר הבדיקה שאני ממליץ עליו אחרי ההקמה: קודם כל פלטפורמה לחוד, כדי לוודא שהאירועים המרכזיים מגיעים משלושת ה-streams באותם שמות. אחר כך משפך אחד שחוצה פלטפורמות, למשל צפייה במוצר באתר ורכישה באפליקציה, מסונן למשתמשים מחוברים. אם המשפך הזה ריק, הבעיה היא כמעט תמיד ב-User-ID ולא בדוח. מי שצריך לחבר את הנתונים מחוץ לממשק ימצא ב-BigQuery את השדה user_id לצד user_pseudo_id, המזהה האוטומטי של המכשיר או ההתקנה.
שאלות נפוצות
האם אתר ואפליקציה צריכים להיות באותו נכס GA4?
כן, כשהם משרתים את אותו בסיס משתמשים. לפי התיעוד של Google נכס מייצג בסיס משתמשים אחד. הדוגמאות בתיעוד שמות אתר ואת האפליקציות שלו באותו נכס כדי שכל הנתונים יהיו זמינים באותם דוחות. כשהאפליקציה והאתר פונים לקהלים שונים לגמרי, יוצרים נכסים נפרדים.
כמה data streams אפשר ליצור בנכס GA4?
לפי התיעוד של Google נכס יכול להכיל עד 50 data streams, מתוכם עד 30 של אפליקציות. ההמלצה של Google צנועה בהרבה: עד שלושה streams לנכס, אחד ל-web, אחד ל-iOS ואחד ל-Android. ברוב המקרים מספיק web stream אחד גם לאתר שחוצה כמה דומיינים.
למה אותו משתמש נספר פעמיים, פעם באתר ופעם באפליקציה?
כי בלי User-ID הזיהוי נעשה לפי Device ID. לפי התיעוד של Google, באתר זה ה-client ID מהעוגייה _ga. באפליקציה זה app-instance ID של ההתקנה. אין קשר בין שני המזהים. כדי לאחד אותם שולחים User-ID זהה בשתי הפלטפורמות ובוחרים זהות דיווח Blended או Observed.
האם אפשר לקשר כמה פרויקטים של Firebase לאותו נכס GA4?
לפי התיעוד של Google פרויקט Firebase אחד מקושר לנכס GA4 אחד בלבד. כל האפליקציות שבפרויקט שולחות נתונים לאותו נכס. לכן כשכבר קיים פרויקט Firebase לאפליקציה, מתחילים את הקישור לנכס הקיים של האתר מתוך Firebase ולא יוצרים stream חדש מתוך Analytics.
איך מודדים WebView בתוך אפליקציה?
לפי התיעוד של Firebase, קריאות Analytics מתוך WebView לא יכולות להגיע ל-Google Analytics ישירות. צריך להעביר אותן לקוד המקורי של האפליקציה, שישלח אותן דרך ה-SDK של Firebase. ב-Android עושים זאת בממשק JavaScript וב-iOS בעזרת message handler של ה-WebView.
מה ההבדל בין page_view ל-screen_view בנכס משותף?
page_view הוא האירוע שנשלח בטעינת עמוד באתר. screen_view הוא האירוע שנשלח במעבר מסך באפליקציה. אלה שני אירועים נפרדים, לכן GA4 מציע מימדים משולבים כמו Page title and screen class שמציגים את שניהם באותו דוח. המימד Platform מפריד ביניהם ל-Web, iOS ו-Android.
מה השורה התחתונה?
נכס אחד לאתר ולאפליקציה הוא ההחלטה הנכונה לרוב העסקים, אבל הוא רק נקודת ההתחלה. הנכס מאחד את המקום שבו הנתונים יושבים. את האנשים מאחד רק User-ID שנשלח בערך זהה משתי הפלטפורמות. את המשפכים מאחדים רק שמות אירועים ופרמטרים זהים. שלושת הדברים שכדאי לסגור לפני שהמפתחים מתחילים: לאיזה פרויקט Firebase מקשרים, מה ערך ה-User-ID ומתי הוא נשלח ומה מילון האירועים המשותף. אנחנו מתכננים הקמות כאלה ובודקים אותן מול הפיתוח כחלק משירות אנליטיקס וניטור אפליקציות. אם האתר והאפליקציה שלכם באותו נכס והמספרים עדיין לא מתחברים, כתבו לנו.
מקורות
Google Analytics Help: Google Analytics account structure, Google Analytics Help: Google Analytics hierarchy, Google Analytics Help: Connect Firebase to Google Analytics, Google Analytics Help: Reporting identity, Google Analytics Help: Measure activity across platforms with User-ID, Firebase: Use Analytics in a WebView
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי