قياس الاستخدام بلا إنترنت

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

Stephan Giesau

Martin Schierle

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

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

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

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

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

منهج أفضل: مشغّل الخدمات

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

في أبسط أشكاله، يمكن تفعيله ضمن مشغّل خدمات يستند إلى Workbox باستخدام هذين السطرَين:

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

googleAnalytics.initialize();

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

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

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

ماذا يحدث إذا غادر المستخدم الصفحة بسبب عدم الاتصال بالإنترنت، قبل عودة الاتصال بالإنترنت؟ في حين أنّ ذلك عادةً ما يؤدي إلى وضع مشغّل الخدمات في وضع السكون، لأنّه لا يمكنه إرسال البيانات عند عودة الاتصال، تستخدِم وحدة Workbox "إحصاءات Google" واجهة برمجة التطبيقات Background Sync API. ترسِل Background Sync بيانات الإحصاءات عند عودة الاتصال، حتى إذا أغلق المستخدم علامة التبويب أو المتصفح.

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

التطبيقات ذات الصفحة الواحدة والتحميل الكسول

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

هناك حلّ أكثر وضوحًا وهو تنفيذ 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".

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

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