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

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

Stephan Giesau

Martin Schierle

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

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

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

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

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

แนวทางที่ดีกว่า: Service Worker

โซลูชันที่เปิดใช้โหมดออฟไลน์ยังเป็นโซลูชันที่ดีกว่าในการติดตาม การใช้งานแบบออฟไลน์ด้วย คุณสามารถจัดเก็บ Ping การวิเคราะห์ใน IndexedDB ตราบใดที่ผู้ใช้ออฟไลน์ และส่งอีกครั้งเมื่อผู้ใช้ออนไลน์อีกครั้ง สำหรับ Google Analytics ฟีเจอร์นี้มีอยู่ในโมดูล Workbox อยู่แล้ว แต่โปรดทราบว่าระบบอาจไม่ประมวลผล Hit ที่ส่งโดยเลื่อนเวลาไปนานกว่า 4 ชั่วโมง

ในรูปแบบที่ง่ายที่สุด คุณสามารถเปิดใช้งานได้ภายใน Service Worker ที่ใช้ Workbox ด้วย 2 บรรทัดต่อไปนี้

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

googleAnalytics.initialize();

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

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

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

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

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

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

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

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

เนื่องจากกรณีเหล่านี้สร้างความรำคาญให้กับผู้ใช้เป็นอย่างมาก จึงควรติดตาม Service Worker เป็นจุดที่เหมาะที่สุดในการตรวจหาข้อผิดพลาดของเครือข่าย และติดตามข้อผิดพลาดเหล่านั้นโดยใช้ Analytics Workbox ช่วยให้กำหนดค่า ตัวแฮนเดิล 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 กับตัวแฮนเดิลที่กำหนดเอง ซึ่ง จะห่อหุ้มตรรกะทางธุรกิจไว้ในเส้นทางแยกต่างหาก โดยมี ความสามารถในการบำรุงรักษาที่ดีขึ้นใน 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 และส่งการ Ping ของ 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 ได้ง่ายๆ และเป็นแนวทางปฏิบัติแนะนำด้าน UX ที่คล้ายกับหน้า 404 ที่กำหนดเอง จากนั้นให้พยายามใช้ การสำรองข้อมูลแบบออฟไลน์ขั้นสูงเพิ่มเติม และสุดท้ายคือเนื้อหาแบบออฟไลน์จริง ตรวจสอบว่าคุณโฆษณาและอธิบาย ฟีเจอร์นี้ให้ผู้ใช้ทราบอย่างดี แล้วคุณจะเห็นการใช้งานที่เพิ่มขึ้น เพราะทุกคน ต่างก็ต้องออฟไลน์กันบ้าง

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