Mengukur penggunaan offline

Cara melacak penggunaan offline situs sehingga Anda dapat menjelaskan mengapa situs Anda membutuhkan pengalaman offline yang lebih baik.

Stephan Giesau
Stephan Giesau
Martin Schierle
Martin Schierle
X GitHub

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

Perangkap peristiwa browser online dan offline

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

  • Secara umum, pelacakan setiap peristiwa status koneksi jaringan mungkin berlebihan dan kontra-produktif di dunia yang berfokus pada privasi di mana data yang dikumpulkan seminimal mungkin. Selain itu, peristiwa online dan offline dapat diaktifkan hanya selama sepersekian detik kehilangan jaringan, yang mungkin tidak akan dilihat atau diperhatikan oleh pengguna.
  • Pelacakan analisis aktivitas offline tidak akan pernah menjangkau server analisis karena pengguna... yah, 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 meninggalkan situs Anda karena tidak memiliki mode offline dan tidak pernah mengunjunginya kembali, tidak ada cara untuk melacaknya. Kemampuan untuk melacak pengguna yang berhenti secara offline merupakan data penting untuk membuat kasus tentang alasan situs Anda memerlukan mode offline yang lebih baik.
  • Peristiwa online tidak terlalu dapat diandalkan karena hanya mengetahui tentang akses jaringan, bukan akses internet. Oleh karena itu, pengguna mungkin masih offline, dan pengiriman ping pelacakan masih dapat gagal.
  • Meskipun pengguna tetap berada di halaman saat ini saat offline, tidak ada peristiwa analisis lainnya (misalnya peristiwa scroll, klik, dll.) yang dilacak, yang mungkin menjadi informasi yang lebih relevan dan berguna.
  • Menjadi {i>offline<i} juga tidak terlalu bermakna. Sebagai developer situs, mungkin lebih penting untuk mengetahui jenis resource apa yang gagal dimuat. Hal ini sangat relevan dalam konteks SPA, saat koneksi jaringan yang terputus mungkin tidak mengarah ke halaman error offline browser (yang dipahami pengguna), tetapi lebih mungkin untuk melakukan acak pada bagian dinamis halaman yang gagal tanpa pemberitahuan.

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

Pendekatan yang lebih baik: pekerja layanan

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

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

googleAnalytics.initialize();

Metode ini melacak semua peristiwa dan ping kunjungan halaman yang ada saat offline, tetapi Anda tidak akan tahu bahwa peristiwa tersebut terjadi secara offline (karena di-replay sebagaimana adanya). Untuk itu, Anda dapat memanipulasi permintaan pelacakan dengan Workbox dengan menambahkan flag offline ke ping analisis, menggunakan dimensi kustom (cd1 pada contoh kode di bawah ini):

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

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

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

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

SPA dan pemuatan lambat

Jika pengguna yang mengunjungi halaman yang dibuat sebagai situs multi-halaman menjadi offline dan mencoba menjelajah, halaman offline default browser akan muncul, sehingga membantu pengguna memahami apa yang terjadi. Namun, halaman yang dibuat 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 apa pun. Pengguna tidak melihat halaman error browser saat offline. Sebaliknya, bagian dinamis halaman dirender dengan error, beralih ke status yang tidak ditentukan, atau hanya berhenti menjadi dinamis.

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

Karena kasus ini sangat menjengkelkan bagi pengguna, masuk akal untuk melacaknya. Pekerja layanan adalah tempat yang tepat untuk menemukan error jaringan, dan pada akhirnya melacaknya menggunakan analisis. Dengan Workbox, pengendali catch global dapat dikonfigurasi untuk memberi tahu halaman tentang permintaan yang gagal dengan mengirimkan 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();

  }());
});

Selain memproses semua permintaan yang gagal, cara lainnya adalah mendeteksi error pada rute tertentu saja. Misalnya, jika ingin melaporkan error yang terjadi pada rute ke /products/* saja, kita dapat menambahkan pemeriksaan di setCatchHandler yang memfilter URI dengan ekspresi reguler. Solusi yang lebih bersih adalah dengan menerapkan registerRoute dengan pengendali kustom. Tindakan ini mengenkapsulasi logika bisnis ke dalam rute terpisah, dengan pemeliharaan yang lebih baik dalam 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 harus memproses peristiwa message, dan mengirimkan ping analisis. Sekali lagi, pastikan untuk menyangga permintaan analisis yang terjadi secara offline dalam pekerja layanan. 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, yang dapat dianalisis dengan pelaporan. Insight turunan dapat digunakan untuk meningkatkan penyimpanan cache pekerja layanan dan penanganan error secara umum, agar halaman menjadi lebih tangguh dan andal dalam kondisi jaringan yang tidak stabil.

Langkah berikutnya

Artikel ini menunjukkan berbagai cara untuk melacak penggunaan offline beserta kelebihan dan kekurangannya. Meskipun metrik ini dapat membantu mengukur jumlah pengguna yang offline dan mengalami masalah karenanya, semua itu hanyalah permulaan. Selama situs Anda tidak menawarkan mode offline yang dibuat dengan baik, jelas Anda tidak akan melihat banyak penggunaan offline dalam analisis.

Sebaiknya gunakan pelacakan lengkap, lalu perluas kemampuan offline Anda dalam iterasi dengan memperhatikan nomor pelacakan. Mulailah dengan halaman error offline sederhana terlebih dahulu–dengan Workbox mudah dilakukan–dan harus dianggap sebagai praktik terbaik UX yang mirip dengan halaman 404 kustom. Kemudian, lanjutkan menuju penggantian offline yang lebih canggih dan terakhir menuju konten offline sungguhan. Pastikan Anda memberitahukan dan menjelaskan hal ini kepada pengguna dengan baik, dan penggunaannya akan meningkat. Lagi pula, semua orang kadang-kadang offline.

Lihat Cara melaporkan metrik dan membangun budaya performa dan Memperbaiki kecepatan situs lintas fungsi untuk mendapatkan tips tentang cara membujuk pemangku kepentingan lintas fungsi agar berinvestasi lebih banyak di situs Anda. Meskipun postingan tersebut difokuskan pada performa, postingan dapat membantu Anda mendapatkan gambaran umum tentang cara melibatkan pemangku kepentingan.

Foto utama oleh JC Gellidon di Unsplash.