Halaman ini diterjemahkan oleh Cloud Translation API.

Mengukur penggunaan offline

Cara melacak penggunaan offline situs agar Anda dapat menjelaskan alasan situs memerlukan pengalaman offline yang lebih baik.

Stephan Giesau

Martin Schierle

Artikel ini menunjukkan cara melacak penggunaan offline situs Anda untuk membantu menjelaskan alasan situs membutuhkan mode offline yang lebih baik. Dokumen ini juga menjelaskan tentang perangkap 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 online dan Peristiwa offline (yang banyak browser mendukung) dan untuk menempatkan pelacakan analisis Anda logika pada pemroses tersebut. Sayangnya, ada beberapa masalah dan batasan dengan pendekatan:

Pada umumnya, melacak setiap peristiwa status koneksi jaringan mungkin berlebihan, dan kontraproduktif di dunia yang berfokus pada privasi di mana data seminimal mungkin dapat kumpulkan. Selain itu, peristiwa online dan offline dapat diaktifkan hanya selama sepersekian detik kehilangan jaringan, yang mungkin tidak akan dilihat atau disadari oleh pengguna.
Pelacakan analitik aktivitas offline tidak akan pernah mencapai server analitik karena pengguna itu... 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 {i>offline<i} dan tidak pernah mengunjunginya kembali, Anda harus tidak ada cara untuk melacak itu. Kemampuan untuk melacak penurunan pengguna secara {i>offline<i} adalah data penting untuk membangun yang menjelaskan mengapa situs membutuhkan mode offline yang lebih baik.
Peristiwa online tidak terlalu andal karena hanya mengetahui tentang akses jaringan, bukan akses internet. Oleh karena itu, pengguna mungkin masih offline, dan mengirim ping pelacakan dapat masih gagal.
Meskipun pengguna masih berada di halaman saat ini selagi offline, tidak satu pun peristiwa analitik (mis. peristiwa gulir, klik, dll.) juga akan dilacak, yang mungkin lebih informasi yang relevan dan berguna.
Secara umum, offline juga tidak terlalu berarti. Sebagai pengembang situs web, mungkin lebih penting untuk mengetahui jenis sumber daya apa yang gagal dimuat. Hal ini sangat relevan dalam konteks SPA, yaitu terputusnya koneksi jaringan mungkin tidak menyebabkan browser offline halaman error (yang dipahami pengguna) tetapi lebih cenderung ke bagian dinamis acak pada halaman yang gagal secara diam-diam.

Anda masih bisa menggunakan solusi ini untuk mendapatkan pemahaman dasar tentang penggunaan offline, tetapi kekurangan dan keterbatasan perlu dipertimbangkan dengan cermat.

Pendekatan yang lebih baik: pekerja layanan

Solusi yang mengaktifkan mode offline ternyata menjadi solusi yang lebih baik untuk pelacakan offline tingkat penggunaan. Ide dasarnya adalah menyimpan ping analisis ke SharedPreferences selama pengguna sedang offline, dan mengirimnya kembali ketika pengguna kembali {i>online<i}. Untuk Google Analytics, fitur ini sudah tersedia siap pakai melalui modul Workbox, Namun perlu diingat bahwa hit mengirim lebih dari ditangguhkan selama empat jam mungkin tidak diproses. Dalam bentuk yang paling sederhana, dapat diaktifkan dalam layanan berbasis {i>Workbox<i} 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 terjadi secara offline (karena 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 kode contoh di bawah):

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

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

Bagaimana jika pengguna keluar dari halaman karena sedang offline, sebelum koneksi internet masuk kembali? Meskipun ini biasanya membuat pekerja layanan tidur sebentar (karena tidak dapat mengirim data saat koneksi kembali), modul Workbox Google Analytics menggunakan Sinkronisasi Latar Belakang API, yang mengirimkan analisis data nanti ketika koneksi kembali, bahkan jika pengguna menutup tab atau {i>browser<i}.

Masih ada kekurangan: meskipun hal ini membuat pelacakan yang ada dapat dilakukan offline, kemungkinan besar Anda akan tidak melihat banyak data yang relevan masuk sebelum Anda menerapkan mode offline dasar. Pengguna masih akan meninggalkan situs Anda dengan cepat ketika koneksi terputus. Tapi sekarang Anda setidaknya dapat mengukur dan mengukurnya, dengan membandingkan durasi sesi rata-rata dan interaksi pengguna untuk yang diterapkan versus pengguna reguler.

SPA dan pemuatan lambat

Jika pengguna yang mengunjungi halaman yang dibuat sebagai situs multi-halaman masuk ke mode offline dan mencoba bernavigasi, browser halaman offline default muncul, membantu pengguna memahami apa yang sedang terjadi. Namun, laman yang dibuat sebagai aplikasi web satu halaman bekerja secara berbeda. Pengguna tetap berada di laman yang sama, dan konten baru dimuat secara dinamis melalui AJAX tanpa navigasi browser apa pun. Pengguna tidak melihat error browser saat offline. Sebaliknya, bagian dinamis laman dirender dengan kesalahan, 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 menggulir. Semua konten yang dimuat dengan lambat di paruh bawah secara diam-diam akan gagal dan hilang.

Karena kasus ini sangat mengganggu pengguna, maka masuk akal untuk melacaknya. Service worker adalah tempat yang tepat untuk menangkap {i>error<i} jaringan, dan akhirnya melacaknya menggunakan analitik. 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();

  }());
});

Daripada memproses semua permintaan yang gagal, cara lain adalah dengan menangkap error pada rute tertentu saja. Sebagai contoh, jika ingin melaporkan error yang terjadi pada rute ke /products/* saja, kita dapat tambahkan tanda centang di setCatchHandler yang memfilter URI dengan ekspresi reguler. Solusi yang lebih bersih adalah menerapkan registerRoute dengan pengendali khusus. Fungsi ini mengenkapsulasi logika bisnis ke dalam rute terpisah, dengan kemudahan 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 perlu memproses peristiwa message, dan mengirimkan ping analisis. Sekali lagi, pastikan untuk mem-buffer permintaan analisis yang terjadi secara offline dalam pekerja layanan. Sebagai dijelaskan sebelumnya, lakukan inisialisasi plugin workbox-google-analytics untuk Google Analytics bawaan dukungan teknis IT.

Contoh berikut menggunakan Google Analytics, tetapi dapat diterapkan dengan cara yang sama untuk analisis lainnya vendor.

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

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

Langkah berikutnya

Artikel ini menunjukkan berbagai cara melacak penggunaan offline dengan kelebihan dan kekurangannya. Meskipun ini dapat membantu mengukur berapa banyak pengguna Anda yang menjadi {i>offline<i} 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 Analytics.

Sebaiknya dapatkan pelacakan lengkap, lalu perluas kemampuan offline Anda di iterasi dengan memperhatikan jumlah pelacakan. Mulai dengan halaman error offline sederhana terlebih dahulu, dengan Workbox yang mudah tindakan–dan harus dianggap sebagai praktik terbaik UX yang mirip dengan laman 404 khusus. Lalu lakukan sesuai keinginan penggantian offline yang lebih canggih dan terakhir ke konten offline nyata. Pastikan Anda mengiklankan dan menjelaskan hal ini kepada pengguna dan Anda akan melihat penggunaan yang meningkat. Lagi pula, semua orang terkadang offline.

Lihat Cara melaporkan metrik dan membangun budaya performa dan Memperbaiki kecepatan situs secara lintas fungsi untuk mendapatkan tips untuk membujuk pemangku kepentingan lintas fungsi untuk berinvestasi lebih banyak di {i>website<i} Anda. Meskipun kiriman tersebut berfokus pada kinerja, melainkan dapat membantu Anda memperoleh gagasan umum tentang cara melibatkan pemangku kepentingan proyek.

Foto utama oleh JC Gellidon di Unsplash.