Mengukur penggunaan offline

Cara melacak penggunaan offline situs agar Anda dapat menjelaskan alasan situs 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 menjelaskan mengapa situs Anda memerlukan mode offline yang lebih baik. Panduan ini juga menjelaskan tentang kesalahan dan masalah yang harus dihindari saat menerapkan analisis penggunaan offline.

Jebakan 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 dalam pemroses tersebut. Sayangnya, ada beberapa masalah dan batasan dengan pendekatan ini:

  • Secara umum, pelacakan setiap peristiwa status koneksi jaringan mungkin berlebihan dan bersifat kontraproduktif dalam dunia yang berfokus pada privasi dengan sesedikit mungkin data yang harus dikumpulkan. Selain itu, peristiwa online dan offline dapat diaktifkan hanya selama sepersekian detik dari kehilangan jaringan, yang mungkin tidak akan dilihat atau dilihat oleh 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 meninggalkan situs Anda karena kurangnya mode offline dan tidak pernah berkunjung kembali, Anda tidak memiliki cara untuk melacaknya. Kemampuan untuk melacak penurunan traffic offline merupakan data penting untuk membuat 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 satu pun peristiwa analisis lainnya (misalnya, peristiwa scroll, klik, dll.) yang dilacak, sehingga informasi bisa menjadi informasi yang lebih relevan dan berguna.
  • Secara umum, offline juga tidak terlalu berarti. Sebagai developer situs, mengetahui jenis resource yang gagal dimuat mungkin lebih penting. 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 gagal secara otomatis ke bagian dinamis yang acak pada halaman.

Anda tetap 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 menjadi solusi yang lebih baik untuk melacak penggunaan offline. Ide dasarnya adalah menyimpan ping analisis ke IndexedDB selama pengguna sedang offline, dan cukup mengirim ulang ping tersebut saat pengguna kembali online. Untuk Google Analytics, fungsi ini sudah tersedia siap pakai melalui modul Workbox, tetapi perlu diingat bahwa hit yang dikirim lebih dari empat jam dan ditangguhkan mungkin tidak akan 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();

Ini melacak semua peristiwa dan ping kunjungan halaman yang ada saat offline, tetapi Anda tidak akan tahu bahwa peristiwa dan ping tersebut terjadi secara offline (karena hanya di-replay apa adanya). Untuk hal ini, Anda dapat memanipulasi permintaan pelacakan dengan Workbox dengan menambahkan tanda 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 membuat pekerja layanan nonaktif (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 kekurangan: meskipun hal ini membuat pelacakan yang ada dapat digunakan secara offline, kemungkinan besar Anda tidak akan melihat banyak data yang relevan yang masuk hingga Anda menerapkan mode offline dasar. Pengguna masih akan meninggalkan situs Anda dengan cepat ketika koneksi terputus. Namun, sekarang Anda setidaknya dapat mengukur dan mengukur hal ini dengan membandingkan durasi sesi rata-rata dan engagement pengguna untuk pengguna yang menggunakan dimensi offline dengan pengguna reguler Anda.

SPA dan pemuatan lambat

Jika pengguna yang mengunjungi halaman yang dibuat sebagai situs multi-halaman saat offline dan mencoba menjelajahinya, halaman offline default browser akan muncul, sehingga 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. Sebaliknya, bagian dinamis halaman dirender dengan error, masuk 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 paruh bawah akan otomatis gagal dan hilang.

Karena kasus ini sangat mengganggu pengguna, maka masuk akal untuk melacaknya. Pekerja layanan adalah tempat yang tepat untuk menemukan error jaringan, dan pada akhirnya melacaknya menggunakan analisis. Dengan Workbox, pengendali tangkapan 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();

  }());
});

Cara lain adalah dengan menangkap error pada rute tertentu saja, bukan memproses semua permintaan yang gagal. 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 menerapkan registerRoute dengan pengendali khusus. Tindakan ini akan mengenkapsulasi logika bisnis ke dalam rute terpisah, dengan kemudahan pemeliharaan yang lebih baik pada 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 mem-buffer 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
      });
    }
  });
}

Langkah ini akan melacak pemuatan resource yang gagal di Google Analytics, tempat resource tersebut dapat dianalisis dengan pelaporan. Insight yang diperoleh dapat digunakan untuk meningkatkan kualitas cache dan penanganan error pekerja layanan secara umum, agar halaman menjadi lebih andal dan andal dalam kondisi jaringan yang tidak stabil.

Langkah berikutnya

Artikel ini menunjukkan berbagai cara melacak penggunaan offline dengan 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 analisis.

Sebaiknya dapatkan 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 ke penggantian offline yang lebih canggih dan terakhir menuju konten offline nyata. 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 membujuk pemangku kepentingan lintas fungsi agar berinvestasi lebih banyak di situs Anda. Meskipun postingan tersebut berfokus pada performa, postingan tersebut akan membantu Anda mendapatkan ide umum tentang cara melibatkan pemangku kepentingan.

Foto utama oleh JC Gellidon di Unsplash.