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

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

Stephan Giesau

Martin Schierle

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

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

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

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

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

גישה טובה יותר: קובץ השירות (Service Worker)

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

בצורה הכי פשוטה, אפשר להפעיל אותו ב-Service Worker שמבוסס על Workbox באמצעות שתי השורות הבאות:

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

googleAnalytics.initialize();

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

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

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

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

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

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

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

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

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

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 worker המורכב יותר:

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

במאמרים How to report metrics and build a performance culture ו-Fixing website speed cross-functionally מפורטים טיפים שיעזרו לכם לשכנע בעלי עניין בתחומים שונים להשקיע יותר באתר שלכם. הפוסטים האלה מתמקדים בביצועים, אבל הם יכולים לתת לכם רעיונות כלליים לגבי דרכים לעורר עניין בקרב בעלי העניין.