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

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

Stephan Giesau

Martin Schierle

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

อันตรายของกิจกรรมเบราว์เซอร์ออนไลน์และออฟไลน์

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

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

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

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

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

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

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

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

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

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

รูปภาพหลักของ JC Gellidon ใน Unsplash