سنجش استفاده آفلاین

چگونه استفاده آفلاین از سایتتان را ردیابی کنید تا بتوانید دلیلی برای اینکه چرا سایتتان به تجربه آفلاین بهتری نیاز دارد ارائه دهید.

Stephan Giesau

Martin Schierle

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

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

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

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

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

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

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

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

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

googleAnalytics.initialize();

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

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

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

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

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

برنامه‌های تک‌صفحه‌ای و بار کردن کُند

اگر کاربرانی که از صفحه‌ای بازدید می‌کنند که به‌عنوان وب‌سایت چندصفحه‌ای ساخته شده است آفلاین شوند و سعی کنند پیمایش کنند، صفحه آفلاین پیش‌فرض مرورگر نشان داده می‌شود و به کاربران کمک می‌کند بفهمند چه اتفاقی دارد می‌افتد. اما صفحه‌هایی که به‌عنوان برنامه‌های تک‌صفحه‌ای ساخته شده‌اند عملکرد متفاوتی دارند. کاربر در همان صفحه می‌ماند و محتوای جدید به‌طور پویا ازطریق 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();

  }());
});

به‌جای گوش دادن به همه درخواست‌های ناموفق، راه دیگر این است که خطاها را فقط در مسیرهای خاصی دریافت کنید. As an example, if we want to report errors happening on routes to /products/* only, we can add a check in setCatchHandler which filters the URI with a regular expression.

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

مثال زیر از 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
      });
    }
  });
}

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

مراحل بعدی

با روش‌های مختلف ردیابی استفاده آفلاین و مزایا و معایب آن‌ها آشنا شدید. اگرچه این کار می‌تواند به تعیین تعداد کاربرانی که آفلاین می‌شوند و به‌دلیل آن با مشکل مواجه می‌شوند کمک کند، اما این فقط یک شروع است. As long as your website does not offer a well-built offline mode, you obviously won't see much offline usage in analytics.

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

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