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

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

Stephan Giesau

Martin Schierle

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

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

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

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

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

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

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

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