מדידת שימוש במצב אופליין

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

Stephan Giesau

Martin Schierle

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

המלכודות של אירועי דפדפן מקוונים ואופליין

הפתרון הבולט למעקב אחרי שימוש אופליין הוא ליצור פונקציות event listener online ו- offline אירועים (שהם תומכים בדפדפנים רבים) וכדי למקם את המעקב אחר ניתוח נתונים את הלוגיקה של המאזינים האלה. לצערי, יש כמה בעיות ומגבלות בשיטה הזו גישה:

• באופן כללי, מעקב אחר כל אירוע של סטטוס חיבור לרשת עשוי להיות מוגזם, דבר שאינו יעיל בעולם שבו מתמקדים בפרטיות המשתמשים, שבו כמות הנתונים צריכה להיות קטנה ככל האפשר שנאספו. בנוסף, האירועים online ו-offline יכולים לפעול למשך שבריר שנייה בלבד אובדן רשת, שסביר להניח שהמשתמש לא יראה או יבחין בו.
• המעקב ב-Analytics אחר פעילות אופליין לעולם לא יגיע לשרת ניתוח הנתונים כי המשתמש... אז הוא אופליין.
• מעקב מקומי אחר חותמת זמן כשמשתמש עובר למצב אופליין ושולח את הפעילות אופליין אל כאשר המשתמש חוזר לאינטרנט, שרת הניתוח תלוי במשתמש שמבקר שוב באתר שלכם. אם המשתמש נוטש את האתר עקב מחסור במצב אופליין ולא חוזר אליו אף פעם, עליך אין דרך לעקוב אחרי זה. היכולת לעקוב אחר נשירות מתהליך ההמרה אופליין היא נתונים קריטיים ליצירת למה נדרש מצב אופליין טוב יותר באתר.
• האירוע online לא מאוד מהימן הוא יודע רק על גישה לרשת, ואין גישה לאינטרנט. לכן ייתכן שמשתמש עדיין לא מחובר לאינטרנט, ושליחת הפינג למעקב יכולה עדיין נכשל.
• גם אם המשתמש נשאר בדף הנוכחי כשהוא במצב אופליין, אף אחד מהאחרים מתבצע מעקב אחר אירועים של ניתוח נתונים (למשל, אירועי גלילה, קליקים וכו') ,ולכן יש כמה שיותר מידע רלוונטי ושימושי.
• גם במצב אופליין אין ערך מוסף באופן כללי. כמפתחי אתרים, יכול להיות חשוב יותר לדעת אילו סוגי משאבים לא נטענו. זה רלוונטי במיוחד בהקשר של שירותי SPA, שבהם ניתוק החיבור לרשת עלול שלא להוביל לדפדפן במצב אופליין אבל יש סבירות גבוהה יותר שחלקים דינמיים אקראיים בדף ייכשלו בשקט.

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

גישה טובה יותר: Service Worker

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

import * as googleAnalytics from 'workbox-google-analytics';

googleAnalytics.initialize();

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

import * as googleAnalytics from 'workbox-google-analytics';

googleAnalytics.initialize({
  parameterOverrides: {
    cd1: 'offline',
  },
});

מה קורה אם משתמש עוזב את הדף מפני שהוא היה במצב אופליין, לפני שמתחברים לאינטרנט בחזרה? למרות שהפעולה הזו בדרך כלל מעבירה את Service Worker למצב שינה (כי הוא לא יכול לשלוח את הנתונים) כשהחיבור חוזר), מודול Google Analytics של Workbox משתמש בסנכרון ברקע ל-API, ששולח את ניתוח הנתונים נתונים מאוחר יותר כשהחיבור חוזר, גם אם המשתמש סוגר את הכרטיסייה או את הדפדפן.

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

שירותי SPA וטעינה מדורגת

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

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

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

import { setCatchHandler } from 'workbox-routing';

setCatchHandler(({ event }) => {
  // https://developer.mozilla.org/docs/Web/API/Client/postMessage
  event.waitUntil(async function () {
    // Exit early if we don't have access to the client.
    // Eg, if it's cross-origin.
    if (!event.clientId) return;

    // Get the client.
    const client = await clients.get(event.clientId);
    // Exit early if we don't get the client.
    // Eg, if it closed.
    if (!client) return;

    // Send a message to the client.
    client.postMessage({
      action: "network_fail",
      url: event.request.url,
      destination: event.request.destination
    });

    return Response.error();

  }());
});

במקום להקשיב לכל הבקשות שנכשלו, דרך נוספת היא לזהות שגיאות במסלולים ספציפיים. בלבד. לדוגמה, אם אנחנו רוצים לדווח על שגיאות שמתרחשות במסלולים אל /products/* בלבד, אנחנו יכולים הוספת בדיקה ב-setCatchHandler שתסנן את ה-URI באמצעות ביטוי רגולרי. פתרון פשוט יותר הוא להטמיע MarkRoute עם handler בהתאמה אישית. הוא כולל את לוגיקה עסקית למסלול נפרד, עם תחזוקה טובה יותר ב-Service Workers מורכבים יותר:

import { registerRoute } from 'workbox-routing';
import { NetworkOnly } from 'workbox-strategies';

const networkOnly = new NetworkOnly();
registerRoute(
  new RegExp('https:\/\/example\.com\/products\/.+'),
  async (params) => {
    try {
      // Attempt a network request.
      return await networkOnly.handle(params);
    } catch (error) {
      // If it fails, report the error.
      const event = params.event;
      if (!event.clientId) return;
      const client = await clients.get(event.clientId);
      if (!client) return;

      client.postMessage({
        action: "network_fail",
        url: event.request.url,
        destination: "products"
      });

      return Response.error();
    }
  }
);

בשלב האחרון, הדף צריך להאזין לאירוע message ולשלוח את הפינג של ניתוח הנתונים. שוב, הקפידו לאחסן במאגר נתונים זמני בקשות לניתוח נתונים שמתרחשות אופליין בתוך Service Worker. בתור שתיארנו קודם, צריך לאתחל את הפלאגין workbox-google-analytics עבור Google Analytics מובנה תמיכה.

הדוגמה הבאה מתבססת על Google Analytics, אבל ניתן ליישם אותה באותו אופן בניתוחים אחרים לספקים שונים.

if ("serviceWorker" in navigator) {
  // ... SW registration here

  // track offline error events
  navigator.serviceWorker.addEventListener("message", event => {
    if (gtag && event.data && event.data.action === "network_fail") {
      gtag("event", "network_fail", {
        event_category: event.data.destination,
        // event_label: event.data.url,
        // value: event.data.value
      });
    }
  });
}

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

השלבים הבאים

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

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

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

תמונה ראשית (Hero) של JC Gellidon בתוכנית Unbounce.