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

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

Stephan Giesau
Stephan Giesau
Martin Schierle
Martin Schierle

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

החסרונות של אירועי הדפדפן אונליין ואופליין

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

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

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

גישה טובה יותר: ה-service worker

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

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

googleAnalytics.initialize();

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

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

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

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

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

אפליקציות SPA וטעינה מדורגת

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

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

מכיוון שהמקרים האלה מאוד מרגיזים את המשתמשים, כדאי לעקוב אחריהם. שירותי העבודה הם המקום המושלם לזהות שגיאות ברשת, ובסופו של דבר לעקוב אחריהן באמצעות ניתוח נתונים. באמצעות 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 עם טיפול בהתאמה אישית. כך אפשר להכיל את הלוגיקה העסקית במסלול נפרד, עם יכולת תחזוקה טובה יותר בקובצי שירות מורכבים יותר:

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 ולשלוח את ה-ping ל-Analytics. שוב, חשוב לאגור ב-buffer בקשות ניתוח נתונים שמתרחשות במצב אופליין בתוך ה-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) ואת טיפול השגיאות באופן כללי, כדי שהדף יהיה עמיד ואמין יותר בתנאים של רשת לא יציבה.

השלבים הבאים

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

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

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

התמונה הראשית (Hero) היא צילום של JC Gellidon ב-Unsplash.