نموذج Data safety في Google Play: الدليل الكامل

نموذج Data safety هو استبيان يجب عليك تعبئته لكل تطبيق ترفعه إلى Google Play؛ تُفصح فيه عن أنواع البيانات التي يجمعها تطبيقك، ولماذا، وما إذا كانت هذه البيانات تُشارَك مع أطراف ثالثة. في Play Console، يوجد ضمن Policy > App content > Data safety بعد اختيار تطبيقك.

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

لا يمكنك الوصول إلى الإصدار الإنتاجي (production) دون إكمال النموذج؛ يظهر قسم Data safety المتروك فارغًا أو الذي لم يُفتح أبدًا كتحذير حاجب في مسار إصدار النسخة.

يطرح النموذج أسئلة على محورين منفصلين: جمع البيانات ومشاركة البيانات. وفقًا للتعريف الرسمي من Google، يعني الجمع نقل البيانات إلى خارج جهاز المستخدم — بواسطة تطبيقك أو SDK يستخدمه؛ أما البيانات التي تُعالَج على الجهاز فقط ولا تُرسَل إلى أي مكان (معالجة آنية/ephemeral على الجهاز) فلا تُحسب جمعًا ولا يلزم الإفصاح عنها. أما المشاركة فتعني نقل بيانات المستخدم المجمَّعة إلى طرف ثالث (شبكة إعلانية، مزوّد تحليلات) — وبغض النظر عن الغرض الأصلي من جمع البيانات، فإن نقلها إلى طرف ثالث يُحسب مشاركة. الاثنان ليسا الشيء نفسه، ويجعلك النموذج تحدد كلًا منهما على حدة.

على سبيل المثال، يُعد SDK إعلاني يأخذ معرّف الإعلانات (Advertising ID) لتخصيص الإعلانات ويرسله إلى خوادمه الخاصة جمعًا ومشاركة في آنٍ واحد: ينقل الـ SDK البيانات إلى خارج الجهاز (جمع)، وتُعالَج تلك البيانات على خوادم شبكة الإعلان الخاصة بها (مشاركة). في المقابل، البيانات التي تُرسَل فقط إلى الخادم الخلفي الخاص بك (خادم تُشغّله أنت مباشرة، وليس طرفًا ثالثًا) تُحسب جمعًا لكن لا تُحسب مشاركة، لأنه لا يوجد طرف ثالث معني. أما البيانات التي لا تغادر الجهاز إطلاقًا — والمحفوظة فقط في التخزين المحلي، مثل تفضيل مظهر أو لغة يتذكره التطبيق محليًا — فلا تُحسب جمعًا من الأساس؛ ووفقًا لتعريف Google الرسمي، لا يلزم الإفصاح عن هذا النوع من البيانات في النموذج إطلاقًا.

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

إذا كنت تستخدم AdMob، يجب عليك الإفصاح عن جمع معرّف الإعلانات (Advertising ID) واستخدامه لتخصيص الإعلانات؛ كما يمكن لـ AdMob معالجة الموقع التقريبي ومعلومات الجهاز/التطبيق لأغراض عرض الإعلانات ومنع الاحتيال. هذا إفصاح تشترطه سياسات الناشرين الخاصة بـ AdMob نفسها على المطورين — وتخطّيه يسبب مشاكل في مراجعة Play وفي لوحة تحكم AdMob على حدٍّ سواء.

إذا كنت تستخدم Firebase Analytics، فعليك تحديد أن تفاعلات التطبيق وبيانات الاستخدام تُجمع لأغراض التحليلات. وإذا كنت تستخدم Firebase Crashlytics، فعليك الإفصاح بشكل منفصل عن جمع سجلات الأعطال ومعرّفات الجهاز وبيانات التشخيص — فدمج Crashlytics في نفس سطر Analytics قد يُعد نقصًا في الإفصاح، لأنهما SDKs منفصلان ويستحقان سطرين منفصلين في النموذج.

إذا كان تطبيقك يجمع بياناته الخاصة بمعزل عن أي SDK — بريد إلكتروني أو هاتف تسجيل الدخول، تفاصيل الدفع، إذن الموقع — فأفصح عنها أيضًا بشكل منفصل. يُعد قسم التوثيق الخاص بكل SDK حول إفصاحات data-safety/الخصوصية المرجع الأكثر موثوقية عند تعبئة النموذج؛ وقد تتغير هذه المعلومات بين إصدارات الـ SDK.

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

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

المشكلة الأكثر شيوعًا هي نقص الإفصاح: يجمع التطبيق بيانات عبر SDK، لكن النموذج لا يعكس ذلك أبدًا. يحدث هذا عادةً عندما لا يُحدَّث النموذج بعد دمج SDK، ويمكن رصده كتناقض أثناء مراجعة Play الآلية أو اليدوية.

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

الثالثة هي عدم مراجعة النموذج بعد تغييرات المحتوى: إضافة SDK جديد، أو إذن جديد (الموقع مثلًا)، أو تكامل جديد مع طرف ثالث دون تحديث النموذج يترك الإفصاح الحالي غير متزامن مع السلوك الفعلي للتطبيق. يمكن لـ Google إعادة تقييم الإصدارات دوريًا في ضوء ذلك.