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

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

ستيفان غيساو

مارتن شيرل

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

مخاطر أحداث المتصفّح على الإنترنت وبلا إنترنت

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

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

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

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

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

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

الإعلانات الترويجية والتحميل الكسول

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