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

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

Stephan Giesau

Martin Schierle

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

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

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

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

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

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

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

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

השלבים הבאים

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

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

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

תמונה ראשית (Hero) של JC Gellidon בתוכנית Unbounce.