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 memberikan alasan mengapa situs Anda memerlukan mode offline yang lebih baik. Memahami kesalahan dan masalah yang harus dihindari saat menerapkan analisis penggunaan offline.

Kelemahan peristiwa browser online dan offline

Solusi yang jelas untuk melacak penggunaan offline adalah dengan 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 di dunia yang berfokus pada privasi, yang mengumpulkan data sesedikit mungkin. Selain itu, peristiwa online dan offline dapat diaktifkan hanya dalam waktu sepersekian detik setelah kehilangan jaringan, yang mungkin tidak akan dilihat atau diperhatikan oleh pengguna.
• Pelacakan analisis aktivitas offline tidak mencapai server analisis.
• 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 mengunjunginya lagi, 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 dapat diandalkan 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 berada di halaman saat ini saat offline, tidak ada peristiwa analisis lain (misalnya, peristiwa scroll, klik, dll.) yang dilacak, yang mungkin merupakan informasi yang lebih relevan dan berguna.
• Hanya offline tidak terlalu berarti. Hal yang paling penting untuk diketahui adalah resource apa yang gagal dimuat. Hal ini sangat relevan untuk aplikasi web satu halaman (SPA), ketika koneksi jaringan yang terputus mungkin tidak menyebabkan halaman error offline browser, yang dipahami pengguna. Sebaliknya, hal ini kemungkinan akan menyebabkan bagian halaman yang dinamis dan acak gagal tanpa ada pemberitahuan.

Anda masih 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 offline, dan mengirimkannya kembali saat pengguna online lagi. Untuk Google Analytics, hal ini sudah tersedia di modul Workbox, tetapi perlu diingat bahwa hit yang dikirim lebih dari empat jam ditangguhkan mungkin tidak diproses.

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

Tindakan ini akan melacak semua peristiwa dan ping tayangan halaman yang ada saat offline, tetapi Anda tidak akan tahu bahwa peristiwa tersebut terjadi secara offline, karena peristiwa tersebut hanya diputar ulang sebagaimana adanya. Anda dapat memanipulasi permintaan pelacakan dengan Workbox dengan menambahkan flag offline ke ping analisis, 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 hal ini 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 mengirimkan data analisis saat koneksi kembali, meskipun pengguna menutup tab atau browser.

Namun, masih ada kelemahan: meskipun hal ini membuat pelacakan yang ada dapat berfungsi secara offline, Anda kemungkinan besar 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, sekarang Anda setidaknya dapat mengukur dan menghitungnya, 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 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 akan melihat halaman error browser saat offline. Sebagai gantinya, bagian dinamis halaman akan dirender dengan error, masuk ke status tidak terdefinisi, 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 gagal dan hilang tanpa ada pemberitahuan.

Karena kasus ini sangat mengganggu pengguna, sebaiknya lacak kasus tersebut. Service worker adalah tempat yang tepat untuk menangkap 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();

  }());
});

Daripada memproses semua permintaan yang gagal, cara lain adalah dengan menangkap error hanya pada rute tertentu. Sebagai contoh, jika kita hanya ingin melaporkan error yang terjadi pada rute ke /products/*, kita dapat menambahkan pemeriksaan di setCatchHandler yang memfilter URI dengan ekspresi reguler.

Solusi yang lebih rapi adalah dengan mengimplementasikan registerRoute dengan pengendali kustom. Hal ini merangkum logika bisnis ke dalam rute terpisah, dengan 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 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 yang diperoleh dapat digunakan untuk meningkatkan penyimpanan cache service worker dan penanganan error secara umum, agar halaman menjadi lebih tangguh dan andal 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 karenanya, hal ini masih merupakan permulaan. Selama situs Anda tidak menawarkan mode offline yang dibangun dengan baik, Anda jelas tidak akan melihat banyak penggunaan offline di analisis.

Sebaiknya siapkan pelacakan lengkap, lalu perluas kemampuan offline Anda dalam iterasi, 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, upayakan penggantian offline yang lebih canggih dan terakhir, upayakan 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 tentang cara meyakinkan 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 berinteraksi dengan pemangku kepentingan.