قياس الاستخدام في وضع عدم الاتصال

كيفية تتبع استخدام موقعك الإلكتروني بلا اتصال بالإنترنت لتتمكّن من إثبات احتياجك إلى تجربة أفضل بلا اتصال بالإنترنت

Stephan Giesau

Martin Schierle

توضّح هذه المقالة كيفية تتبع استخدام موقعك الإلكتروني بلا اتصال بالإنترنت لمساعدتك في توضيح سبب احتياج موقعك إلى وضع عدم اتصال أفضل. كما يشرح بعض الصعوبات والمشكلات التي يجب تجنبها عند تنفيذ تحليلات الاستخدام بلا اتصال بالإنترنت.

المشاكل المرتبطة بأحداث المتصفح على الإنترنت وبلا اتصال بالإنترنت

يتمثّل الحل البديهي لتتبُّع الاستخدام بلا اتصال بالإنترنت في إنشاء أدوات معالجة الأحداث لحدثَي online وoffline (التي تتوافق معها العديد من المتصفحات) ووضع منطق تتبُّع الإحصاءات في هؤلاء المستمعين. لسوء الحظ، هناك العديد من المشكلات والقيود بهذا النهج:

• بشكل عام، قد يكون تتبُّع كل حدث من أحداث حالة الاتصال بالشبكة زائدًا عن الحد، ويؤثر سلبًا في بيئة تركِّز على الخصوصية حيث يتم جمع أقل قدر ممكن من البيانات. إضافةً إلى ذلك، يمكن أن يتم تنشيط حدثَي online وoffline لمدة جزء من الثانية فقط من فقدان الشبكة، وهو ما قد لا يراه المستخدم أو يلاحظه.
• لن يصل تتبع إحصاءات النشاط بلا اتصال بالإنترنت أبدًا إلى خادم التحليلات لأن المستخدم... حسنًا، غير متصل بالإنترنت.
• إنّ تتبُّع طابع زمني محليًا عندما يكون المستخدم بلا اتصال بالإنترنت وإرسال النشاط بلا اتصال بالإنترنت إلى خادم الإحصاءات عند معاودة الاتصال بالإنترنت يعتمد على المستخدم الذي يعيد زيارة موقعك الإلكتروني. إذا غادر المستخدم موقعك الإلكتروني بسبب عدم توفّر وضع عدم الاتصال بالإنترنت ولم يعُد إلى زيارته، لا يمكنك تتبُّع ذلك. تعد القدرة على تتبع حالات الانسحاب بلا اتصال بالإنترنت بيانات مهمة لإنشاء حالة حول احتياج موقعك إلى وضع عدم اتصال أفضل.
• إنّ فعالية online ليست موثوقة للغاية لأنّها تعني معلومات عن الوصول إلى الشبكة فقط، وليست الاتصال بالإنترنت. وبالتالي، قد يكون المستخدم غير متصل بالإنترنت، وقد يتعذّر إرسال إشعار التتبع.
• حتى إذا بقي المستخدم على الصفحة الحالية بلا اتصال بالإنترنت، لا يتم تتبُّع أيٍّ من أحداث الإحصاءات الأخرى (مثل أحداث التمرير والنقرات وما إلى ذلك)، وقد تكون هذه المعلومات أكثر صلةً وفائدةً.
• فالمشاهدة في حد ذاتها بلا اتصال بالإنترنت ليست مفيدة جدًا بشكل عام. كمطور مواقع ويب، قد يكون من المهم معرفة أنواع الموارد التي فشل تحميلها. وينطبق ذلك بشكل خاص في سياق SPA، حيث قد لا يؤدي انقطاع الاتصال بالشبكة إلى ظهور صفحة خطأ في المتصفح بلا اتصال بالإنترنت (يمكن للمستخدمين فهمها)، ولكن من المرجح أن تعرض الأجزاء الديناميكية العشوائية من الصفحة إخفاقًا تلقائيًا.

لا يزال بإمكانك استخدام هذا الحل لاكتساب فهم أساسي للاستخدام بلا اتصال بالإنترنت، ولكن يجب مراعاة العيوب والقيود العديدة بعناية.

أسلوب أفضل: عامل الخدمة

اتضح أنّ الحل الذي يتيح وضع عدم الاتصال بالإنترنت هو الحل الأفضل لتتبّع الاستخدام بلا اتصال بالإنترنت. تكمن الفكرة الأساسية في تخزين إشعارات الإحصاءات في IndexedDB طالما أن المستخدم غير متصل بالإنترنت، وإعادة إرسالها عند اتصال المستخدم بالإنترنت مرة أخرى. بالنسبة إلى "إحصاءات Google"، يمكن إجراء ذلك الجاهز من خلال وحدة Workbox، ولكن تذكَّر أنّه قد لا تتم معالجة النتائج المُرسَلة أكثر من أربع ساعات مؤجلة. وفي أبسط صوره، يمكن تفعيله ضمن مشغّل الخدمات المستند إلى Workbox باستخدام السطرَين التاليَين:

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

googleAnalytics.initialize();

يؤدي هذا إلى تتبع جميع الأحداث وإشعارات مشاهدة الصفحة على الويب الحالية أثناء عدم الاتصال بالإنترنت، لكنك لن تعرف أنها تمت بلا اتصال بالإنترنت (حيث تتم إعادة تشغيلها كما هي). لهذا، يمكنك معالجة طلبات التتبّع باستخدام Workbox من خلال إضافة علامة offline إلى إشعار الإحصاءات، باستخدام سمة مخصّصة (cd1 في عيّنة الرمز أدناه):

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

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

ماذا لو خرج المستخدم من الصفحة بسبب عدم الاتصال بالإنترنت، قبل أن يعاود الاتصال بالإنترنت؟ وعلى الرغم من أنّ هذا يؤدي عادةً إلى وضع عامل الخدمة في وضع السكون (لأنّه غير قادر على إرسال البيانات عند استعادة الاتصال)، تستخدم وحدة Workbox Google Analytics واجهة برمجة التطبيقات لمزامنة الخلفية التي ترسل بيانات الإحصاءات لاحقًا عند عودة الاتصال، حتى إذا أغلق المستخدم علامة التبويب أو المتصفّح.

لا يزال هناك عيب: على الرغم من أن ذلك يجعل التتبع الحالي ممكنًا في وضع عدم الاتصال، فمن المحتمل ألا ترى الكثير من البيانات ذات الصلة الواردة قبل تنفيذ وضع عدم الاتصال الأساسي. سيظل المستخدمون ينسحبون من موقعك بسرعة عند انقطاع الاتصال. ولكن يمكنك الآن على الأقل قياس هذا الأمر وتحديده كميًا، من خلال مقارنة متوسط مدة الجلسة وتفاعل المستخدمين للمستخدمين مع تطبيق البُعد بلا اتصال بالإنترنت مقابل المستخدمين العاديين.

منتجعات صحية (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/* فقط، يمكننا إضافة عملية تحقُّق في setCatchHandler تؤدي إلى فلترة معرّف الموارد المنتظم (URI) باستخدام تعبير عادي. ويتمثل الحل الأكثر تنظيمًا في تنفيذ recordRoute باستخدام معالج مخصص. وهذا يلخص منطق الأعمال في مسار منفصل، مع إمكانية صيانتها بشكل أفضل في عمال الخدمة الأكثر تعقيدًا:

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" المضمّن.

يستخدم المثال التالي "إحصاءات Google"، ولكن يمكن تطبيقه بالطريقة نفسها على موردي "إحصاءات 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 المخصصة على أي حال. بعد ذلك، شقّ طريقك نحو إجراءات احتياطية أكثر تقدّمًا بلا إنترنت، ثم أخيرًا نحو المحتوى الفعلي بلا إنترنت. احرص على نشر إعلانات عن هذا الموضوع وشرحه للمستخدمين، وستلاحظ تزايدًا في الاستخدام. بعد كل شيء، يتوقف الجميع عن الاتصال بالإنترنت بين الحين والآخر.

اطّلِع على مقالة كيفية إعداد تقارير عن المقاييس وإنشاء ثقافة للأداء وإصلاح سرعة الموقع الإلكتروني بشكلٍ تبادلي للحصول على نصائح حول إقناع الجهات المعنيّة المتعدّدة الوظائف باستثمار المزيد في موقعك الإلكتروني. على الرغم من أن هذه المشاركات تركز على الأداء، إلا أنها يجب أن تساعدك في الحصول على أفكار عامة حول كيفية إشراك الأطراف المعنية.

صورة رئيسية من تصميم JC Gellidon على قناة Unسباش