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

Artikel ini menunjukkan cara melacak penggunaan offline situs Anda untuk membantu Anda membuat alasan mengapa situs Anda memerlukan mode offline yang lebih baik. Panduan ini juga menjelaskan masalah dan jebakan yang harus dihindari saat menerapkan analisis penggunaan 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, yang hanya boleh mengumpulkan data 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 ada 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 tetap berada di halaman saat ini saat offline, tidak ada peristiwa analytics lainnya (misalnya, peristiwa scroll, klik, dll.) yang dilacak, yang mungkin merupakan 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 sangat relevan dalam konteks SPA, saat koneksi jaringan yang terputus mungkin tidak mengarah ke halaman error browser offline (yang dipahami pengguna), tetapi lebih cenderung ke bagian dinamis acak dari halaman yang gagal secara diam-diam.

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 bentuknya yang paling sederhana, fitur 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 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. Pengguna tidak melihat halaman error browser saat offline. Sebagai gantinya, bagian dinamis halaman 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 menjengkelkan bagi pengguna, sebaiknya lacak kasus tersebut. 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();

  }());
});

Daripada memproses semua permintaan yang gagal, cara lain adalah dengan mendeteksi error hanya pada rute tertentu. Misalnya, jika ingin melaporkan error yang terjadi di rute ke /products/* saja, 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 harus memproses peristiwa message, dan mengirim 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 hal ini dapat membantu mengukur jumlah pengguna yang offline dan mengalami masalah karenanya, ini masih merupakan awal. 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 dengan baik, 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 hero oleh JC Gellidon di Unsplash.