اندازه‌گیری میزان استفاده آفلاین

چگونه میزان استفاده آفلاین از سایت خود را پیگیری کنید تا بتوانید استدلال کنید که چرا سایت شما به یک تجربه آفلاین بهتر نیاز دارد.

Stephan Giesau

Martin Schierle

یاد بگیرید که چگونه میزان استفاده آفلاین از سایت خود را پیگیری کنید، تا بتوانید دلیل نیاز سایت خود به حالت آفلاین بهتر را بیان کنید. بفهمید که هنگام اجرای تجزیه و تحلیل میزان استفاده آفلاین، از چه مشکلات و دام‌هایی باید اجتناب کنید.

مشکلات رویدادهای مرورگر آنلاین و آفلاین

راه حل واضح برای ردیابی استفاده آفلاین، ایجاد شنونده‌های رویداد برای رویدادهای online و offline (که بسیاری از مرورگرها از آن پشتیبانی می‌کنند ) و قرار دادن منطق ردیابی تحلیلی خود در آن شنونده‌ها است. متأسفانه، این رویکرد چندین مشکل و محدودیت دارد:

• به طور کلی، ردیابی هر رویداد وضعیت اتصال به شبکه ممکن است بیش از حد باشد و در دنیایی که محوریت آن حریم خصوصی است و باید تا حد امکان داده‌های کمی جمع‌آوری شود، نتیجه‌ی معکوس می‌دهد. علاوه بر این، رویدادهای online و offline می‌توانند تنها در کسری از ثانیه از قطع شبکه فعال شوند، که احتمالاً کاربر حتی آن را نمی‌بیند یا متوجه آن نمی‌شود.
• ردیابی تحلیلی فعالیت آفلاین به سرور تحلیلی نمی‌رسد.
• ردیابی یک برچسب زمانی به صورت محلی هنگامی که کاربر آفلاین می‌شود و ارسال فعالیت آفلاین به سرور تحلیلی هنگامی که کاربر دوباره آنلاین می‌شود، بستگی به بازدید مجدد کاربر از سایت شما دارد. اگر کاربر به دلیل عدم وجود حالت آفلاین، سایت شما را ترک کند و دیگر هرگز بازدید نکند، شما هیچ راهی برای ردیابی آن ندارید. توانایی ردیابی بازدیدهای آفلاین، داده‌های حیاتی برای ایجاد دلیلی در مورد اینکه چرا سایت شما به حالت آفلاین بهتری نیاز دارد، می‌باشد.
• رویداد online خیلی قابل اعتماد نیست زیرا فقط از دسترسی به شبکه اطلاع دارد ، نه از دسترسی به اینترنت. بنابراین ممکن است کاربر هنوز آفلاین باشد و ارسال پینگ ردیابی همچنان با شکست مواجه شود.
• حتی اگر کاربر در حالت آفلاین همچنان در صفحه فعلی بماند، هیچ یک از رویدادهای تحلیلی دیگر (مثلاً رویدادهای اسکرول، کلیک‌ها و غیره) نیز ردیابی نمی‌شوند، که ممکن است اطلاعات مرتبط‌تر و مفیدتری باشند.
• آفلاین بودن به خودی خود خیلی معنی‌دار نیست. احتمالاً مهم‌ترین چیز این است که بدانید کدام منابع بارگذاری نمی‌شوند. این موضوع به ویژه برای برنامه‌های تک صفحه‌ای (SPA) اهمیت دارد، جایی که قطع اتصال شبکه ممکن است منجر به صفحه خطای آفلاین مرورگر نشود، که کاربران آن را درک می‌کنند. در عوض، احتمالاً منجر به از کار افتادن بخش‌های تصادفی و پویای صفحه به صورت خاموش می‌شود.

شما هنوز هم می‌توانید از این راه‌حل برای درک اولیه‌ی استفاده‌ی آفلاین استفاده کنید، اما باید معایب و محدودیت‌های فراوان آن را با دقت در نظر بگیرید.

یک رویکرد بهتر: کارگر خدماتی

راهکاری که حالت آفلاین را فعال می‌کند، راهکار بهتری برای ردیابی استفاده آفلاین نیز هست. می‌توانید پینگ‌های تحلیلی را تا زمانی که کاربر آفلاین است در IndexedDB ذخیره کنید و وقتی کاربر دوباره آنلاین شد، دوباره آنها را ارسال کنید. برای Google Analytics، این قابلیت از قبل در یک ماژول Workbox موجود است، اما به خاطر داشته باشید که ممکن است بازدیدهایی که بیش از چهار ساعت به تعویق افتاده‌اند، پردازش نشوند.

در ساده‌ترین شکل، می‌توان آن را در یک سرویس ورکر مبتنی بر Workbox با این دو خط فعال کرد:

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

googleAnalytics.initialize();

این ابزار تمام رویدادهای موجود و پینگ‌های بازدید از صفحه را در حالت آفلاین ردیابی می‌کند، اما شما متوجه نمی‌شوید که آنها در حالت آفلاین اتفاق افتاده‌اند، زیرا آنها فقط به همان صورت که هستند، دوباره پخش می‌شوند. می‌توانید با استفاده از یک بُعد سفارشی، درخواست‌های ردیابی را با Workbox با اضافه کردن یک پرچم offline به پینگ تحلیلی، دستکاری کنید:

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

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

اگر کاربر به دلیل آفلاین بودن، قبل از اتصال مجدد به اینترنت، از صفحه خارج شود، چه می‌شود؟ در حالی که این حالت معمولاً سرویس ورکر را به حالت خواب می‌برد، زیرا پس از اتصال مجدد نمی‌تواند داده‌ها را ارسال کند، ماژول Workbox Google Analytics از API همگام‌سازی پس‌زمینه استفاده می‌کند. همگام‌سازی پس‌زمینه، داده‌های تحلیلی را پس از اتصال مجدد ارسال می‌کند، حتی اگر کاربر تب یا مرورگر را ببندد.

هنوز یک اشکال وجود دارد: اگرچه این امر ردیابی موجود را به صورت آفلاین امکان‌پذیر می‌کند، اما به احتمال زیاد تا زمانی که حالت آفلاین اولیه را پیاده‌سازی نکنید، داده‌های مرتبط زیادی را مشاهده نخواهید کرد. کاربران همچنان به محض قطع اتصال، سایت شما را به سرعت ترک می‌کنند. اما اکنون حداقل می‌توانید با مقایسه میانگین طول جلسه و میزان مشارکت کاربران با بُعد آفلاین اعمال شده در مقابل کاربران عادی، این موضوع را اندازه‌گیری و کمّی کنید.

SPA ها و بارگذاری تنبل

اگر کاربرانی که از صفحه‌ای که به عنوان یک وب‌سایت چند صفحه‌ای ساخته شده است بازدید می‌کنند، آفلاین شوند و سعی کنند در آن پیمایش کنند، صفحه پیش‌فرض آفلاین مرورگر نمایش داده می‌شود و به کاربران کمک می‌کند تا بفهمند چه اتفاقی می‌افتد. با این حال، صفحاتی که به عنوان برنامه‌های تک صفحه‌ای ساخته شده‌اند، متفاوت عمل می‌کنند. کاربر در همان صفحه می‌ماند و محتوای جدید به صورت پویا از طریق AJAX و بدون هیچ پیمایش مرورگری بارگذاری می‌شود. کاربران هنگام آفلاین شدن، صفحه خطای مرورگر را نمی‌بینند. در عوض، بخش‌های پویای صفحه با خطا رندر می‌شوند، به حالت‌های نامشخص می‌روند یا به سادگی از پویایی خارج می‌شوند.

اثرات مشابهی می‌تواند در وب‌سایت‌های چند صفحه‌ای به دلیل بارگذاری تنبل رخ دهد. برای مثال، شاید بارگذاری اولیه به صورت آنلاین اتفاق افتاده باشد، اما کاربر قبل از پیمایش، آفلاین شده باشد. تمام محتوای بارگذاری شده تنبل در زیر صفحه، بی‌صدا از کار می‌افتند و از دست می‌روند.

از آنجایی که این موارد واقعاً برای کاربران آزاردهنده هستند، ردیابی آنها منطقی است. سرویس ورکرها مکان مناسبی برای گرفتن خطاهای شبکه و در نهایت ردیابی آنها با استفاده از تجزیه و تحلیل هستند. با Workbox، یک کنترل‌کننده سراسری 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/* رخ می‌دهند گزارش دهیم، می‌توانیم یک بررسی در setCatchHandler اضافه کنیم که URI را با یک عبارت منظم فیلتر می‌کند.

یک راه حل ساده‌تر، پیاده‌سازی 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 گوش دهد و پینگ تحلیلی را ارسال کند. مجدداً، مطمئن شوید که درخواست‌های تحلیلی که به صورت آفلاین در سرویس ورکر اتفاق می‌افتند را بافر کرده‌اید. همانطور که قبلاً توضیح داده شد، افزونه workbox-google-analytics را برای پشتیبانی داخلی گوگل آنالیتیکس راه‌اندازی کنید.

مثال زیر از گوگل آنالیتیکس استفاده می‌کند، اما می‌تواند به همین روش برای سایر ارائه‌دهندگان خدمات تحلیلی نیز اعمال شود.

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

این کار، بارهای منبع ناموفق را در گوگل آنالیتیکس ردیابی می‌کند، جایی که می‌توان آنها را با گزارش‌گیری تجزیه و تحلیل کرد. از بینش به‌دست‌آمده می‌توان برای بهبود ذخیره‌سازی سرویس ورکرها و مدیریت خطا به طور کلی استفاده کرد تا صفحه در شرایط ناپایدار شبکه، قوی‌تر و قابل اعتمادتر شود.

مراحل بعدی

شما روش‌های مختلف ردیابی استفاده آفلاین را به همراه مزایا و معایب آنها آموختید. اگرچه این می‌تواند به تعیین کمیت تعداد کاربرانی که آفلاین می‌شوند و به دلیل آن با مشکل مواجه می‌شوند کمک کند، اما هنوز فقط یک شروع است. تا زمانی که وب‌سایت شما حالت آفلاین خوبی ارائه ندهد، بدیهی است که استفاده آفلاین زیادی را در تجزیه و تحلیل مشاهده نخواهید کرد.

توصیه می‌کنیم ردیابی کامل را انجام دهید و سپس قابلیت‌های آفلاین خود را در تکرارها، با تمرکز بر ردیابی، گسترش دهید. با یک صفحه خطای آفلاین شروع کنید. ایجاد این صفحه با Workbox ساده است و یک روش برتر UX مشابه صفحات ۴۰۴ سفارشی است. سپس، به سمت جایگزین‌های آفلاین پیشرفته‌تر و در نهایت به سمت محتوای آفلاین واقعی حرکت کنید. مطمئن شوید که این موضوع را به خوبی برای کاربران خود تبلیغ و توضیح می‌دهید و شاهد افزایش استفاده خواهید بود. به هر حال، همه هر از گاهی آفلاین می‌شوند.

برای نکاتی در مورد ترغیب ذینفعان چندوظیفه‌ای به سرمایه‌گذاری بیشتر در وب‌سایت خود، به «نحوه گزارش معیارها و ایجاد فرهنگ عملکرد» و «اصلاح سرعت وب‌سایت به صورت چندوظیفه‌ای» مراجعه کنید. اگرچه این پست‌ها بر عملکرد متمرکز هستند، اما باید به شما کمک کنند تا ایده‌های کلی در مورد نحوه تعامل با ذینفعان کسب کنید.