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

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

סטפן גיאסאו

מרטין שיירל

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

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

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

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

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

גישה טובה יותר: קובץ השירות (service worker)

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

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

googleAnalytics.initialize();

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

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

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

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

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

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

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

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

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

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 באמצעות ביטוי רגולרי. פתרון נקי יותר הוא הטמעת RegisterRoute באמצעות 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 ב-UnFlood.