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

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

Stephan Giesau

Martin Schierle

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

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

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

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

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

نهج أفضل: Worker الخدمة

تبيّن أنّ الحلّ الذي يتيح وضع "بلا إنترنت" هو الحلّ الأفضل لتتبُّع استخدام التطبيقات بلا إنترنت. تتمثل الفكرة الأساسية في تخزين إشعارات الإحصاءات في IndexedDB ما دام المستخدم غير متصل بالإنترنت، وإعادة إرسالها فقط عندما يعود المستخدم إلى الاتصال بالإنترنت. بالنسبة إلى "إحصاءات Google"، تتوفّر هذه الميزة حاليًا بشكل جاهز من خلال وحدة Workbox، ولكن يُرجى العِلم أنّه قد لا تتم معالجة النتائج التي تم إرسالها بعد مرور أكثر من أربع ساعات. في أبسط أشكاله، يمكن تفعيله ضمن worker لخدمة مستندة إلى 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',
  },
});

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

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

التطبيقات المُنشِئة لصفحات ويب ديناميكية و"التحميل الكسول"

إذا انقطع الاتصال بالإنترنت لدى المستخدمين الذين يزورون صفحة تم إنشاؤها كموقع إلكتروني مكوّن من عدّة صفحات وحاولوا التنقّل، ستظهر لهم الصفحة التلقائية بلا اتصال بالإنترنت في المتصفّح، ما يساعدهم في فهم ما يحدث. ومع ذلك، تعمل الصفحات التي تم إنشاؤها كتطبيقات صفحة واحدة بشكل مختلف. يبقى المستخدم في الصفحة نفسها، ويتم تحميل المحتوى الجديد بشكل ديناميكي من خلال 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 لفلترة معرّف الموارد المنتظم باستخدام تعبير عادي. إنّ الحلّ الأسهل هو تنفيذ 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 وتُرسِل إشعار إحصاءات Google. مرة أخرى، احرص على تخزين طلبات الإحصاءات التي تتم بلا اتصال بالإنترنت في الخدمة العاملة. كما هو описан سابقًا، عليك إعداد المكوّن الإضافي 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 على Unsplash.