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

Bu makale, sitenizin neden daha iyi bir çevrimdışı moda ihtiyaç duyduğunu anlamanıza yardımcı olmak için sitenizin çevrimdışı kullanımını nasıl izleyeceğinizi gösterir. Ayrıca, çevrimdışı kullanım analitiğini uygularken kaçınılması gereken tuzakları ve sorunları da açıklar.

Çevrimiçi ve çevrimdışı tarayıcı olaylarının tuzakları #

Çevrimdışı kullanımı izlemenin bariz çözümü, kullanıcı için olay dinleyicileri oluşturmaktır. online Ve offline olaylar (hangi birçok tarayıcı desteği) ve analitik izleme mantığınızı bu dinleyicilere yerleştirmek için. Ne yazık ki, bu yaklaşımla ilgili birkaç sorun ve sınırlama var:

• Genel olarak, her ağ bağlantısı durumu olayının izlenmesi aşırı olabilir ve mümkün olduğunca az verinin toplanması gereken gizlilik merkezli bir dünyada verimsiz olabilir. ek olarak online Ve offline olaylar, bir kullanıcının muhtemelen görmeyeceği veya fark etmeyeceği, yalnızca bir saniyelik ağ kaybı için tetiklenebilir.
• Çevrimdışı etkinliğin analitik izlemesi, kullanıcı… eh, çevrimdışı olduğu için asla analiz sunucusuna ulaşmaz.
• Bir kullanıcı çevrimdışı olduğunda yerel olarak bir zaman damgasını 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 sitenizi bırakırsa ve bir daha asla ziyaret etmezse, bunu izlemenizin hiçbir yolu yoktur. Çevrimdışı ayrılmaları izleme yeteneği, sitenizin neden daha iyi bir çevrimdışı moda ihtiyaç duyduğu hakkında bir durum oluşturmak için kritik verilerdir.
• bu online olay çok güvenilir değil çünkü sadece ağ erişimini bilir, internet erişimi değil. Bu nedenle, bir kullanıcı hala çevrimdışı olabilir ve izleme pingini gönderme işlemi yine başarısız olabilir.
• Kullanıcı çevrimdışıyken geçerli sayfada kalsa bile, diğer analiz olaylarının hiçbiri (örn. kaydırma etkinlikleri, tıklamalar vb.) izlenmez, bu daha ilgili ve yararlı bilgiler olabilir.
• Kendi içinde çevrimdışı olmak da genel olarak çok anlamlı değil. Bir web sitesi geliştiricisi olarak, ne tür kaynakların yüklenemediğini bilmek daha önemli olabilir. Bu özellikle, kesilen bir ağ bağlantısının bir tarayıcı çevrimdışı hata sayfasına (kullanıcıların anladığı) yol açmayabileceği, ancak sayfanın rastgele dinamik bölümlerinin sessizce başarısız olmasına yol açabileceği SPA’lar bağlamında önemlidir.

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

Daha iyi bir yaklaşım: servis çalışanı #

Çevrimdışı modu etkinleştiren çözüm, çevrimdışı kullanımı izlemek için daha iyi bir çözüm olarak ortaya çıkıyor. Temel fikir, analitik ping’lerini kullanıcı çevrimdışı olduğu sürece IndexedDB’de depolamak ve kullanıcı tekrar çevrimiçi olduğunda bunları yeniden göndermektir. Google Analytics için bu zaten mevcut bir Workbox modülü aracılığıyla kullanıma hazırancak şundan daha fazla isabet gönderildiğini unutmayın: dört saat ertelendi işlenemez. En basit haliyle Workbox tabanlı bir servis çalışanı içerisinde şu iki satır ile aktif hale getirilebilir:

import * as googleAnalytics from 'workbox-google-analytics';
googleAnalytics.initialize();

Bu, çevrimdışıyken tüm mevcut etkinlikleri ve sayfa görüntüleme pinglerini izler, ancak bunların çevrimdışı olduğunu bilemezsiniz (çünkü oldukları gibi yeniden oynatılırlar). Bunun için izleme isteklerini Workbox ile değiştirebilirsiniz ekleyerek offline özel bir boyut kullanarak (cd1 aşağıdaki kod örneğinde):

import * as googleAnalytics from 'workbox-google-analytics';
googleAnalytics.initialize({
parameterOverrides: {
cd1: 'offline',
},
});

Kullanıcı, internet bağlantısı geri gelmeden önce çevrimdışı olduğu için sayfadan ayrılırsa ne olur? Bu, normalde hizmet çalışanını uyku moduna geçirse de (çünkü bağlantı geri geldiğinde verileri gönderemez), Workbox Google Analytics modülü Arka Plan Senkronizasyon API’sıkullanıcı sekmeyi veya tarayıcıyı kapatsa bile bağlantı geri geldiğinde analiz verilerini daha sonra gönderir.

Yine de bir dezavantaj var: Bu, mevcut izlemeyi çevrimdışı yapabilir hale getirirken, temel bir çevrimdışı modu uygulayana kadar büyük olasılıkla çok fazla ilgili verinin geldiğini görmezsiniz. Bağlantı koptuğunda kullanıcılar yine de sitenizi hızlı bir şekilde bırakacaktır. Ancak artık, ortalama oturum uzunluğunu ve çevrimdışı boyutun uygulandığı kullanıcılar için kullanıcı katılımını normal kullanıcılarınıza karşı karşılaştırarak en azından bunu ölçebilir ve nicelleştirebilirsiniz.

SPA’lar ve yavaş yükleme #

Çok sayfalı bir web sitesi olarak oluşturulmuş bir sayfayı ziyaret eden kullanıcılar çevrimdışı duruma geçer ve gezinmeye çalışırsa, tarayıcının varsayılan çevrimdışı sayfası görünür ve kullanıcıların neler olduğunu anlamalarına yardımcı olur. Ancak, tek sayfalık uygulamalar olarak oluşturulan sayfalar farklı çalışır. Kullanıcı aynı sayfada kalır ve yeni içerik, herhangi bir tarayıcı gezintisi olmadan AJAX aracılığıyla dinamik olarak yüklenir. Kullanıcılar çevrimdışıyken tarayıcı hata sayfasını görmezler. Bunun yerine, sayfanın dinamik bölümleri hatalı işleniyor, tanımsız durumlara giriyor veya dinamik olmayı bırakıyor.

Geç yükleme nedeniyle çok sayfalı web sitelerinde benzer etkiler olabilir. Örneğin, ilk yükleme çevrimiçi olmuş olabilir, ancak kullanıcı kaydırma yapmadan önce çevrimdışı olmuştur. Ekranın alt kısmına geç yüklenen tüm içerik sessizce başarısız olur ve kaybolur.

Bu durumlar kullanıcıları gerçekten rahatsız ettiğinden, onları takip etmek mantıklıdır. Hizmet çalışanları, ağ hatalarını tespit etmek ve nihayetinde bunları analitik kullanarak izlemek için mükemmel bir yerdir. Workbox ile bir küresel yakalama işleyicisi bir mesaj olayı göndererek sayfayı başarısız istekler hakkında bilgilendirmek için 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, başka bir yol da yalnızca belirli yollardaki hataları yakalamaktır. Örnek olarak, rotalarda meydana gelen hataları raporlamak istiyorsak /products/* yalnızca bir check-in ekleyebiliriz setCatchHandler URI’yi düzenli bir ifadeyle filtreleyen. Daha temiz bir çözüm, registerRoute’u özel bir işleyici ile uygulamaktır. Bu, iş mantığını daha karmaşık hizmet çalışanlarında daha iyi bakımla birlikte ayrı bir rotaya sığdırır:

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 bir adım olarak, sayfanın aşağıdakileri dinlemesi gerekir: message olay ve analitik pingini gönderin. Yine, hizmet çalışanı içinde çevrimdışı gerçekleşen analiz isteklerini arabelleğe aldığınızdan emin olun. Daha önce açıklandığı gibi, workbox-google-analytics yerleşik Google Analytics desteği için eklenti.

Aşağıdaki örnek Google Analytics’i kullanır, ancak diğer analitik tedarikçileri için aynı şekilde 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’teki başarısız kaynak yüklerini izleyecek ve burada analiz edilebilecekleri raporlama. Elde edilen içgörü, sayfayı kararsız ağ koşullarında daha sağlam ve güvenilir hale getirmek için genel olarak hizmet çalışanı önbelleğini ve hata işlemeyi iyileştirmek için kullanılabilir.

Sonraki adımlar #

Bu makale, avantajları ve eksiklikleriyle çevrimdışı kullanımı izlemenin farklı yollarını gösterdi. Bu, kaç kullanıcınızın çevrimdışı olduğunu ve bu nedenle sorunla karşılaştığını belirlemenize yardımcı olsa da, yine de yalnızca bir başlangıçtır. Web siteniz iyi oluşturulmuş bir çevrimdışı mod sunmadığı sürece, analitikte çok fazla çevrimdışı kullanım görmeyeceksiniz.

Tam izlemeyi uygulamaya koymanızı ve ardından izleme numaralarını göz önünde bulundurarak çevrim dışı yeteneklerinizi yinelemelerle genişletmenizi öneririz. Önce basit bir çevrimdışı hata sayfasıyla başlayın; Workbox bunu yapmak önemsiz–ve yine de özel 404 sayfalarına benzer bir UX en iyi uygulaması olarak düşünülmelidir. O zaman istediğin gibi çalış daha gelişmiş çevrimdışı geri dönüşlere doğru ve son olarak gerçek çevrimdışı içeriğe doğru. Reklam verdiğinizden ve bunu kullanıcılarınıza iyi anlattığınızdan emin olun, kullanımın arttığını göreceksiniz. Sonuçta, herkes arada bir çevrimdışı oluyor.

İşlevler arası paydaşları web sitenize daha fazla yatırım yapmaya ikna etmeyle ilgili ipuçları için Metrikleri raporlama ve bir performans kültürü oluşturma ve İşlevler arası web sitesi hızını düzeltme bölümlerine 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ı olmalıdır.

yazan kahraman fotoğrafı JC Gellidon Açık Unsplash.