تتجه متطلبات Google Play في 2026 نحو تشديد أكبر على شفافية البيانات (Data Safety)، والتحقق من هوية المطوّر التجاري، والتوافق مع أحدث إصدارات Android عبر متطلب target API level المحدث سنويًا. تطبيقات التجارة الإلكترونية معنية بشكل خاص لأنها تتعامل مع بيانات دفع وطلبات ومعلومات شخصية للعملاء، وأي تقصير في توثيق هذه البيانات قد يؤخر الموافقة على النشر أو التحديثات.

لماذا تتغير متطلبات Google Play باستمرار؟

Google تراجع سياساتها دوريًا استجابة لتطور تهديدات الأمان والخصوصية، وتفرض على جميع التطبيقات المستهدَفة لأسواق مختلفة (بما فيها السعودية والخليج) نفس المستوى من الشفافية بغض النظر عن حجم الشركة. الفارق أن تطبيقات التجارة الإلكترونية تحديدًا تحمل حساسية أعلى بسبب بيانات الدفع والعناوين والطلبات.

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

من يتابع هذه المتطلبات عمليًا نيابة عن صاحب المتجر؟

متابعة تفاصيل تقنية مثل target API level أو صياغة قسم Data Safety ليست مهمة يُتوقع من صاحب متجر عادي إتقانها بنفسه، بل مسؤولية فريق تطوير التطبيق أو مزود الخدمة الذي يديره. دور صاحب المتجر الأساسي هنا هو التأكد أن هذه المتابعة بند صريح ومكتوب ضمن عقد الصيانة، لا افتراضًا ضمنيًا قد لا يلتزم به الطرف الآخر عمليًا عند حدوث تغيير سياسة مفاجئ.

أبرز المتطلبات التي تحتاج تطبيقات المتاجر الانتباه لها

1. قسم Data Safety الدقيق والمحدّث

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

2. التحقق من هوية المطوّر التجاري (Business Verification)

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

3. استهداف أحدث إصدار من Android (Target API Level)

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

4. سياسات أوضح حول الإعلانات والمحتوى المدفوع داخل التطبيق

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

هل تخطط Google لمزيد من التشديد بعد 2026؟

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

جدول: أثر كل متطلب على تطبيق متجرك

المتطلب	الأثر إذا أُهمل	الإجراء المطلوب
Data Safety غير دقيق	تعليق محتمل بعد المراجعة أو شكاوى مستخدمين	مراجعة القسم مع كل تحديث يغيّر نوع البيانات المجمّعة
عدم التحقق من هوية المطوّر	تأخير أو رفض نشر تحديثات جديدة	استكمال التحقق التجاري في Google Play Console مبكرًا
target API level قديم	منع رفع تحديثات جديدة للتطبيق	التحديث الفني مع كل نسخة سنوية جديدة

كيف تجهز تطبيق متجرك لهذه المتطلبات دون تعطيل النشر؟

• راجع قسم Data Safety في Google Play Console كل مرة تُضيف فيها ميزة تجمع بيانات جديدة (مثل تكامل دفع أو شحن إضافي).
• تأكد من مزود خدمة التطبيق أن الإصدار المرفوع يستهدف دائمًا آخر متطلب API معتمد من Google قبل كل رفع تحديث.
• وثّق معلومات نشاطك التجاري في Google Play Console بدقة تطابق سجلاتك الرسمية لتجنب أي تأخير في التحقق.

ماذا لو كان تطبيقك قائمًا بالفعل ولم يواكب هذه المتطلبات بعد؟

الخطوة الأولى هي جرد سريع: افتح Google Play Console وراجع تنبيهات السياسات إن وُجدت، ثم قارن قسم Data Safety الحالي مع الميزات الفعلية في أحدث نسخة من التطبيق. إذا وجدت فجوة، صحّحها فورًا حتى لو لم تكن هناك مخالفة رسمية معلنة بعد، لأن الاستباقية هنا أرخص بكثير من التعامل مع تعليق مفاجئ لاحقًا يؤثر على عملائك الحاليين مباشرة.

هل هذه المتطلبات تختلف عن App Store؟

Apple لديها متطلبات مماثلة من حيث الجوهر (شفافية البيانات، التحقق من الهوية) لكن بآليات مختلفة تقنيًا. الفكرة المشتركة أن كلا المتجرين يتجهان لمزيد من الرقابة على تطبيقات التجارة الإلكترونية تحديدًا بسبب حساسية بيانات الدفع والعملاء التي تتعامل معها.

من يتحمل مسؤولية المتابعة الفنية لهذه المتطلبات؟

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

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

إذا واجه تطبيقك من قبل مشكلة في مراجعة أحد المتجرين، راجع دليل أسباب رفض التطبيقات في App Store وكيف تتجنبها لفهم أنماط الرفض الشائعة التي تنطبق مبادئها على Google Play أيضًا. وإذا كنت تخطط لنشر تطبيقك على المتجرين لأول مرة، ابدأ من دليل نشر تطبيقك على App Store وGoogle Play: المتطلبات والخطوات والمدة لتفهم الصورة الكاملة قبل البدء.

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

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

هل تعليق تطبيق قائم يحدث فورًا عند تغيير المتطلبات؟

عادة لا، Google تمنح فترة سماح لتحديث التطبيقات القائمة قبل تطبيق المتطلبات الجديدة بشكل صارم، لكن هذه الفترة محدودة ويجب عدم الاعتماد عليها طويلًا.

هل صغر حجم المتجر يعفيه من هذه المتطلبات؟

لا، المتطلبات تنطبق على جميع التطبيقات بغض النظر عن حجم النشاط التجاري أو عدد المستخدمين.

من المسؤول عن تحديث target API level، أنا أم شركة التطوير؟

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