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

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

Stephan Giesau

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.