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

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

Stephan Giesau

Martin Schierle

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

ข้อผิดพลาดของเหตุการณ์ในเบราว์เซอร์แบบออนไลน์และออฟไลน์

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

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

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

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

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

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

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

googleAnalytics.initialize();

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

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

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

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

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

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

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

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