Mengukur penggunaan offline

Cara melacak penggunaan offline situs Anda sehingga Anda dapat membuat kasus tentang mengapa situs Anda memerlukan pengalaman offline yang lebih baik.

Stephan Giesau
Stephan Giesau
Martin Schierle
Martin Schierle
X GitHub

Artikel ini menunjukkan cara melacak penggunaan offline situs Anda untuk membantu Anda membuat kasus mengapa situs Anda memerlukan mode offline yang lebih baik. Panduan ini juga menjelaskan masalah dan jebakan yang harus dihindari saat menerapkan analisis penggunaan offline.

Permasalahan peristiwa browser online dan offline

Solusi yang jelas untuk melacak penggunaan offline adalah membuat pemroses peristiwa untuk peristiwa online dan offline (yang didukung oleh banyak browser) dan menempatkan logika pelacakan analisis Anda di pemroses tersebut. Sayangnya, ada beberapa masalah dan batasan dengan pendekatan ini:

  • Secara umum, melacak setiap peristiwa status koneksi jaringan mungkin berlebihan, dan tidak produktif di dunia yang berfokus pada privasi, tempat data harus dikumpulkan sesedikit mungkin. Selain itu, peristiwa online dan offline dapat diaktifkan hanya dalam hitungan detik saat jaringan hilang, yang mungkin tidak akan dilihat atau diketahui pengguna.
  • Pelacakan analisis aktivitas offline tidak akan pernah menjangkau server analisis karena pengguna sedang offline.
  • Melacak stempel waktu secara lokal saat pengguna offline dan mengirim aktivitas offline ke server analisis saat pengguna kembali online bergantung pada pengguna yang mengunjungi kembali situs Anda. Jika pengguna keluar dari situs Anda karena tidak adanya mode offline dan tidak pernah kembali, Anda tidak dapat melacaknya. Kemampuan untuk melacak pengabaian offline adalah data penting untuk membangun kasus tentang alasan situs Anda memerlukan mode offline yang lebih baik.
  • Peristiwa online tidak terlalu andal karena hanya mengetahui akses jaringan, bukan akses internet. Oleh karena itu, pengguna mungkin masih offline, dan pengiriman ping pelacakan masih dapat gagal.
  • Meskipun pengguna masih tetap berada di halaman saat ini saat offline, tidak ada peristiwa analisis lainnya (misalnya, peristiwa scroll, klik, dll.) yang dilacak, sehingga informasi bisa menjadi informasi yang lebih relevan dan berguna.
  • Secara umum, offline itu sendiri juga tidak terlalu bermakna. Sebagai developer situs, mungkin lebih penting untuk mengetahui jenis resource yang gagal dimuat. Hal ini terutama relevan dalam konteks SPA, saat koneksi jaringan yang terputus mungkin tidak menyebabkan halaman error offline browser (yang dipahami pengguna), tetapi lebih cenderung kegagalan bagian dinamis yang acak pada halaman.

Anda masih dapat menggunakan solusi ini untuk mendapatkan pemahaman dasar tentang penggunaan offline, tetapi banyak kelemahan dan batasan yang perlu dipertimbangkan dengan cermat.

Pendekatan yang lebih baik: pekerja layanan

Solusi yang mengaktifkan mode offline ternyata merupakan solusi yang lebih baik untuk melacak penggunaan offline. Ide dasarnya adalah menyimpan ping analisis ke IndexedDB selama pengguna offline, dan hanya mengirim ulang saat pengguna online lagi. Untuk Google Analytics, fitur ini sudah tersedia secara siap pakai melalui modul Workbox, tetapi perlu diingat bahwa hit yang dikirim lebih dari empat jam tertunda mungkin tidak diproses. Dalam bentuk yang paling sederhana, ini dapat diaktifkan dalam pekerja layanan berbasis Workbox dengan dua baris berikut:

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

googleAnalytics.initialize();

Hal ini melacak semua peristiwa yang ada dan ping kunjungan halaman saat offline, tetapi Anda tidak akan tahu bahwa peristiwa tersebut terjadi secara offline (karena peristiwa tersebut hanya diputar ulang apa adanya). Untuk ini, Anda dapat memanipulasi permintaan pelacakan dengan Workbox dengan menambahkan tanda offline ke ping analisis, menggunakan dimensi kustom (cd1 dalam contoh kode di bawah):

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

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

Bagaimana jika pengguna keluar dari halaman karena offline, sebelum koneksi internet kembali? Meskipun hal ini biasanya membuat pekerja layanan tidur (karena tidak dapat mengirim data saat koneksi kembali), modul Google Analytics Workbox menggunakan Background Sync API, yang mengirim data analitik nanti saat koneksi kembali, meskipun pengguna menutup tab atau browser.

Masih ada kekurangan: meskipun hal ini membuat pelacakan yang ada dapat digunakan secara offline, Anda kemungkinan besar tidak akan melihat banyak data relevan yang masuk hingga Anda menerapkan mode offline dasar. Pengguna akan tetap meninggalkan situs Anda dengan cepat saat koneksi terputus. Namun, sekarang Anda setidaknya dapat mengukur dan mengukurnya, dengan membandingkan durasi sesi rata-rata dan engagement pengguna untuk pengguna dengan dimensi offline yang diterapkan dibandingkan dengan pengguna reguler Anda.

SPA dan pemuatan lambat

Jika pengguna yang mengunjungi halaman yang dibuat sebagai situs multi-halaman offline dan mencoba menavigasi, halaman offline default browser akan muncul, membantu pengguna memahami apa yang terjadi. Namun, halaman yang dibangun sebagai aplikasi web satu halaman berfungsi secara berbeda. Pengguna tetap berada di halaman yang sama, dan konten baru dimuat secara dinamis melalui AJAX tanpa navigasi browser. Pengguna tidak melihat halaman error browser saat offline. Sebagai gantinya, bagian dinamis halaman akan dirender dengan error, beralih ke status yang tidak ditentukan, atau berhenti menjadi dinamis.

Efek serupa dapat terjadi dalam situs multi-halaman karena pemuatan lambat. Misalnya, mungkin pemuatan awal terjadi secara online, tetapi pengguna offline sebelum men-scroll. Semua konten yang dimuat lambat di bawah fold akan gagal dan hilang secara otomatis.

Karena kasus ini sangat mengganggu pengguna, maka masuk akal untuk melacaknya. Service worker adalah tempat yang tepat untuk menangkap error jaringan, dan pada akhirnya melacaknya menggunakan analisis. Dengan Workbox, pengendali penanganan global dapat dikonfigurasi untuk memberi tahu halaman tentang permintaan yang gagal dengan mengirim peristiwa pesan:

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();

  }());
});

Cara lain adalah dengan menangkap error pada rute tertentu saja, bukan memproses semua permintaan yang gagal. Misalnya, jika ingin melaporkan error yang terjadi di rute hanya ke /products/*, kita dapat menambahkan pemeriksaan di setCatchHandler yang memfilter URI dengan ekspresi reguler. Solusi yang lebih bersih adalah menerapkan registerRoute dengan pengendali kustom. Hal ini mengenkapsulasi logika bisnis ke dalam rute terpisah, dengan kemampuan pemeliharaan yang lebih baik di pekerja layanan yang lebih kompleks:

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();
    }
  }
);

Sebagai langkah terakhir, halaman perlu memproses peristiwa message, dan mengirimkan ping analisis. Sekali lagi, pastikan untuk melakukan buffering permintaan analisis yang terjadi secara offline dalam service worker. Seperti yang dijelaskan sebelumnya, lakukan inisialisasi plugin workbox-google-analytics untuk dukungan Google Analytics bawaan.

Contoh berikut menggunakan Google Analytics, tetapi dapat diterapkan dengan cara yang sama untuk vendor analisis lainnya.

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
      });
    }
  });
}

Tindakan ini akan melacak pemuatan resource yang gagal di Google Analytics, tempat pemuatan tersebut dapat dianalisis dengan pelaporan. Insight turunan dapat digunakan untuk meningkatkan caching dan penanganan error service worker secara umum, untuk membuat halaman lebih andal dan dapat diandalkan dalam kondisi jaringan yang tidak stabil.

Langkah berikutnya

Artikel ini menunjukkan berbagai cara melacak penggunaan offline beserta kelebihan dan kekurangannya. Meskipun dapat membantu mengukur jumlah pengguna Anda yang offline dan mengalami masalah karenanya, ini baru permulaan. Selama situs Anda tidak menawarkan mode offline yang dibuat dengan baik, Anda jelas tidak akan melihat banyak penggunaan offline di Analytics.

Sebaiknya terapkan pelacakan lengkap, lalu perluas kemampuan offline Anda dalam iterasi dengan memperhatikan nomor pelacakan. Mulailah dengan halaman error offline sederhana terlebih dahulu–dengan Workbox, hal ini mudah dilakukan–dan harus dianggap sebagai praktik terbaik UX yang mirip dengan halaman 404 kustom. Kemudian, lanjutkan ke penggantian offline yang lebih canggih dan akhirnya ke konten offline yang sebenarnya. Pastikan Anda mengiklankan dan menjelaskan hal ini kepada pengguna, dan Anda akan melihat peningkatan penggunaan. Lagi pula, semua orang terkadang offline.

Lihat Cara melaporkan metrik dan membangun budaya performa dan Memperbaiki kecepatan situs secara lintas fungsi untuk mendapatkan tips cara meyakinkan pemangku kepentingan lintas fungsi untuk berinvestasi lebih banyak di situs Anda. Meskipun berfokus pada performa, postingan tersebut akan membantu Anda mendapatkan ide umum tentang cara berinteraksi dengan pemangku kepentingan.

Foto utama oleh JC Gellidon di Unsplash.