جهّز تطبيقك لمراجعة سوق التطبيقات: قائمة تحقق قبل الإرسال

ماذا يفحص فريق المراجعة؟

قبل أن يظهر تطبيقك في سوق التطبيقات، يراجعه فريق زد ويختبره. المراجعة لا تقتصر على الكود؛ فهي تشمل صفحة التطبيق كما سيراها التاجر، وتجربة التفعيل وOAuth 2.0، والصلاحيات (Scopes) التي طلبتها، والباقات، وقناة الدعم.

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

صفحة التطبيق: التفاصيل التي تُراجَع

صفحة تطبيقك هي أول ما يراه التاجر، ولذلك تخضع لقواعد محددة:

• اسم التطبيق: بين 3 و24 حرفًا، ولا يحتوي على كلمة «Zid»، ويُكتب بالعربية والإنجليزية بترجمة صحيحة.
• التصنيف: اختر التصنيف الذي يصف الوظيفة الأساسية لتطبيقك، ويمكنك إضافة تصنيف آخر إذا كانت له وظيفة أساسية ثانية.
• الوصف: لديك حتى 4000 حرف. ركّز على الفائدة والوظائف بدل اللغة التسويقية، ولا تضع أرقامًا أو إحصاءات، واذكر خطوات التفعيل بالتفصيل وأي قيود مهمة (مثل دول محددة أو ثيمات محددة). ويُكتب باللغتين.
• الوصف المختصر: استخدم فيه كلمات مفتاحية لمزايا تطبيقك حتى يظهر في بحث التاجر، وباللغتين أيضًا.
• المطوِّر: يجب أن يحمل اسم الشركة التي طوّرت التطبيق.
• الفيديو: رابط YouTube بصيغة التضمين فقط، مثل https://www.youtube.com/embed/######.
• الصور: من صورة واحدة إلى 10 صور، واضحة وغير مزدحمة، بلا نوافذ متصفح أو أسهم توضيحية، وبدون شعار زد.
• الأيقونة: بنسبة 1:1، وبحد أقصى 250×250 بكسل.

التفعيل وOAuth: أين تتعثر معظم التطبيقات

تنص سياسة «Zid App Activation & OAuth Policy» على أن التطبيق القياسي يبدأ تدفق OAuth فورًا بعد أن يضغط التاجر «تفعيل». أي دفع مطلوب للباقة يتم عبر زد قبل التفعيل، ولا يجوز طلب دفع إضافي من جهة الشريك.

تذكر السياسة صراحةً تدفقات تُرفض، ومنها:

• وضع التسجيل أو تسجيل الدخول في منصتك قبل OAuth في التطبيقات القياسية.
• إرسال التاجر إلى صفحة رئيسية عامة أو صفحة إعدادات ليبحث بنفسه عن ربط زد.
• مطالبة التاجر بلصق Access Token أو Manager Token أو مفاتيح API أو كتابة ID المتجر يدويًا.

كذلك يجب أن تستخدم HTTPS، وتتحقق من قيمة state، وتطلب فقط الصلاحيات التي تحتاجها فعلًا. ومقالة «Publish your app» تنبّه إلى أن كل صلاحية تختارها يجب أن تكون مستخدمة في التكامل مع ذكر سببها، لأن الفريق سيختبرها.

متطلبات الدعم للتطبيقات العامة

بحسب مقالة «Support your customers»، يجب على كل تطبيق عام أن يوفّر قناة دعم واحدة على الأقل يستطيع التاجر من خلالها الحصول على المساعدة. سوق التطبيقات لا يقدّم الدعم للتجار في التطبيقات التي يبنيها طرف ثالث، فالمسؤولية عليك.

• بريد المسؤول (Maintainer E-mail) حقل إلزامي، ويجب أن يكون فعّالًا ومتابَعًا.
• رابط بوابة دعم (نظام تذاكر أو منتدى) اختياري، ويمكنك ذكره في وصف التطبيق.
• رقم الهاتف إلزامي لتطبيقات الشحن فقط.
• قائمة متطلبات المراجعة تطلب أيضًا قناة دعم داخل التطبيق نفسه، مثل محادثة مباشرة أو نموذج تواصل أو رابط تذاكر، منفصلة عن بيانات التواصل في صفحة السوق.

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

أسباب شائعة لإعادة التطبيق

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

• بيانات ناقصة أو غير مترجمة بين العربية والإنجليزية.
• اسم يحتوي على «Zid» أو صور تستخدم شعار زد.
• تفعيل لا يبدأ بـOAuth أو يطلب بيانات دخول يدوية.
• صلاحيات مطلوبة بلا مبرر أو غير مستخدمة في التكامل.
• غياب قناة دعم داخل التطبيق أو بريد دعم غير فعّال.
• مزايا باقات لا تطابق ما يقدمه التطبيق فعلًا، أو صفحة وفيديو لا يطابقان التجربة المنفّذة.

قائمة التحقق قبل الإرسال

1. وقّعت اتفاقية الشراكة وأكملت بيانات الشراكة.
2. اختبرت التطبيق على متجر تجريبي من التفعيل حتى آخر ميزة.
3. أضفت الباقات، واشتركت في Webhooks التي يحتاجها تطبيقك.
4. جهّزت حسابات اختبار لمنصتك إن لزم، دون طلب بيانات تجار حقيقيين.
5. جهّزت حالات اختبار QA وفيديو اختبار يغطي السيناريوهات الأساسية.
6. كتبت خطوات التفعيل ومتطلبات الإعداد والأسئلة الشائعة للتاجر.
7. أرسلت التطبيق للمراجعة من لوحة الشركاء، ثم أرسلت متطلبات الاختبار من الدعم: Technical Concern ثم App Testing.

كلما كان تطبيقك مكتملًا عند الإرسال، قلّت جولات التعديل وأصبح طريقك إلى النشر أقصر.