사이트에 더 나은 오프라인 경험이 필요한 이유를 판단할 수 있도록 사이트의 오프라인 사용을 추적하는 방법
이 도움말에서는 사이트의 오프라인 사용량을 추적하여 사이트에 더 나은 오프라인 모드가 필요한 이유를 설명하는 데 도움이 되는 방법을 설명합니다. 또한 오프라인 사용 분석을 구현할 때 피해야 할 함정과 문제도 설명합니다.
온라인 및 오프라인 브라우저 이벤트의 함정
오프라인 사용 추적을 위한 명백한 해결책은 online
및 offline
이벤트 (많은 브라우저에서 지원)의 이벤트 리스너를 만들고 분석 추적 로직을 이러한 리스너에 넣는 것입니다. 안타깝게도 이 접근 방식에는 몇 가지 문제와 제한사항이 있습니다.
- 일반적으로 모든 네트워크 연결 상태 이벤트를 추적하는 것은 과도할 수 있으며, 최대한 적은 데이터를 수집해야 하는 개인 정보 보호 중심의 세상에서는 비생산적입니다. 또한
online
및offline
이벤트는 사용자가 보거나 알아차릴 수 없는 찰나의 네트워크 손실로 인해 발생할 수 있습니다. - 오프라인 활동의 분석 추적은 사용자가 오프라인 상태이므로 분석 서버에 도달하지 않습니다.
- 사용자가 오프라인 상태가 되면 로컬에서 타임스탬프를 추적하고 사용자가 다시 온라인 상태가 되면 오프라인 활동을 애널리틱스 서버로 전송하는 것은 사용자가 사이트를 다시 방문하는지에 따라 다릅니다. 오프라인 모드가 없어 사용자가 사이트에서 이탈한 후 다시 방문하지 않는 경우 이를 추적할 방법이 없습니다. 오프라인 이탈을 추적하는 기능은 사이트에 더 나은 오프라인 모드가 필요한 이유를 설명하는 데 중요한 데이터입니다.
online
이벤트는 인터넷 액세스가 아닌 네트워크 액세스만 알고 있으므로 신뢰성이 떨어집니다. 따라서 사용자는 여전히 오프라인 상태일 수 있으며 추적 핑을 보내는 데 실패할 수 있습니다.- 사용자가 오프라인 상태에서도 현재 페이지에 머물러 있더라도 더 관련성 높고 유용한 정보일 수 있는 다른 애널리틱스 이벤트 (예: 스크롤 이벤트, 클릭 등)도 추적되지 않습니다.
- 오프라인 상태 자체도 일반적으로 그다지 의미가 없습니다. 웹사이트 개발자의 경우 어떤 종류의 리소스를 로드하지 못했는지 아는 것이 더 중요할 수 있습니다. 이는 네트워크 연결이 끊겨도 사용자가 이해할 수 있는 브라우저 오프라인 오류 페이지가 표시되지 않고 페이지의 무작위 동적 부분이 자동으로 실패할 가능성이 더 높은 SPA의 맥락에서 특히 관련이 있습니다.
이 솔루션을 사용하여 오프라인 사용량에 대한 기본적인 이해를 얻을 수는 있지만 여러 단점과 제한사항을 신중하게 고려해야 합니다.
더 나은 접근 방식: 서비스 워커
오프라인 모드를 사용 설정하는 솔루션이 오프라인 사용량을 추적하는 데 더 효과적인 것으로 나타났습니다. 기본 개념은 사용자가 오프라인 상태인 동안 애널리틱스 핑을 IndexedDB에 저장하고 사용자가 다시 온라인 상태가 되면 다시 전송하는 것입니다. Google 애널리틱스에서는 이미 워크박스 모듈을 통해 즉시 사용할 수 있지만, 4시간 넘게 지연된 조회는 처리되지 않을 수 있다는 점에 유의하세요. 가장 간단한 형태로 다음 두 줄을 사용하여 Workbox 기반 서비스 워커 내에서 활성화할 수 있습니다.
import * as googleAnalytics from 'workbox-google-analytics';
googleAnalytics.initialize();
이렇게 하면 오프라인 상태에서 기존의 모든 이벤트와 페이지 조회 핑을 추적할 수 있지만, 이벤트가 오프라인에서 발생했는지 알 수는 없습니다 (있는 그대로 재생되기 때문). 이를 위해 맞춤 측정기준 (아래 코드 샘플의 cd1
)을 사용하여 분석 핑에 offline
플래그를 추가하여 Workbox로 추적 요청을 조작할 수 있습니다.
import * as googleAnalytics from 'workbox-google-analytics';
googleAnalytics.initialize({
parameterOverrides: {
cd1: 'offline',
},
});
인터넷 연결이 복원되기 전에 사용자가 오프라인 상태로 인해 페이지에서 나가면 어떻게 되나요? 이렇게 하면 일반적으로 연결이 복원될 때 데이터를 전송할 수 없으므로 서비스 워커가 절전 모드로 전환되지만 Workbox Google 애널리틱스 모듈은 백그라운드 동기화 API를 사용합니다. 이 API는 사용자가 탭이나 브라우저를 닫은 경우에도 나중에 연결이 복원되면 분석 데이터를 전송합니다.
단점이 있습니다. 이렇게 하면 기존 추적을 오프라인으로 실행할 수 있지만 기본 오프라인 모드를 구현할 때까지는 관련 데이터가 많이 수신되지 않을 가능성이 큽니다. 연결이 끊어지면 사용자는 여전히 사이트에서 빠르게 이탈합니다. 하지만 이제는 적용된 오프라인 측정기준과 일반 사용자의 평균 세션 길이와 사용자 참여도를 비교하여 최소한으로 이를 측정하고 수치화할 수 있습니다.
SPA 및 지연 로드
다중 페이지 웹사이트로 빌드된 페이지를 방문하는 사용자가 오프라인으로 전환된 후 탐색하려고 하면 브라우저의 기본 오프라인 페이지가 표시되어 사용자가 상황을 이해하는 데 도움이 됩니다. 그러나 싱글페이지 애플리케이션으로 빌드된 페이지는 다르게 작동합니다. 사용자는 동일한 페이지에 머물고 브라우저 탐색 없이 AJAX를 통해 새 콘텐츠가 동적으로 로드됩니다. 사용자가 오프라인 상태로 전환해도 브라우저 오류 페이지가 표시되지 않습니다. 대신 페이지의 동적 부분이 오류와 함께 렌더링되거나 정의되지 않은 상태로 전환되거나 동적 상태가 중지됩니다.
지연 로드로 인해 여러 페이지 웹사이트 내에서도 유사한 효과가 발생할 수 있습니다. 예를 들어 초기 로드는 온라인에서 이루어졌지만 사용자가 스크롤하기 전에 오프라인 상태가 되었을 수 있습니다. 스크롤해야 볼 수 있는 부분의 모든 지연 로드 콘텐츠는 자동으로 실패하고 누락됩니다.
이러한 케이스는 사용자에게 매우 불편을 주므로 추적하는 것이 좋습니다. 서비스 워커는 네트워크 오류를 포착하고 결국 분석을 사용하여 추적하기에 적합한 위치입니다. Workbox를 사용하면 메시지 이벤트를 전송하여 페이지에 실패한 요청을 알리도록 전역 포착 핸들러를 구성할 수 있습니다.
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();
}());
});
실패한 모든 요청을 리슨하는 대신 특정 경로에서만 오류를 포착하는 방법도 있습니다. 예를 들어 /products/*
경로에서 발생하는 오류만 보고하려면 정규 표현식으로 URI를 필터링하는 검사를 setCatchHandler
에 추가하면 됩니다.
더 깔끔한 해결책은 맞춤 핸들러로 registerRoute를 구현하는 것입니다. 이렇게 하면 비즈니스 로직을 별도의 경로로 캡슐화하여 더 복잡한 서비스 워커에서 유지보수성을 개선할 수 있습니다.
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();
}
}
);
마지막 단계로 페이지에서 message
이벤트를 수신 대기하고 애널리틱스 핑을 전송해야 합니다.
다시 말하지만, 오프라인에서 발생하는 분석 요청을 서비스 워커 내에서 버퍼링해야 합니다. 앞에서 설명한 대로 내장 Google 애널리틱스 지원을 위해 workbox-google-analytics
플러그인을 초기화합니다.
다음 예에서는 Google 애널리틱스를 사용하지만 다른 분석 공급업체에도 동일한 방식으로 적용할 수 있습니다.
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
});
}
});
}
이렇게 하면 Google 애널리틱스에서 실패한 리소스 로드가 추적되며 보고를 통해 분석할 수 있습니다. 파생된 통계는 일반적으로 서비스 워커 캐싱 및 오류 처리를 개선하여 불안정한 네트워크 조건에서 페이지의 안정성과 신뢰성을 높이는 데 사용할 수 있습니다.
다음 단계
이 도움말에서는 오프라인 사용을 추적하는 다양한 방법과 장단점에 대해 알아봤습니다. 이렇게 하면 오프라인 상태가 되어 문제가 발생한 사용자 수를 수치화하는 데 도움이 되지만, 아직 시작에 불과합니다. 웹사이트에서 제대로 구축된 오프라인 모드를 제공하지 않는 한 애널리틱스에서 오프라인 사용량이 많지 않을 것입니다.
전체 추적을 설정한 다음 추적 번호를 고려하여 반복적으로 오프라인 기능을 확장하는 것이 좋습니다. 먼저 간단한 오프라인 오류 페이지로 시작합니다. Workbox를 사용하면 간단하게 만들 수 있으며 맞춤 404 페이지와 마찬가지로 UX 권장사항으로 간주되어야 합니다. 그런 다음 더욱 고급화된 오프라인 대체 옵션으로 이동한 후 마지막으로 실제 오프라인 콘텐츠로 이동합니다. 사용자에게 이를 잘 광고하고 설명하면 사용량이 증가할 것입니다. 누구나 가끔 오프라인 상태가 되니까요.
웹사이트에 더 많은 투자를 하도록 여러 부문의 이해관계자를 설득하는 방법에 관한 도움말은 측정항목을 보고하고 실적 문화를 구축하는 방법 및 기능 간 웹사이트 속도 개선을 참고하세요. 이러한 게시물은 실적에 중점을 두고 있지만 이해관계자 참여를 유도하는 방법에 관한 일반적인 아이디어를 얻는 데 도움이 됩니다.