كيفية تحديد استراتيجية التثبيت

Demián Renzulli

Pete LePage

تاريخ النشر: 12 أيار (مايو) 2020

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

يمكنك تحقيق ذلك بطرق مختلفة:

• تثبيت تطبيق الويب التقدّمي من المتصفّح
• تثبيت تطبيق الويب التقدّمي من متجر التطبيقات

يُعدّ توفّر قنوات توزيع مختلفة طريقة رائعة للوصول إلى قاعدة مستخدمين واسعة. ومع ذلك، قد يكون من الصعب اختيار الاستراتيجية المناسبة للترويج لتثبيت تطبيق الويب التقدّمي.

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

لماذا يجب أن يكون تطبيق الويب قابلاً للتثبيت؟

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

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

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

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

إذا كان حجم هذا الجزء كبيرًا، يشير ذلك إلى أنّك بحاجة إلى توفير طرق بديلة لتثبيت تجاربك.

تشجيع المستخدمين على تثبيت تطبيق الويب التقدّمي في المتصفّح

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

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

تطبيق الويب التقدّمي (PWA) كتجربة أساسية قابلة للتثبيت

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

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

منع تطبيق الويب التقدّمي من مزاحمة معدّل تثبيت التطبيق الخاص بمنصة معيّنة

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

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

على سبيل المثال، يمكن أن يكون مستخدم تطبيق الويب التقدّمي هو مستخدم رأى طلب التثبيت لتطبيقك الخاص بمنصة معيّنة، ولكنّه لم يثبّته. وقد يعودون إلى موقعك الإلكتروني خمس مرات أو أكثر، وينقرون على بانر التطبيق، ولكنهم يواصلون استخدام الموقع الإلكتروني بدلاً من ذلك.

يمكن تنفيذ طريقة الاستدلال بالطريقة التالية:

1. عرض بانر تثبيت التطبيق الخاص بالنظام الأساسي
2. إذا أغلق المستخدم البانر، اضبط ملف تعريف ارتباط يتضمّن هذه المعلومات (مثل document.cookie = "app-install-banner=dismissed").
3. استخدِم ملف تعريف ارتباط آخر لتتبُّع عدد زيارات المستخدمين للموقع الإلكتروني (مثل document.cookie = "user-visits=1").
4. اكتب دالة، مثل isPWAUser()، تستخدم المعلومات المخزّنة سابقًا في ملفات تعريف الارتباط مع واجهة برمجة التطبيقات getInstalledRelatedApps() لتحديد ما إذا كان المستخدم يُعدّ مستخدمًا لتطبيق ويب تقدّمي.
5. عندما ينفِّذ المستخدم إجراءً ذا مغزى، استدعِ الدالة isPWAUser(). إذا عرضت الدالة القيمة "صحيح" وتم حفظ طلب تثبيت تطبيق الويب التقدّمي (PWA) سابقًا، يمكنك عرض زر تثبيت تطبيق الويب التقدّمي.

الترويج لتثبيت تطبيق PWA في متجر تطبيقات

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

يمكن تصنيف التطبيقات في المتجر إلى مجموعتَين:

• التطبيقات الخاصة بنظام أساسي معيّن: يتم إنشاء معظم هذه التطبيقات باستخدام رمز برمجي خاص بنظام أساسي معيّن. يختلف حجم التطبيق حسب النظام الأساسي، ولكنّه عادةً ما يكون أكبر من 10 ميغابايت على Android و30 ميغابايت على iOS. قد تحتاج إلى الترويج لتطبيقك الخاص بمنصة معيّنة إذا لم يكن لديك تطبيق ويب تقدّمي، أو إذا كان التطبيق الخاص بمنصة معيّنة يقدّم مجموعة أكثر اكتمالاً من الميزات.
• التطبيقات الخفيفة: يمكن إنشاء هذه التطبيقات باستخدام رموز خاصة بالمنصة أيضًا، ولكن يتم إنشاؤها عادةً باستخدام تكنولوجيا الويب، ويتم تجميعها في غلاف خاص بالمنصة. يمكن أيضًا تحميل تطبيقات الويب التقدّمية الكاملة إلى المتجر. تختار بعض الشركات تقديم هذه التجارب على أنّها "مبسطة"، بينما تستخدم شركات أخرى هذا النهج أيضًا في تطبيقاتها الرئيسية (الأساسية).

الترويج للتطبيقات الخفيفة

وفقًا لدراسة أجراها Google Play، مقابل كل زيادة بمقدار 6 ميغابايت في حجم حزمة APK، ينخفض معدّل الإحالات الناجحة للتثبيت بنسبة %1. وهذا يعني أنّ معدّل إكمال تنزيل تطبيق بحجم 10 ميغابايت يمكن أن يكون أعلى بنسبة% 30 تقريبًا من معدّل إكمال تنزيل تطبيق بحجم 100 ميغابايت.

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

أنشأت شركة Oyo، إحدى أكبر شركات الضيافة في الهند، نسخة Lite من تطبيقها وأتاحتها في "متجر Play" باستخدام تطبيق ويب متوافق مع الأجهزة الجوّالة. في أيار (مايو) 2020، كان حجم تطبيق Oyo يبلغ 850 كيلوبايت فقط، أي% 7 من حجم تطبيق Android. وبعد تثبيته، لا يمكن التمييز بينه وبين تطبيق Android:

أبقت شركة Oyo على كل من الإصدار الرئيسي وإصدار "Lite" من التطبيق في المتجر، ما أتاح للمستخدمين اختيار الإصدار الذي يناسبهم.

توفير تجربة خفيفة على الويب

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

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

استخدام JavaScript

باستخدام سمات JavaScript، مثل navigator.hardwareConcurrency وnavigator.deviceMemory وnavigator.connection، يمكنك الحصول على معلومات حول وحدة المعالجة المركزية (CPU) والذاكرة وحالة الشبكة على التوالي. على سبيل المثال:

const deviceCategory = req.get('Device-Memory') < 1 ? 'lite' : 'full';`

استخدام "تعديلات برنامج وكيل المستخدم"

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

1. أخبِر المتصفّح بأنّك مهتم بتلقّي تلميحات حول ذاكرة الجهاز في رأس استجابة HTTP لأي طلب تابع لجهة أولى:

   HTTP/1.1 200 OK
   Content-Type: text/html
   Accept-CH: Device-Memory
   

2. ستبدأ في تلقّي معلومات Device-Memory في عنوان الطلب الخاص بطلبات HTTP:

   GET /main.js HTTP/1.1
   Device-Memory: 0.5
   

3. استخدِم هذه المعلومات في الأنظمة الخلفية لتخزين ملف تعريف ارتباط يتضمّن فئة جهاز المستخدم:

   app.get('/route', (req, res) => {
     // Determine device category
   
   const deviceCategory = req.get('Device-Memory') < 1 ? 'lite' : 'full';
   
     // Set cookie
     res.setCookie('Device-Category', deviceCategory);
     …
   });
   

4. أنشئ منطقك الخاص لربط هذه المعلومات بفئات الأجهزة، واعرض طلب تثبيت التطبيق المناسب في كل حالة:

   if (isDeviceMidOrLowEnd()) {
     // show "Lite app" install banner or PWA A2HS prompt
   } else {
     // show "Core app" install banner
   }
   

السماح للمستخدمين بتثبيت تطبيقك بغض النظر عن النظام الأساسي

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

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