روابط موقعك تفتح داخل تطبيقك: Universal Links وApp Links

باختصار: حين ترسل لزبونك رابط منتج أو رابط تتبع طلب على واتساب، يمكن أن يفتح الرابط داخل تطبيقك مباشرة إن كان مثبتًا، وفي المتصفح إن لم يكن. على iPhone تسمى هذه الميزة Universal Links، وعلى أندرويد Android App Links، وكلاهما يعتمد على ملف صغير في موقعك يثبت أن التطبيق والموقع لصاحب واحد. العمل يمر بمراحل: اختيار الروابط، تجهيز صفحات الويب المقابلة، رفع ملفات الربط، ثم الاختبار.

ما المشكلة التي نحلها؟

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

الهدف بسيط: الرابط نفسه، https:// من نطاقك العادي، يفتح المكان الصحيح. من لديه التطبيق يدخل إلى الشاشة المطابقة فيه، ومن ليس لديه يرى الصفحة على الموقع. هذا يختلف عن مسألة إقناع الزائر بتنزيل التطبيق من صفحة الموقع؛ نحن هنا نتحدث عمن ثبّته فعلًا.

المرحلة الأولى: حدّد الروابط التي تستحق أن تفتح في التطبيق

لا يلزم أن يفتح كل رابط في موقعك داخل التطبيق. صفحة "من نحن" أو المدونة لا تكسب شيئًا من ذلك. ابدأ بقائمة الروابط التي ترسلها فعلًا للزبائن أو التي يشاركونها:

صفحات المنتجات أو الأطباق.
صفحة تتبع الطلب.
صفحات العروض التي تنشرها على إنستغرام وواتساب.
رابط إعادة الطلب أو التقييم بعد التسليم.

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

المرحلة الثانية: اجعل كل رابط يعمل على الويب أولًا

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

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

المرحلة الثالثة: ملف الربط على iPhone

ما الذي يحتاجه Apple؟

بحسب وثائق Apple عن النطاقات المرتبطة (Associated Domains)، يحتاج الربط إلى أمرين: ملف على موقعك، وصلاحية مقابلة داخل التطبيق. الملف اسمه apple-app-site-association بدون امتداد، ويوضع في مجلد .well-known في موقعك، ويحتوي بصيغة JSON قائمة بمعرّفات تطبيقك وأنماط الروابط المسموح بها ضمن خدمة applinks.

تفاصيل تسبب أعطالًا شائعة

HTTPS بلا تحويل: تشترط Apple أن يُقدَّم الملف عبر https:// بشهادة صالحة ومن دون أي إعادة توجيه.
كل نطاق فرعي وحده: إن كان موقعك يعمل على النطاق مع www وبدونه، فلكل منهما إدخال في التطبيق، وكل واحد يجب أن يقدم ملفه.
التحديثات ليست فورية: تذكر Apple أنه منذ iOS 14 لا تطلب التطبيقات الملف من خادمك مباشرة، بل من شبكة توزيع محتوى تديرها Apple، وأن هذه الشبكة تطلب الملف خلال 24 ساعة، وأن الأجهزة تتحقق من التحديثات تقريبًا مرة أسبوعيًا بعد تثبيت التطبيق. لذلك لا تتوقع أن يظهر تعديل الملف على هواتف الزبائن في اليوم نفسه.

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

المرحلة الرابعة: ملف الربط على أندرويد

الروابط العادية والروابط الموثقة

توضح وثائق Android أن الروابط العميقة العادية متاحة على كل الإصدارات لكنها تخضع لنافذة يختار فيها المستخدم التطبيق الذي سيفتح الرابط، أما Android App Links فهي روابط موثقة تثبت علاقة موثوقة بين التطبيق والموقع، وبعد التوثيق تفتح الروابط المحتوى في التطبيق مباشرة دون تلك النافذة. وتذكر الوثائق أنها مدعومة على Android 6 وما بعده على الأجهزة التي تحتوي خدمات Google، وأنها الطريقة الموصى بها للروابط المؤدية إلى موقعك.

الملف المطلوب

يبحث أندرويد عن ملف Digital Asset Links في العنوان /.well-known/assetlinks.json لكل اسم نطاق مذكور في إعدادات التطبيق. الملف يحتوي اسم حزمة التطبيق وبصمة شهادة التوقيع. وتنبّه وثائق Android إلى أن تحديث هذا الملف لا يصل إلى الأجهزة فورًا، وأن مدة التأخير تختلف حسب إصدار النظام، وأن ذاكرة التخزين المؤقت قد تؤخر وصول التعديل حتى بعد إعادة تثبيت التطبيق أثناء الاختبار.

وتنبّه الوثائق نفسها إلى نقطة تُسقط الربط كثيرًا: إن كان التطبيق يستخدم خدمة Play App Signing، فالبصمة التي يستخرجها المطور من جهازه لن تطابق غالبًا البصمة الموجودة على هواتف المستخدمين، والبصمة الصحيحة مع نص الملف الجاهز موجودة في Play Console ضمن إعدادات توقيع التطبيق.

المرحلة الخامسة: الاختبار من حيث يضغط الزبائن فعلًا

لا تكتفِ باختبار الرابط من المتصفح. أرسل الروابط لنفسك في الأماكن التي يستخدمها زبائنك:

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

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

أخطاء تُفسد التجربة

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

الأسئلة الشائعة

هل أحتاج تحديث التطبيق لتفعيل هذه الروابط؟

نعم في الغالب. الملف على الموقع وحده لا يكفي؛ التطبيق يحتاج إعدادًا يعلن النطاقات وشيفرة تستقبل الرابط وتفتح الشاشة المناسبة.

ماذا يحدث إن لم يكن التطبيق مثبتًا؟

يفتح الرابط في المتصفح كأي صفحة ويب، لذلك يجب أن تكون الصفحة المقابلة موجودة وتعمل على الموقع.

لماذا لا تظهر تعديلاتي على ملف الربط فورًا؟

لأن Apple تجلب الملف عبر شبكتها وتتحقق الأجهزة منه دوريًا، ولأن أندرويد يخزن نتيجة التحقق مؤقتًا. خطط لتعديلات الملفات قبل الحملات بوقت كافٍ.

هل يمكن استخدام رابط واحد للنظامين؟

نعم، هذا هو الهدف: رابط https:// واحد من نطاقك يعمل على iPhone وأندرويد والحاسوب، وكل جهاز يفتحه بالطريقة المناسبة له.

إن كانت روابط عروضك وطلباتك تفتح في المتصفح رغم أن زبائنك يملكون تطبيقك، دعنا نراجع الربط بين موقعك وتطبيقك.