การวัดการใช้งานออฟไลน์

วิธีติดตามการใช้งานออฟไลน์ในเว็บไซต์ของคุณเพื่อหาคำตอบว่าทำไมเว็บไซต์ของคุณจึงต้องการประสบการณ์การใช้งานออฟไลน์ที่ดียิ่งขึ้น

Stephan Giesau

Martin Schierle

บทความนี้แสดงวิธีการติดตามการใช้งานแบบออฟไลน์ของเว็บไซต์ เพื่อหาสาเหตุที่เว็บไซต์ต้องมีโหมดออฟไลน์ที่ดียิ่งขึ้น นอกจากนี้ยังอธิบายหลุมพรางและปัญหาที่ควรหลีกเลี่ยงเมื่อนำการวิเคราะห์การใช้งานแบบออฟไลน์มาใช้

อันตรายของเหตุการณ์ออนไลน์และออฟไลน์ในเบราว์เซอร์

โซลูชันที่เห็นได้ชัดในการติดตามการใช้งานแบบออฟไลน์คือการสร้าง Listener เหตุการณ์สำหรับเหตุการณ์ online และ offline (ซึ่งหลายเบราว์เซอร์รองรับ) และนำตรรกะการติดตามข้อมูลวิเคราะห์ไว้ใน Listener เหล่านั้น อย่างไรก็ตาม วิธีการนี้มีปัญหาและข้อจำกัดหลายประการดังนี้

• โดยทั่วไปแล้ว การติดตามทุกเหตุการณ์ของสถานะการเชื่อมต่อเครือข่ายอาจเป็นการดำเนินการที่มากเกินไป และมีผลเสียอย่างมากในโลกที่มุ่งเน้นความเป็นส่วนตัว ซึ่งควรรวบรวมข้อมูลให้น้อยที่สุดเท่าที่จะเป็นไปได้ นอกจากนี้ เหตุการณ์ online และ offline อาจเริ่มทำงานเป็นเวลาเพียง 1 วินาทีของการสูญเสียเครือข่าย ซึ่งผู้ใช้อาจมองไม่เห็นหรือแจ้งให้ทราบ
• การติดตาม Analytics ของกิจกรรมออฟไลน์จะไม่ส่งไปถึงเซิร์ฟเวอร์การวิเคราะห์ เนื่องจากผู้ใช้ออฟไลน์อยู่
• การติดตามการประทับเวลาในเครื่องเมื่อผู้ใช้ออฟไลน์และส่งกิจกรรมออฟไลน์ไปยังเซิร์ฟเวอร์การวิเคราะห์เมื่อผู้ใช้กลับมาออนไลน์อีกครั้งขึ้นอยู่กับการที่ผู้ใช้กลับมายังเว็บไซต์ของคุณ หากผู้ใช้ออกจากเว็บไซต์ของคุณเนื่องจากไม่มีโหมดออฟไลน์และไม่เคยกลับมาอีกเลย ก็จะไม่มีทางติดตามได้ ความสามารถในการติดตามการออกออฟไลน์เป็นข้อมูลสำคัญในการสร้างตัวอย่างว่าเหตุใดเว็บไซต์ของคุณจึงต้องมีโหมดออฟไลน์ที่ดียิ่งขึ้น
• เหตุการณ์ online ไม่น่าเชื่อถือมากนักเนื่องจากรู้เฉพาะเรื่องการเข้าถึงเครือข่าย ไม่ใช่การเข้าถึงอินเทอร์เน็ต ดังนั้น ผู้ใช้อาจยังออฟไลน์อยู่ และส่งคำสั่ง ping การติดตามยังคงไม่สำเร็จ
• แม้ว่าผู้ใช้จะยังอยู่ในหน้าปัจจุบันขณะที่ออฟไลน์ จะไม่มีการติดตามเหตุการณ์ Analytics อื่นๆ (เช่น เหตุการณ์การเลื่อน การคลิก ฯลฯ) ซึ่งอาจเป็นข้อมูลที่เกี่ยวข้องและเป็นประโยชน์มากกว่า
• การอยู่ในสถานะออฟไลน์ก็ไม่ได้มีความหมายโดยทั่วไปเช่นกัน ในฐานะนักพัฒนาเว็บไซต์ การรู้ว่าทรัพยากรประเภทใดที่โหลดไม่สำเร็จอาจสำคัญกว่า โดยเฉพาะอย่างยิ่งในบริบทของ SPA ซึ่งการเชื่อมต่อเครือข่ายที่หลุดอาจไม่นำไปสู่หน้าข้อผิดพลาดแบบออฟไลน์ของเบราว์เซอร์ (ซึ่งผู้ใช้เข้าใจ) แต่มีแนวโน้มมากขึ้นที่ส่วนแบบไดนามิกของหน้าเว็บจะล้มเหลวโดยไม่มีสะดุด

คุณยังสามารถใช้โซลูชันนี้เพื่อทำความเข้าใจพื้นฐานการใช้งานแบบออฟไลน์ได้ แต่การดึงเงินคืนและข้อจำกัดต่างๆ ต้องได้รับการพิจารณาอย่างรอบคอบ

วิธีที่ดีกว่าคือ ให้โปรแกรมทำงานของบริการ

โซลูชันที่เปิดใช้โหมดออฟไลน์จะเป็นโซลูชันที่ดีกว่าสำหรับการติดตามการใช้งานแบบออฟไลน์ แนวคิดเบื้องต้นคือจัดเก็บคําสั่ง ping ของ Analytics ไว้ใน IndexedDB ตราบใดที่ผู้ใช้ออฟไลน์อยู่ และส่งคําสั่ง ping อีกครั้งเมื่อผู้ใช้ออนไลน์อีกครั้ง สำหรับ Google Analytics ตัวเลือกนี้มีอยู่แล้วพร้อมใช้งานผ่านโมดูลกล่องจดหมาย แต่โปรดคำนึงว่า Hit ที่ส่งนานกว่า 4 ชั่วโมงที่มีการเลื่อนเวลาอาจไม่ได้รับการประมวลผล รูปแบบที่ง่ายที่สุดคือการเปิดใช้งานภายใน Service Worker ที่ทำงานด้วย Workbox ด้วย 2 บรรทัดต่อไปนี้

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

googleAnalytics.initialize();

วิธีนี้จะติดตามกิจกรรมที่มีอยู่ทั้งหมดและคำสั่ง ping การดูหน้าเว็บขณะที่ออฟไลน์ แต่คุณจะไม่ทราบว่าเหตุการณ์เหล่านั้นเกิดขึ้นแบบออฟไลน์ (เนื่องจากเล่นซ้ำตามเดิม) สำหรับขั้นตอนนี้ คุณสามารถจัดการคำขอติดตามด้วย Workbox โดยเพิ่มแฟล็ก offline ในคำสั่ง ping ของการวิเคราะห์โดยใช้มิติข้อมูลที่กำหนดเอง (cd1 ในตัวอย่างโค้ดด้านล่าง) ดังนี้

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

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

จะเกิดอะไรขึ้นหากผู้ใช้ออกจากหน้าเนื่องจากออฟไลน์ก่อนที่การเชื่อมต่ออินเทอร์เน็ตจะกลับมา แม้ว่าโดยปกติจะทำให้โปรแกรมทำงานของบริการเข้าสู่โหมดสลีป (เนื่องจากส่งข้อมูลไม่ได้เมื่อมีการเชื่อมต่อกลับมา) แต่โมดูล Google Analytics ของ Workbox จะใช้ Background Sync API ซึ่งจะส่งข้อมูลการวิเคราะห์ในภายหลังเมื่อมีการเชื่อมต่อกลับมาแม้ว่าผู้ใช้จะปิดแท็บหรือเบราว์เซอร์ไปแล้ว

แต่ก็ยังมีข้อเสียอยู่ ถึงแม้วิธีนี้จะทำให้การติดตามที่มีอยู่ใช้งานได้ในแบบออฟไลน์ แต่คุณมีแนวโน้มที่จะไม่เห็นข้อมูลที่เกี่ยวข้องมากนักจนกว่าจะใช้โหมดออฟไลน์พื้นฐาน ผู้ใช้ยังคงออกจากเว็บไซต์อย่างรวดเร็วเมื่อการเชื่อมต่อถูกตัด แต่ตอนนี้คุณสามารถวัดและวัดผลได้เป็นอย่างน้อย โดยการเปรียบเทียบระยะเวลาเซสชันโดยเฉลี่ยและการมีส่วนร่วมของผู้ใช้กับผู้ใช้ที่ใช้มิติข้อมูลออฟไลน์กับผู้ใช้ทั่วไป

SPA และการโหลดแบบ Lazy Loading

หากผู้ใช้ที่เข้าชมหน้าเว็บที่สร้างขึ้นเป็นเว็บไซต์ที่มีหลายหน้าออฟไลน์และพยายามไปยังส่วนต่างๆ หน้าออฟไลน์เริ่มต้นของเบราว์เซอร์จะปรากฏขึ้นเพื่อช่วยให้ผู้ใช้ทราบว่ากำลังเกิดอะไรขึ้น อย่างไรก็ตาม หน้าที่สร้างเป็นแอปพลิเคชันหน้าเดียวจะทำงานต่างออกไป ผู้ใช้อยู่ในหน้าเดิม และเนื้อหาใหม่จะโหลดแบบไดนามิกผ่าน AJAX โดยไม่ต้องไปยังส่วนต่างๆ ของเบราว์เซอร์ ผู้ใช้จะไม่เห็นหน้าข้อผิดพลาด ของเบราว์เซอร์เมื่อออฟไลน์ แต่ส่วนแบบไดนามิกของหน้าเว็บจะแสดงผลโดยมีข้อผิดพลาด เข้าสู่สถานะที่ไม่ระบุ หรือหยุดเป็นไดนามิก

ผลกระทบที่คล้ายกันอาจเกิดขึ้นภายในเว็บไซต์ที่มีหลายหน้าเนื่องจากการโหลดแบบ Lazy Loading ตัวอย่างเช่น ตอนแรกอาจโหลดขึ้นทางออนไลน์ แต่ผู้ใช้ออฟไลน์ก่อนที่จะเลื่อน เนื้อหาที่โหลดแบบ Lazy Loading ทั้งหมด ในครึ่งหน้าล่างจะล้มเหลวและหายไป

เนื่องจากกรณีเหล่านี้สร้างความรำคาญแก่ผู้ใช้ จึงควรติดตามกรณีเหล่านี้ โปรแกรมทำงานของบริการเป็นจุดที่สมบูรณ์แบบ ในการตรวจพบข้อผิดพลาดของเครือข่าย และติดตามข้อผิดพลาดเหล่านั้นโดยใช้การวิเคราะห์ เมื่อใช้ 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 ของข้อมูลวิเคราะห์ออก ขอย้ำอีกครั้งว่าอย่าลืมบัฟเฟอร์คำขอการวิเคราะห์ที่เกิดขึ้นแบบออฟไลน์ภายใน 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 เพื่อทำให้หน้าเว็บมีประสิทธิภาพและเชื่อถือได้มากขึ้นภายใต้สภาวะของเครือข่ายที่ไม่เสถียร

ขั้นตอนถัดไป

บทความนี้จะแสดงวิธีต่างๆ ในการติดตามการใช้งานออฟไลน์พร้อมทั้งข้อดีและข้อเสีย แม้ว่าวิธีนี้จะช่วยวัดจํานวนผู้ใช้ที่ออฟไลน์และพบปัญหาเนื่องจากเหตุการณ์ดังกล่าว แต่นี่เป็นเพียงการเริ่มต้นเท่านั้น ตราบใดที่เว็บไซต์ของคุณไม่มีโหมดออฟไลน์ที่สร้างขึ้นมาอย่างดี คุณก็จะไม่เห็นการใช้งานออฟไลน์ใน Analytics มากนัก

เราขอแนะนำให้คุณติดตั้งการติดตามอย่างเต็มรูปแบบ จากนั้นจึงขยายความสามารถในการทำงานแบบออฟไลน์โดยคอยตรวจสอบหมายเลขติดตาม เริ่มต้นด้วยหน้าข้อผิดพลาดออฟไลน์แบบง่ายๆ ก่อน ด้วยกล่องทำงานที่ไม่ซับซ้อน และควรถือเป็นแนวทางปฏิบัติแนะนำสำหรับ UX ที่คล้ายกับหน้า 404 ที่กำหนดเองอยู่ดี จากนั้นให้สร้าง การสร้างวิดีโอสำรองแบบออฟไลน์ขั้นสูง และสุดท้ายเพื่อสร้างเนื้อหาออฟไลน์จริง ตรวจสอบว่าที่คุณโฆษณาและอธิบายเรื่องนี้ แก่ผู้ใช้ แล้วคุณจะได้เห็นการใช้งานที่เพิ่มขึ้น เพราะแน่นอนว่าทุกคนจะออฟไลน์เป็นครั้งคราว

ดูวิธีรายงานเมตริกและสร้างวัฒนธรรมด้านประสิทธิภาพ และการแก้ไขความเร็วของเว็บไซต์ข้ามสายงานเพื่อดูเคล็ดลับในการโน้มน้าวผู้มีส่วนเกี่ยวข้องข้ามสายงานให้ลงทุนในเว็บไซต์มากขึ้น แม้ว่าโพสต์เหล่านี้จะมุ่งเน้นที่ประสิทธิภาพ แต่ก็น่าจะช่วยให้คุณได้รับแนวคิดทั่วไปเกี่ยวกับวิธีการมีส่วนร่วมกับผู้มีส่วนเกี่ยวข้อง

รูปภาพหลักโดย JC Gellidon ใน Unsplash