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

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

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 إلى إشعار "إحصاءات Google"، باستخدام سمة مخصّصة (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"، ولكن يمكن تطبيقه بالطريقة نفسها على إحصاءات أخرى. البائعين.

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

الخطوات التالية

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

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

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

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