Mengukur penggunaan offline

Cara melacak penggunaan offline situs Anda sehingga Anda dapat memberikan alasan mengapa situs Anda memerlukan pengalaman offline yang lebih baik.

Stephan Giesau

Martin Schierle

Pelajari cara melacak penggunaan offline situs Anda, sehingga Anda dapat menjelaskan alasan mengapa situs Anda memerlukan mode offline yang lebih baik. Pahami potensi kesalahan dan masalah yang harus dihindari saat menerapkan analisis penggunaan offline.

Kesalahan umum pada 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 kontraproduktif dalam dunia yang berfokus pada privasi, di mana sesedikit mungkin data yang harus dikumpulkan. Selain itu, peristiwa online dan offline dapat dipicu hanya dalam sepersekian detik saat jaringan hilang, yang mungkin tidak akan dilihat atau disadari oleh pengguna.
• Pelacakan analisis aktivitas offline tidak menjangkau server analisis.
• Melacak stempel waktu secara lokal saat pengguna offline dan mengirimkan aktivitas offline ke server Analytics 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 penghentian 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.
• Tidak terhubung ke internet saja tidak terlalu berarti. Anda mungkin perlu mengetahui resource mana yang gagal dimuat. Hal ini sangat relevan untuk aplikasi web satu halaman (SPA), yang koneksi jaringannya terputus mungkin tidak mengarah ke halaman error offline browser, yang dipahami pengguna. Sebaliknya, hal ini kemungkinan menyebabkan bagian halaman dinamis acak gagal tanpa pemberitahuan.

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

Pendekatan yang lebih baik: pekerja layanan

Solusi yang mengaktifkan mode offline juga merupakan solusi yang lebih baik untuk melacak penggunaan offline. Anda dapat menyimpan ping analisis di IndexedDB selama pengguna sedang offline, dan mengirimkannya kembali saat pengguna kembali online. Untuk Google Analytics, fitur ini sudah tersedia di modul Workbox, tetapi perlu diingat bahwa hit yang ditunda lebih dari empat jam 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 dan ping tayangan halaman yang ada saat offline, tetapi Anda tidak akan tahu bahwa peristiwa tersebut terjadi saat offline, karena hanya diputar ulang apa adanya. Anda dapat memanipulasi permintaan pelacakan dengan Workbox dengan menambahkan tanda offline ke ping Analytics, menggunakan dimensi kustom:

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

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

Bagaimana jika pengguna keluar dari halaman karena offline, sebelum koneksi internet kembali? Meskipun biasanya membuat pekerja layanan tidak aktif, karena tidak dapat mengirim data saat koneksi kembali, modul Google Analytics Workbox menggunakan Background Sync API. Sinkronisasi Latar Belakang mengirim data analisis saat koneksi kembali, meskipun pengguna menutup tab atau browser.

Namun, masih ada kekurangan: meskipun cara ini membuat pelacakan yang ada dapat dilakukan secara offline, kemungkinan besar Anda tidak akan melihat banyak data yang relevan masuk hingga Anda menerapkan mode offline dasar. Pengguna akan tetap keluar dari situs Anda dengan cepat saat koneksi terputus. Namun, kini Anda setidaknya dapat mengukur dan menguantifikasi hal ini dengan membandingkan durasi sesi rata-rata dan engagement pengguna untuk pengguna dengan dimensi offline yang diterapkan versus pengguna reguler Anda.

SPA dan pemuatan lambat

Jika pengguna yang mengunjungi halaman yang dibuat sebagai situs multi-halaman offline dan mencoba menjelajah, halaman offline default browser akan muncul, sehingga membantu pengguna memahami apa yang terjadi. Namun, halaman yang dibuat sebagai aplikasi halaman tunggal 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. Sebagai gantinya, 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, pemuatan awal terjadi secara online, tetapi pengguna menjadi offline sebelum men-scroll. Semua konten yang dimuat lambat di bawah fold akan gagal tanpa pemberitahuan dan hilang.

Karena kasus ini sangat menjengkelkan bagi pengguna, sebaiknya lacak kasus ini. Service worker adalah tempat yang tepat untuk menangkap error jaringan, dan akhirnya melacaknya menggunakan analytics. Dengan Workbox, catch handler 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();

  }());
});

Daripada memantau semua permintaan yang gagal, cara lain adalah menangkap error hanya pada rute tertentu. Sebagai contoh, jika kita 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 mencakup logika bisnis ke dalam rute terpisah, dengan 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 melakukan buffering permintaan analisis yang terjadi secara offline dalam pekerja layanan. Seperti yang dijelaskan sebelumnya, lakukan inisialisasi plugin workbox-google-analytics untuk dukungan Google Analytics internal.

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

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

Langkah berikutnya

Anda telah mempelajari berbagai cara melacak penggunaan offline beserta kelebihan dan kekurangannya. Meskipun dapat membantu mengukur jumlah pengguna yang offline dan mengalami masalah karena hal tersebut, ini hanyalah permulaan. Selama situs Anda tidak menawarkan mode offline yang dibuat dengan baik, Anda jelas tidak akan melihat banyak penggunaan offline dalam analisis.

Sebaiknya siapkan pelacakan lengkap, lalu perluas kemampuan offline Anda secara berulang, dengan fokus pada pelacakan. Mulai dengan halaman error offline. Hal ini mudah dibuat dengan Workbox dan merupakan praktik terbaik UX yang mirip dengan halaman 404 kustom. Kemudian, kerjakan 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. Lagipula, semua orang terkadang offline.

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