اندازه گیری مصرف آفلاین

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

Stephan Giesau

Martin Schierle

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

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

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

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

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

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

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

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

googleAnalytics.initialize();

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

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

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

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

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

آبگرم و بارگذاری تنبل

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

مراحل بعدی

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

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

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

عکس قهرمان توسط JC Gellidon در Unsplash .