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

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

Stephan Giesau

Martin Schierle

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

הבעיות באירועים בדפדפן אונליין ואופליין

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

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

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

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

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

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

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