Çevrimdışı kullanımı ölçme

Sitenizin çevrimdışı kullanımını izleyerek sitenizin neden daha iyi bir çevrimdışı deneyime ihtiyaç duyduğunu açıklama

Stephan Giesau

Martin Schierle

Sitenizin çevrimdışı kullanımını nasıl izleyeceğinizi öğrenin. Böylece sitenizin neden daha iyi bir çevrimdışı moda ihtiyacı olduğunu açıklayabilirsiniz. Çevrimdışı kullanım analizlerini uygularken kaçınmanız gereken hataları ve sorunları öğrenin.

Online ve çevrimdışı tarayıcı etkinliklerinin dezavantajları

Çevrimdışı kullanımı izlemenin en belirgin çözümü, online ve offline etkinlikleri (birçok tarayıcı tarafından desteklenir) için etkinlik işleyiciler oluşturmak ve analiz izleme mantığınızı bu işleyicilere yerleştirmektir. Maalesef bu yaklaşımın çeşitli sorunları ve sınırlamaları vardır:

• Genel olarak her ağ bağlantısı durumu etkinliğini izlemek aşırı olabilir ve mümkün olduğunca az verinin toplanması gereken gizlilik odaklı bir dünyada ters etki yaratır. Ayrıca online ve offline etkinlikleri, kullanıcının muhtemelen görmeyeceği veya fark etmeyeceği bir saniyelik ağ kaybı için bile tetiklenebilir.
• Çevrimdışı etkinliğin Analytics izleme verileri Analytics sunucusuna ulaşmaz.
• Kullanıcı çevrimdışı olduğunda yerel olarak bir zaman damgası izlemek ve kullanıcı tekrar çevrimiçi olduğunda çevrimdışı etkinliği analiz sunucusuna göndermek, kullanıcının sitenizi tekrar ziyaret etmesine bağlıdır. Kullanıcı, çevrimdışı modun olmaması nedeniyle sitenizden ayrılır ve bir daha ziyaret etmezse bunu izlemeniz mümkün olmaz. Çevrimdışı ayrılmaları izleyebilmek, sitenizin neden daha iyi bir çevrimdışı moda ihtiyacı olduğuyla ilgili bir gerekçe oluşturmak için kritik bir veridir.
• online etkinliği, internet erişimi hakkında değil yalnızca ağ erişimi hakkında bilgi sahibi olduğu için pek güvenilir değildir. Bu nedenle, kullanıcı hâlâ çevrimdışı olabilir ve izleme ping'i gönderilemeyebilir.
• Kullanıcı çevrimdışıyken mevcut sayfada kalsa bile diğer analiz etkinliklerinin (ör.kaydırma etkinlikleri, tıklamalar vb.) hiçbiri izlenmez. Bu etkinlikler daha alakalı ve faydalı bilgiler sağlayabilir.
• Sadece çevrimdışı olmak pek anlamlı değil. En önemli şey, hangi kaynakların yüklenemediğini bilmektir. Bu durum özellikle, ağ bağlantısının kesilmesinin tarayıcıda çevrimdışı hata sayfasına yol açmayabileceği tek sayfalık uygulamalar (SPA) için geçerlidir. Bunun yerine, sayfanın rastgele, dinamik bölümlerinin sessizce başarısız olmasına neden olabilir.

Çevrimdışı kullanım hakkında temel bir anlayış kazanmak için bu çözümü kullanmaya devam edebilirsiniz ancak birçok dezavantaj ve sınırlamanın dikkatlice değerlendirilmesi gerekir.

Daha iyi bir yaklaşım: Hizmet çalışanı

Çevrimdışı modu etkinleştiren çözüm, çevrimdışı kullanımı izlemek için de daha iyi bir çözümdür. Kullanıcı çevrimdışı olduğu sürece analiz ping'lerini IndexedDB'de depolayabilir ve kullanıcı tekrar çevrimiçi olduğunda yeniden gönderebilirsiniz. Google Analytics için bu özellik bir Workbox modülünde zaten mevcut. Ancak dört saatten daha uzun süre ertelenen isabetlerin işlenmeyebileceğini unutmayın.

En basit haliyle, Workbox tabanlı bir hizmet çalışanında şu iki satırla etkinleştirilebilir:

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

googleAnalytics.initialize();

Bu, çevrimdışıyken mevcut tüm etkinlikleri ve sayfa görüntüleme ping'lerini izler ancak bunlar olduğu gibi yeniden oynatıldığından çevrimdışı gerçekleştiğini bilemezsiniz. Analytics ping'ine bir offline işareti ekleyerek özel bir boyut kullanarak Workbox ile izleme isteklerini değiştirebilirsiniz:

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

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

Kullanıcı, internet bağlantısı geri gelmeden önce çevrimdışı olduğu için sayfadan ayrılırsa ne olur? Bu durum normalde hizmet çalışanını uyku moduna geçirir. Bağlantı geri geldiğinde verileri gönderemediği için Workbox Google Analytics modülü, Background Sync API'yi kullanır. Arka Planda Senkronizasyon, kullanıcı sekmeyi veya tarayıcıyı kapatsa bile bağlantı geri geldiğinde analiz verilerini gönderir.

Ancak bir dezavantaj var: Bu yöntem mevcut izleme sistemini çevrimdışı çalışabilir hale getirse de temel bir çevrimdışı mod uygulamadan önce çok fazla alakalı veri göremeyebilirsiniz. Bağlantı koptuğunda kullanıcılar sitenizden hızlıca ayrılır. Ancak artık çevrimdışı boyutun uygulandığı kullanıcıların ortalama oturum süresini ve kullanıcı etkileşimini normal kullanıcılarınızla karşılaştırarak bunu en azından ölçebilir ve miktarını belirleyebilirsiniz.

Tek sayfalı uygulamalar ve geç yükleme

Çok sayfalı bir web sitesi olarak oluşturulmuş bir sayfayı ziyaret eden kullanıcılar çevrimdışı olup gezinmeye çalışırsa tarayıcının varsayılan çevrimdışı sayfası gösterilir ve kullanıcıların ne olduğunu anlamasına yardımcı olur. Ancak tek sayfalık uygulama olarak oluşturulan sayfalar farklı şekilde çalışır. Kullanıcı aynı sayfada kalır ve yeni içerik, tarayıcıda gezinme olmadan AJAX aracılığıyla dinamik olarak yüklenir. Kullanıcılar çevrimdışı olduklarında tarayıcı hata sayfasını görmez. Bunun yerine, sayfanın dinamik bölümleri hatalarla oluşturulur, tanımlanmamış durumlara girer veya dinamik olmayı bırakır.

Geç yükleme nedeniyle çok sayfalı web sitelerinde de benzer etkiler görülebilir. Örneğin, ilk yükleme internete bağlıyken gerçekleşmiş ancak kullanıcı sayfayı kaydırmadan önce çevrimdışı olmuş olabilir. Ekranın alt kısmında geç yüklenen tüm içerikler sessizce başarısız olur ve eksik kalır.

Bu durumlar kullanıcılar için gerçekten can sıkıcı olduğundan bunları izlemek mantıklıdır. Hizmet çalışanları, ağ hatalarını yakalamak ve analizleri kullanarak bunları izlemek için mükemmel bir yerdir. Workbox ile, bir mesaj etkinliği göndererek sayfayı başarısız istekler hakkında bilgilendirmek için global bir yakalama işleyici yapılandırılabilir:

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

  }());
});

Başarısız olan tüm istekleri dinlemek yerine, yalnızca belirli rotalardaki hataları yakalamak da başka bir yöntemdir. Örneğin, yalnızca /products/* rotalarında gerçekleşen hataları bildirmek istiyorsak setCatchHandler içine URI'yi normal ifadeyle filtreleyen bir kontrol ekleyebiliriz.

Daha temiz bir çözüm, özel bir işleyiciyle registerRoute uygulamaktır. Bu, iş mantığını ayrı bir rotaya kapsüller ve daha karmaşık hizmet çalışanlarında daha iyi sürdürülebilirlik sağlar:

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

Son adım olarak sayfanın message etkinliğini dinlemesi ve analiz ping'ini göndermesi gerekir. Çevrimdışı gerçekleşen analiz isteklerini hizmet çalışanında arabelleğe almayı unutmayın. Daha önce açıklandığı gibi, yerleşik Google Analytics desteği için workbox-google-analytics eklentisini ilk kullanıma hazırlayın.

Aşağıdaki örnekte Google Analytics kullanılmaktadır ancak aynı yöntem diğer analiz tedarikçileri için de uygulanabilir.

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

Bu, Google Analytics'te başarısız kaynak yüklemelerini izler ve burada raporlama ile analiz edilebilir. Elde edilen analiz, hizmet çalışanı önbelleğe alma ve hata işleme işlemlerini genel olarak iyileştirmek, sayfayı kararsız ağ koşullarında daha sağlam ve güvenilir hale getirmek için kullanılabilir.

Sonraki adımlar

Çevrimdışı kullanımı izlemenin farklı yollarını, avantajlarını ve eksikliklerini öğrendiniz. Bu, kaç kullanıcınızın çevrimdışı olduğunu ve bu nedenle sorun yaşadığını ölçmenize yardımcı olsa da yalnızca bir başlangıçtır. Web siteniz iyi tasarlanmış bir çevrimdışı mod sunmadığı sürece analizlerde çevrimdışı kullanımın çok fazla olmadığını görürsünüz.

Tam izleme özelliğini etkinleştirmenizi ve ardından izlemeye odaklanarak çevrimdışı özelliklerinizi yinelemelerle genişletmenizi öneririz. Çevrimdışı hata sayfasıyla başlayın. Bu, Workbox ile kolayca oluşturulabilir ve özel 404 sayfalarına benzer bir kullanıcı deneyimi en iyi uygulamasıdır. Ardından, daha gelişmiş çevrimdışı yedekler ve son olarak gerçek çevrimdışı içerikler için çalışın. Bunu kullanıcılarınıza iyi bir şekilde duyurup açıkladığınızda kullanımın arttığını göreceksiniz. Sonuçta herkes zaman zaman çevrimdışı olur.

Çapraz işlevli paydaşları web sitenize daha fazla yatırım yapmaya ikna etme konusunda ipuçları için Metrikleri raporlama ve performans kültürü oluşturma ve Web sitesi hızını çapraz işlevli olarak düzeltme başlıklı makalelere göz atın. Bu gönderiler performansa odaklanmış olsa da paydaşlarla nasıl etkileşim kuracağınız konusunda genel fikirler edinmenize yardımcı olacaktır.