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

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

Stephan Giesau

Martin Schierle

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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