מה Crashlytics מודד ומה הוא לא מודד?
לפי התיעוד של Firebase, Crashlytics הוא כלי דיווח קריסות בזמן אמת שעוזר לעקוב אחרי בעיות יציבות, לתעדף אותן ולתקן אותן. שני המדדים שהוא מחשב אוטומטית הם אחוז המשתמשים ללא קריסה (crash-free users) ואחוז הסשנים ללא קריסה (crash-free sessions). החישוב פשוט: אחד פחות היחס בין משתמשים שקרסו לכלל המשתמשים בתקופה. אותו דבר לסשנים.
הפרט שרוב הצוותים מפספסים: לפי התיעוד, המדדים האלה מחושבים רק על אירועים קטלניים (fatal). שגיאות שנתפסו בקוד ודווחו כאירועים לא קטלניים (non-fatal) לא נכנסות לחישוב. כלומר אפליקציה עם 99.8% משתמשים ללא קריסה יכולה עדיין לייצר אלפי שגיאות שמשבשות את החוויה בלי שהמספר הראשי יזוז. לכן בניטור מקצועי מסתכלים על שני הדברים בנפרד.
מה קורה מרגע הקריסה ועד ההחלטה
ניטור קריסות כתהליך מדידה
אילו התראות צריך להגדיר ולמה ברירת המחדל לא מספיקה?
לפי התיעוד של Firebase, התראות על אירועים לא קטלניים חדשים, על אירועים קטלניים חדשים, על ANR ועל בעיות שמתפשטות במהירות אינן נשלחות כברירת מחדל. מי שמתקין את Crashlytics ולא נוגע בהגדרות ההתראות יגלה קריסה מתפשטת רק כשמישהו ייכנס לקונסולה.
ההתראה החשובה ביותר היא התראת המהירות (velocity alert). לפי התיעוד היא מופעלת כשבעיה בודדת חוצה סף שמוגדר בשני ערכים: אחוז מהסשנים ומספר מינימלי של משתמשים שנפגעו. ברירת המחדל היא 1% מהסשנים ו-25 משתמשים בחלון של 30 דקות. התנאים הנוספים: לאפליקציה היו לפחות 10 משתמשים באותו חלון ולא נשלחה כבר התראה על אותה בעיה באותה גרסה. לאפליקציה עם מעט משתמשים כדאי להוריד את מספר המשתמשים המינימלי (המינימום המותר הוא 10), אחרת ההתראה לא תגיע לעולם. לאפליקציה גדולה 1% מהסשנים יכול להיות אלפי אנשים. אז מורידים את האחוז.
| סוג התראה | מתי היא מופעלת | מי צריך לקבל אותה |
|---|---|---|
| מהירות (velocity) | בעיה אחת חוצה אחוז סשנים ומספר משתמשים בתוך 30 דקות | מפתח תורן ומנהל המוצר, מיד |
| בעיה חדשה קטלנית | קריסה מסוג שלא נראה קודם | צוות הפיתוח, באותו יום |
| בעיה שחזרה (regressed) | בעיה שסומנה כסגורה חוזרת בגרסה חדשה | מי שסגר אותה |
| לא קטלנית חדשה | שגיאה שנתפסה בקוד ודווחה לראשונה | סיכום יומי, לא התראה מיידית |
איך מגדירים Crashlytics כמו מערכת מדידה?
- מגדירים את מדד היציבות מול יעד. אחוז משתמשים ללא קריסה לפי גרסה, עם יעד מוסכם (למשל 99.5%) ועם כלל ברור: גרסה שיורדת מתחת ליעד בשלושת הימים הראשונים נעצרת בהפצה. בלי כלל כזה המדד הוא עוד מספר בדוח.
- מוסיפים מפתחות מותאמים (custom keys). לפי התיעוד אפשר לצרף לכל דוח קריסה זוגות של מפתח וערך שמתארים את מצב האפליקציה: שלב במשפך, סוג משתמש, מצב רשת, האם העגלה מלאה. התיעוד מציין מגבלה של עד 64 זוגות ועד 1 קילובייט לזוג. אלה המפתחות שמאפשרים לענות על השאלה "הקריסה פוגעת במי שעומד לשלם או במי שרק גולש".
- מדווחים שגיאות לא קטלניות בנקודות שחשובות לעסק. כשל בתשלום שנתפס בקוד, תגובה שגויה מהשרת בשלב ההזמנה, טעינה כושלת של מסך מוצר. לפי התיעוד האירועים האלה נרשמים במכשיר ונשלחים עם דוח הקריסה הבא או כשהמשתמש מפעיל מחדש את האפליקציה. Crashlytics שומר רק את שמונה השגיאות האחרונות שנרשמו. לכן מדווחים רק מה שמשמעותי.
- מחברים את Google Analytics. לפי התיעוד, כשהאפליקציה משתמשת ב-Firebase SDK של Google Analytics, Crashlytics מקבל אוטומטית לוגים של פירורי לחם (breadcrumb logs): המסכים והאירועים שהמשתמש עבר לפני הקריסה. בכיוון השני, Crashlytics יכול לרשום את הקריסות כאירוע
app_exceptionב-Analytics. אז אפשר לפלח את שיעור ההמרה לפי משתמשים שחוו קריסה. זה החיבור שהופך ניטור טכני למדידה עסקית. איך מחלקים את העבודה בין Firebase ל-AppsFlyer מוסבר במה מודדים ב-AppsFlyer ומה ב-Firebase. - מעלים קובצי מיפוי. לפי התיעוד, קובץ ה-mapping באנדרואיד וקובצי ה-dSYM ב-iOS מאפשרים לשרתי Crashlytics להציג את שרשרת הקריאות בקוד קריא. בלי זה הדוח מראה שמות מעורפלים ואף אחד לא יכול לתקן.
- מייצאים ל-BigQuery כשצריך היסטוריה. לפי מדיניות הפרטיות של Firebase, נתוני הקריסות נשמרים 90 יום לפני שמתחיל תהליך המחיקה. מי שרוצה להשוות יציבות בין רבעונים או לחבר קריסות להכנסות מייצא ל-BigQuery. לפי התיעוד הייצוא נותן טבלה יומית לכל אפליקציה ואפשר להוסיף ייצוא בזמן אמת.
איך מחברים קריסות להחלטות עסקיות?
שלוש שאלות שכדאי שיהיו בדשבורד של כל אפליקציה. הראשונה: מה אחוז המשתמשים ללא קריסה בגרסה הנוכחית מול הגרסה הקודמת. אם ירד, האם זה קשור למכשיר או למערכת הפעלה מסוימת. השנייה: מה שיעור ההמרה של משתמשים שחוו app_exception לעומת כאלה שלא, באותו שבוע. אם הפער גדול, לתיקון הקריסה יש ערך כספי שאפשר לחשב. השלישית: כמה מהקריסות קורות בשלבי התשלום וההרשמה לעומת שאר האפליקציה. קריסה במסך הבית מעצבנת, קריסה בתשלום עולה כסף. את שלוש השאלות האלה מגדירים בתוכנית המדידה של האפליקציה, לפי העקרונות באיך בונים תוכנית מדידה מהיעדים העסקיים.
מה לא לעשות?
לא להשאיר את ספי ההתראות על ברירת המחדל בלי לבדוק אם הם מתאימים לגודל האפליקציה. לא לדווח כל שגיאה כאירוע לא קטלני, כי ככה הרעש מסתיר את מה שחשוב ושמונה המקומות בתור מתמלאים בזבל. לא לשפוט יציבות לפי מספר הקריסות המוחלט אלא לפי אחוז המשתמשים שנפגעו. ולא להסתכל על Crashlytics בנפרד מהאנליטיקה: המספר "97% ללא קריסה" לא אומר כלום עד שיודעים מי שלושת האחוזים.
שאלות נפוצות
מה ההבדל בין משתמשים ללא קריסה לסשנים ללא קריסה?
משתמשים ללא קריסה מודד כמה אנשים לא חוו אף קריסה בתקופה. סשנים ללא קריסה מודד כמה סשנים לא הסתיימו בקריסה. משתמש אחד שקורס שלוש פעמים ביום מוריד את מדד הסשנים יותר מאשר את מדד המשתמשים. לפי התיעוד של Firebase שני המדדים מחושבים רק על אירועים קטלניים.
האם Crashlytics שולח התראות אוטומטית?
רק חלק. לפי התיעוד של Firebase, התראות על בעיות חדשות קטלניות ולא קטלניות, על ANR ועל בעיות שמתפשטות במהירות אינן נשלחות כברירת מחדל. צריך להפעיל אותן בקונסולה ולהגדיר להן ספים.
מה הסף המומלץ להתראת מהירות?
ברירת המחדל היא 1% מהסשנים ו-25 משתמשים בחלון של 30 דקות. לאפליקציה קטנה מורידים את מספר המשתמשים למינימום המותר (10). לאפליקציה גדולה מורידים את האחוז. הסף הנכון הוא זה שמתריע על בעיה שתגרום לכם לעצור גרסה, לא פחות ולא יותר.
כמה זמן נשמרים נתוני הקריסות?
לפי מדיניות הפרטיות של Firebase, נתוני הקריסות והמזהים הנלווים נשמרים 90 יום לפני שמתחיל תהליך המחיקה. למעקב ארוך יותר מייצאים את הנתונים ל-BigQuery.
האם צריך Crashlytics אם יש לי AppsFlyer?
כן. AppsFlyer מודד התקנות וייחוס קמפיינים, לא יציבות. Crashlytics מודד קריסות ושגיאות ומחבר אותן לפעולות המשתמש דרך Google Analytics. אלה שני כלים לשתי שאלות שונות. באפליקציה מסחרית צריך את שניהם.
מה השורה התחתונה?
Crashlytics חינמי, מותקן ברוב האפליקציות ומנוצל כמעט תמיד חלקית. ההבדל בין רשימת שגיאות למערכת ניטור הוא ארבע החלטות: יעד ליציבות לפי גרסה, ספי התראות שמתאימים לגודל שלכם, מפתחות מותאמים שמספרים מי נפגע וחיבור ל-Google Analytics שמחבר קריסות להמרות. זה חלק מהעבודה שאנחנו עושים בשירות אנליטיקה לאפליקציות, לצד הטמעת AppsFlyer ומילון אירועים אחיד. אם האפליקציה שלכם מודדת קריסות אבל אף אחד לא מסתכל, כתבו לנו.
מקורות
Firebase: Crashlytics overview, Firebase: Crash-free metrics, Firebase: Crashlytics alerts, Firebase: Customize your Crashlytics crash reports, Firebase: Export Crashlytics data to BigQuery, Firebase: Privacy and Security
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי