מה זה DebugView ולמה אי אפשר לבדוק בדוחות הרגילים?
באתר רגילים לראות אירוע בשנייה שבה הוא נשלח. באפליקציה זה לא עובד כך: לפי התיעוד של Firebase אירועים שהאפליקציה מתעדת נאספים למנות לאורך בערך שעה ונשלחים יחד, כדי לחסוך בסוללה ובתעבורת רשת. בנוסף, לפי התיעוד של GA4 עיבוד הנתונים לדוחות ול-Explorations יכול לקחת 24 עד 48 שעות.
מפתח שמחכה יום כדי לגלות ששם של פרמטר שגוי לא יספיק לתקן לפני השחרור. debug mode משנה את ההתנהגות הזאת: המכשיר מעלה את האירועים בהשהיה מינימלית ו-DebugView מציג אותם לפי מכשיר, אירוע אחרי אירוע. זה הכלי שמאפשר לסגור בדיקת מדידה בזמן ישיבה אחת ולא בשבוע.
מהלך הבדיקה לפני שחרור
ארבעה שלבים, מהמכשיר ועד הדוחות
איך מפעילים debug mode ב-Android וב-iOS?
ב-Android מריצים פקודת adb מול מכשיר או אמולטור מחובר, עם שם החבילה של האפליקציה במקום PACKAGE_NAME:
adb shell setprop debug.firebase.analytics.app PACKAGE_NAMEלפי התיעוד ההגדרה נשארת בתוקף עד שמכבים אותה במפורש בפקודה הבאה:
adb shell setprop debug.firebase.analytics.app .none.ב-iOS מוסיפים ארגומנט ב-Xcode, בהגדרות ה-scheme של הפרויקט, תחת Arguments Passed On Launch:
-FIRDebugEnabledגם כאן המצב נשאר פעיל עד שמכבים אותו. הכיבוי נעשה באותו מקום, עם הארגומנט הזה:
-FIRDebugDisabledזאת הנקודה שמפספסים הכי הרבה: מחיקת הארגומנט לא מכבה את המצב. לפי התיעוד הוא נשאר עד שמציינים במפורש FIRDebugDisabled, כך שמכשיר בדיקה שנשאר ב-debug mode ממשיך להופיע ב-DebugView שבועות אחרי שהבדיקה הסתיימה.
| פלטפורמה | הפעלה | כיבוי |
|---|---|---|
| Android | פקודת adb עם שם החבילה | אותה פקודה עם הערך .none. |
| iOS | הארגומנט FIRDebugEnabled ב-scheme של Xcode | הארגומנט FIRDebugDisabled |
| אתר עם Google tag | Tag Assistant או הפרמטר debug_mode בתג | הסרת הפרמטר debug_mode |
אם לאפליקציה יש גם אתר באותו נכס, שימו לב לפרט קטן בתיעוד של GA4: הגדרת debug_mode לערך false לא מכבה את המצב, צריך להסיר את הפרמטר לגמרי. את הבדיקה בצד האתר פירטנו במצב Preview ו-Tag Assistant ב-GTM.
איפה נמצא DebugView ומה רואים בו?
ב-GA4 נכנסים ל-Admin ובוחרים DebugView תחת Data display. בקונסולה של Firebase הדוח נמצא תחת Analytics. לפי התיעוד אלה חלקי המסך:
| החלק במסך | מה הוא מציג | למה משתמשים בו |
|---|---|---|
| DEBUG DEVICE | בורר המכשירים, בפינה העליונה | לבחור את המכשיר שעליו בודקים כשכמה מפתחים עובדים במקביל |
| Seconds stream | האירועים שתועדו ב-60 השניות האחרונות, החדשים למעלה | לחיצה על אירוע פותחת את הפרמטרים שלו |
| Minutes stream | עיגול לכל דקה ב-30 הדקות האחרונות, עם מספר האירועים | לחיצה על עיגול טוענת את האירועים של אותה דקה |
| Top Events | האירועים המובילים ב-30 הדקות האחרונות | לראות במבט אחד אילו אירועים נשלחו וכמה פעמים |
| Current User Properties | המצב העדכני של מאפייני המשתמש במכשיר שנבחר | לבדוק שמאפיין התעדכן אחרי התחברות או רכישה |
סייג אחד מהתיעוד: DebugView מבצע ניתוח ייחוס מוגבל. כדי לבדוק מקורות תנועה וקמפיינים צריך להסתכל בדוחות Acquisition ולא כאן.
מה ההבדל בין DebugView לדוח Realtime?
שני הדוחות משמשים לאימות איסוף, אבל הם עונים על שאלות שונות. Realtime מציג את הפעילות של כלל המשתמשים ב-30 הדקות האחרונות. DebugView מציג מכשיר אחד שהופעל בו debug mode, גם לאורך זמן ארוך יותר.
יש עוד שני הבדלים שמשפיעים על הבדיקה. לפי התיעוד נתוני אפליקציה ב-Realtime נשלחים במנות כדי לחסוך בסוללה, כך שייתכנו עיכובים. בנוסף, האפשרות View user snapshot ב-Realtime מציגה משתמש אקראי, כך שאי אפשר לבחור בה את המכשיר שלכם. לכן לבדיקת הטמעה משתמשים ב-DebugView. דוח Realtime מתאים לשאלה אחרת: האם אחרי השחרור מגיעים אירועים ממשתמשים אמיתיים.
מה בודקים בכל אירוע לפני שחרור?
הבדיקה נעשית מול מסמך, לא מול הזיכרון. אם אין לכם מסמך כזה, התחילו במילון אירועים לאפליקציה. עם המילון פתוח ליד המכשיר עוברים על השלבים הבאים.
- מפעילים debug mode ומוודאים שהמכשיר מופיע. בוחרים אותו ב-DEBUG DEVICE. אם עובדים כמה בודקים, כל אחד מוודא שהוא מסתכל על המכשיר שלו.
- עוברים על המסלול לפי המילון. מבצעים לפי הסדר כל פעולה שיש לה שורה במילון. אחרי כל פעולה מחכים שהאירוע יופיע ב-Seconds stream.
- בודקים את השם אות באות. שמות אירועים רגישים לאותיות גדולות וקטנות. הבדל של אות אחת יוצר אירוע חדש במקום לספור את הקיים.
- פותחים את הפרמטרים. לוחצים על האירוע ובודקים שכל פרמטר מהמילון קיים, בשם הנכון ועם ערך מהרשימה שנקבעה.
- בודקים את רגע השליחה ואת הכמות. אירוע אחד לכל פעולה. אירוע שמופיע פעמיים או שנשלח לפני שהפעולה הושלמה הוא באג נפוץ בבדיקות.
- בודקים מסכים. לפי התיעוד של Firebase אירוע screen_view נשלח אוטומטית במעבר מסך. באפליקציות SwiftUI צריך להגדיר את שמות המסכים ידנית. מוודאים שלכל מסך יש שם שאפשר לזהות בדוח.
- בודקים מאפייני משתמש. מתחברים, משנים מצב שאמור לעדכן מאפיין ומוודאים שהערך התעדכן ב-Current User Properties.
- חוזרים על הכול בפלטפורמה השנייה. אותה בדיקה ב-iOS וב-Android. הבדלים בין הפלטפורמות מתגלים רק כשמשווים שורה מול שורה.
למה המכשיר או האירוע לא מופיעים ב-DebugView?
יש כמה סיבות שחוזרות על עצמן. הראשונה היא הסכמה: לפי התיעוד של GA4 אירועים לא נראים ב-debug mode כשמופעלות בקרות פרטיות בצד הלקוח, או כשנעשה שימוש ב-Consent Mode והמשתמש לא נתן הסכמה לאנליטיקס. בודק שלחץ על סירוב בבאנר לא יראה כלום. זאת התנהגות תקינה ולא תקלה.
השנייה היא שמצב הבדיקה לא הופעל על האפליקציה הנכונה: ב-Android הפקודה מקבלת שם חבילה, כך שגרסת בדיקה עם שם חבילה שונה מגרסת הייצור צריכה את השם שלה. השלישית היא נכס שגוי: גרסת בדיקה שמדווחת לפרויקט Firebase אחר לא תופיע בנכס שבו אתם מסתכלים.
כשלא ברור אם ה-SDK בכלל מתעד את האירוע, בודקים ביומן של המכשיר לפני שמחפשים בממשק. לפי התיעוד של Firebase ב-Android מפעילים רישום מפורט בפקודות האלה:
adb shell setprop log.tag.FA VERBOSE
adb shell setprop log.tag.FA-SVC VERBOSE
adb logcat -v time -s FA FA-SVCהאירועים מוצגים ב-logcat של Android Studio, גם האוטומטיים וגם אלה שנשלחו בקוד. ב-iOS מוסיפים ב-Xcode, תחת Arguments Passed On Launch, את הארגומנט הבא. האירועים יוצגו בקונסולת הדיבוג של Xcode:
-FIRAnalyticsVerboseLoggingEnabledאם האירוע מופיע ביומן ולא ב-DebugView, הבעיה היא ב-debug mode, בהסכמה או בנכס. אם הוא לא מופיע גם ביומן, הבעיה בקוד.
איך מונעים מנתוני הבדיקה להיכנס לדוחות?
אירועי בדיקה הם אירועים לכל דבר: לפי התיעוד של Firebase אירועים שנשלחו ב-debug mode נכללים כברירת מחדל בייצוא היומי ל-BigQuery. כדי להשאיר אותם מחוץ לדוחות ולייצוא מגדירים בנכס פילטר של תנועת מפתחים.
הפילטר נמצא ב-Admin, תחת Data collection and modification, במסך Data filters. בוחרים Create Filter ואז Developer Traffic. לפי התיעוד הפילטר מוציא מהדוחות פעילות של מכשירים שפועלים ב-debug mode, בזמן שהמפתחים ממשיכים לראות אותה ב-DebugView. שלושה פרטים שכדאי להכיר: במצב Testing הנתונים רק מסומנים במימד Test data filter name ואינם מוסרים. במצב Active השינוי קבוע ואי אפשר להחזיר נתונים שסוננו. החלת פילטר יכולה לקחת 24 עד 36 שעות. את כל סוגי הפילטרים פירטנו בסינון תנועה פנימית ותנועת מפתחים ב-GA4.
ההמלצה שלי היא להפעיל את הפילטר לפני שמתחילים לבדוק ולא אחרי. לפי התיעוד פילטר פעיל חל על נתונים נכנסים, כך שהוא לא מנקה בדיקות שכבר נאספו.
שאלות נפוצות
מה זה DebugView ב-GA4 וב-Firebase?
DebugView הוא דוח שמציג את האירועים, הפרמטרים ומאפייני המשתמש של מכשיר בדיקה אחד כמעט בזמן אמת. הוא עובד רק למכשירים שהופעל בהם debug mode. ב-GA4 הוא נמצא ב-Admin תחת Data display. לפי התיעוד הוא מציג את האירועים של 60 השניות האחרונות ואת 30 הדקות האחרונות בחלוקה לדקות.
איך מפעילים debug mode באפליקציית Android?
מריצים מול המכשיר או האמולטור את הפקודה adb shell setprop debug.firebase.analytics.app עם שם החבילה של האפליקציה. לפי התיעוד של Firebase ההגדרה נשארת בתוקף עד שמכבים אותה במפורש. הכיבוי נעשה באותה פקודה עם הערך .none. במקום שם החבילה.
איך מפעילים debug mode באפליקציית iOS?
ב-Xcode מוסיפים את הארגומנט FIRDebugEnabled עם מקף לפניו בהגדרות ה-scheme, תחת Arguments Passed On Launch. לפי התיעוד של Firebase המצב נשאר פעיל עד שמציינים במפורש את הארגומנט FIRDebugDisabled. מחיקה של הארגומנט הראשון לבדה לא מכבה את debug mode.
למה אירועים מהאפליקציה לא מופיעים מיד בדוחות?
לפי התיעוד של Firebase אירועים שהאפליקציה מתעדת נאספים למנות לאורך בערך שעה ונשלחים יחד, כדי לחסוך בסוללה וברשת. בנוסף, לפי התיעוד של GA4 עיבוד הנתונים לדוחות ול-Explorations יכול לקחת 24 עד 48 שעות. debug mode גורם למכשיר להעלות את האירועים בהשהיה מינימלית, כך שאפשר לבדוק אותם מיד ב-DebugView.
מה ההבדל בין DebugView לדוח Realtime?
Realtime מציג פעילות של כלל המשתמשים ב-30 הדקות האחרונות. DebugView מציג מכשיר אחד שהופעל בו debug mode. לפי התיעוד נתוני אפליקציה ב-Realtime נשלחים במנות ועלולים להתעכב. האפשרות View user snapshot מציגה משתמש אקראי. לכן לבדיקת הטמעה לפני שחרור משתמשים ב-DebugView.
האם אירועי בדיקה נכנסים לדוחות ול-BigQuery?
כן, אם לא מסננים אותם. לפי התיעוד של Firebase אירועים שנשלחו ב-debug mode נכללים כברירת מחדל בייצוא היומי ל-BigQuery. כדי להוציא אותם מהדוחות ומהייצוא מגדירים ב-GA4 פילטר מסוג Developer Traffic. המפתחים ממשיכים לראות את האירועים ב-DebugView גם כשהפילטר פעיל.
מה השורה התחתונה?
בדיקת מדידה באפליקציה היא חלק מבדיקות השחרור ולא משימה לשבוע שאחריו. גרסה שיצאה עם שם שגוי תמשיך לשלוח אותו כל עוד משתמשים לא עדכנו. הסדר שעובד: מפעילים debug mode, עוברים על המילון אירוע אחרי אירוע ב-DebugView, מכבים את המצב במפורש ומוודאים שפילטר המפתחים פעיל. מי שמשלב את זה בתהליך השחרור כמעט לא נתקל בהפתעות בדוחות. אנחנו מבצעים בדיקות כאלה לפני כל גרסה כחלק משירות אנליטיקס וניטור אפליקציות, לצד ההשוואה מול כלי הייחוס שתיארנו בAppsFlyer מול Firebase. אם יש לכם גרסה שעומדת לצאת ואתם לא בטוחים מה היא מודדת, כתבו לנו.
מקורות
Firebase: Monitor collected events and user properties using DebugView, Google Analytics Help: Monitor events in DebugView, Google Analytics Help: Filter out developer traffic, Google Analytics Help: Realtime report, Google Analytics Help: Confirm that you're collecting data, Firebase: Log events
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי