오프라인 사용량 측정

사이트의 오프라인 사용을 추적하여 사이트에 더 나은 오프라인 환경이 필요한 이유를 설명하는 방법을 알아봅니다.

Stephan Giesau

Martin Schierle

사이트의 오프라인 사용을 추적하여 사이트에 더 나은 오프라인 모드가 필요한 이유를 설명하는 방법을 알아봅니다. 오프라인 사용 분석을 구현할 때 피해야 할 함정과 문제를 이해합니다.

온라인 및 오프라인 브라우저 이벤트의 함정

오프라인 사용을 추적하는 명백한 해결책은 online 및 offline 이벤트 (많은 브라우저에서 지원) 에 이벤트 리스너를 만들고 분석 추적 로직을 이러한 리스너에 배치하는 것입니다. 하지만 이 접근 방식에는 몇 가지 문제와 제한사항이 있습니다.

일반적으로 모든 네트워크 연결 상태 이벤트를 추적하는 것은 과도할 수 있으며, 가능한 한 적은 데이터를 수집해야 하는 개인 정보 보호 중심의 세계에서는 비생산적입니다. 또한 online 및 offline 이벤트는 사용자가 보거나 알아차리지 못할 수 있는 네트워크 손실의 아주 짧은 순간에 발생할 수 있습니다.
오프라인 활동의 분석 추적이 분석 서버에 도달하지 않습니다.
사용자가 오프라인 상태가 될 때 타임스탬프를 로컬로 추적하고 사용자가 다시 온라인 상태가 될 때 오프라인 활동을 분석 서버로 전송하는 것은 사용자가 사이트를 다시 방문하는지에 따라 달라집니다. 오프라인 모드가 없어 사용자가 사이트를 이탈하고 다시 방문하지 않는 경우 이를 추적할 방법이 없습니다. 오프라인 이탈을 추적하는 기능은 사이트에 더 나은 오프라인 모드가 필요한 이유를 설명하는 데 중요한 데이터입니다.
online 이벤트는 인터넷 액세스가 아닌 네트워크 액세스만 알기 때문에 매우 안정적이지 않습니다. 따라서 사용자가 여전히 오프라인 상태일 수 있으며 추적 핑 전송이 여전히 실패할 수 있습니다.
사용자가 오프라인 상태인 동안 현재 페이지에 계속 머물러도 다른 분석 이벤트 (예: 스크롤 이벤트, 클릭 등)도 추적되지 않으며, 이는 더 관련성 있고 유용한 정보일 수 있습니다.
오프라인 상태인 것만으로는 큰 의미가 없습니다. 로드하지 못한 리소스를 파악하는 것이 가장 중요할 수 있습니다. 이는 특히 사용자가 이해하는 브라우저 오프라인 오류 페이지로 연결되지 않을 수 있는 네트워크 연결이 끊어진 단일 페이지 애플리케이션 (SPA)과 관련이 있습니다. 대신 페이지의 임의의 동적 부분이 자동으로 실패할 수 있습니다.

이 솔루션을 사용하여 오프라인 사용에 대한 기본적인 이해를 얻을 수 있지만 많은 단점과 제한사항을 신중하게 고려해야 합니다.

더 나은 접근 방식: 서비스 워커

오프라인 모드를 지원하는 솔루션은 오프라인 사용을 추적하는 더 나은 솔루션이기도 합니다. 사용자가 오프라인 상태인 동안 분석 핑을 IndexedDB에 저장하고 사용자가 다시 온라인 상태가 되면 다시 전송할 수 있습니다. Google 애널리틱스의 경우 이는 이미 Workbox 모듈에서 사용할 수 있지만 4시간 이상 지연되어 전송된 조회수 는 처리되지 않을 수 있습니다.

가장 간단한 형태에서는 다음 두 줄로 Workbox 기반 서비스 워커 내에서 활성화할 수 있습니다.

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

googleAnalytics.initialize();

이렇게 하면 오프라인 상태인 동안 모든 기존 이벤트와 페이지 조회수 핑이 추적되지만, 그대로 재생되기 때문에 오프라인에서 발생했는지 알 수 없습니다. 맞춤 측정기준을 사용하여 분석 핑에 offline 플래그를 추가하여 Workbox로 추적 요청을 조작할 수 있습니다.

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

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

인터넷 연결이 다시 되기 전에 사용자가 오프라인 상태가 되어 페이지를 이탈하면 어떻게 될까요? 일반적으로 연결이 다시 될 때 데이터를 전송할 수 없으므로 서비스 워커가 절전 모드로 전환되지만 Workbox Google 애널리틱스 모듈은 Background Sync API를 사용합니다. Background Sync는 사용자가 탭이나 브라우저를 닫더라도 연결이 다시 될 때 분석 데이터를 전송합니다.

여전히 단점이 있습니다. 이렇게 하면 기존 추적을 오프라인에서 사용할 수 있지만 기본적인 오프라인 모드를 구현할 때까지는 관련 데이터가 많이 수신되지 않을 가능성이 높습니다. 연결이 끊어지면 사용자가 여전히 사이트를 빠르게 이탈합니다. 하지만 이제 오프라인 측정기준이 적용된 사용자와 일반 사용자의 평균 세션 길이와 사용자 참여를 비교하여 이를 측정하고 정량화할 수 있습니다.

SPA 및 지연 로드

여러 페이지 웹사이트로 빌드된 페이지를 방문하는 사용자가 오프라인 상태가 되어 이동하려고 하면 브라우저의 기본 오프라인 페이지가 표시되어 사용자가 상황을 이해할 수 있습니다. 하지만 단일 페이지 애플리케이션으로 빌드된 페이지는 다르게 작동합니다. 사용자는 동일한 페이지에 머물고 브라우저 탐색 없이 AJAX를 통해 새 콘텐츠가 동적으로 로드됩니다. 사용자가 오프라인 상태가 되면 브라우저 오류 페이지가 표시되지 않습니다. 대신 페이지의 동적 부분이 오류와 함께 렌더링되거나 정의되지 않은 상태로 전환되거나 동적 상태가 중지됩니다.

지연 로드로 인해 여러 페이지 웹사이트 내에서 유사한 효과가 발생할 수 있습니다. 예를 들어 초기 로드는 온라인에서 발생했지만 사용자가 스크롤하기 전에 오프라인 상태가 되었을 수 있습니다. 접힌 부분 아래의 모든 지연 로드된 콘텐츠가 자동으로 실패하고 누락됩니다.

이러한 사례는 사용자에게 매우 짜증나므로 추적하는 것이 좋습니다. 서비스 워커는 네트워크 오류를 포착하고 결국 분석을 사용하여 추적하는 데 적합합니다. Workbox를 사용하면 메시지 이벤트를 전송하여 실패한 요청에 관해 페이지에 알리도록 a 전역 catch 핸들러 를 구성할 수 있습니다.

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 권장사항입니다. 그런 다음 더 고급 오프라인 대체 로, 마지막으로 실제 오프라인 콘텐츠로 작업합니다. 사용자에게 이를 잘 알리고 설명하면 사용량이 증가합니다. 결국 모든 사람이 가끔 오프라인 상태가 됩니다.

교차 기능 이해관계자가 웹사이트에 더 많이 투자하도록 설득하는 방법에 관한 팁은 측정항목 보고 및 실적 문화 구축 및 교차 기능 웹사이트 속도 수정을 참고하세요. 이러한 게시물은 실적에 중점을 두고 있지만 이해관계자를 참여시키는 방법에 관한 일반적인 아이디어를 얻는 데 도움이 될 것입니다.

오프라인 사용량 측정 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

온라인 및 오프라인 브라우저 이벤트의 함정

더 나은 접근 방식: 서비스 워커

SPA 및 지연 로드

다음 단계

오프라인 사용량 측정