نموذج Data safety ليس اختبارًا له إجابات جاهزة؛ هو إقرار عن النسخة الحقيقية من تطبيقك وكل حزم SDK داخله. لتملأه بدقة، ارسم مسار كل نوع بيانات من لحظة إدخاله حتى الخادم أو الطرف الثالث، ثم طابق النموذج مع سياسة الخصوصية وحذف الحساب. لا توجد صيغة تضمن القبول، وGoogle يوضح أن مراجعته لا تتحقق نيابة عنك من اكتمال كل إقرار.
هذا الدليل إرشاد تقني عام، لا استشارة قانونية. راجعت دليل Google الرسمي وسياسات الحساب في 30 يوليو 2026.
من يجب أن يكمل النموذج؟
كل تطبيق منشور على مسار closed أو open testing أو production يجب أن يكمل Data safety. التطبيق الموجود حصريًا على internal testing مستثنى، لكنك ستحتاج النموذج قبل الانتقال إلى المسارات العامة.
حتى إن كان التطبيق لا يجمع بيانات، يجب إكمال النموذج، والتصريح بذلك، وإضافة سياسة خصوصية. هناك نموذج واحد لحزمة التطبيق كلها، ويجب أن يعكس مجموع ممارسات الإصدارات والمناطق المنشورة، لا النسخة التي اختبرتها وحدها.
ابدأ بجرد البيانات لا بشاشة Play Console
قبل فتح النموذج، أنشئ جدولًا بهذه الأعمدة:
| المصدر | نوع البيانات | هل يغادر الجهاز؟ | المستلم | الغرض | الاحتفاظ والحذف |
|---|---|---|---|---|---|
| تسجيل الدخول | بريد ومعرّف مستخدم | نعم | خادمك/مزود الهوية | إدارة الحساب | حتى حذف الحساب |
| Crash SDK | معرّف جهاز وسجل عطل | غالبًا نعم | مزود SDK | تشخيص | وفق الإعداد والعقد |
| صورة يختارها المستخدم | صورة | حسب التدفق | خادمك أو وجهة يحددها | وظيفة التطبيق | حسب السياسة |
راجع الشيفرة وملف dependencies ولوحات الخدمات. لا تعتمد على ذاكرة المطور؛ حزمة تحليلات أضيفت قبل عام قد تنقل معرفًا لم تعد تتذكره.
معنى Collected ومعنى Shared
تعرف Google Collected بأنه نقل البيانات خارج جهاز المستخدم. إن وصلت إلى خادمك أو مزود خدمة، فهي جمع حتى لو حذفتها سريعًا. أما Shared فهو نقلها إلى طرف ثالث، مع استثناءات محددة في السياسة.
هناك استثناءات مثل المعالجة المؤقتة، وبعض عمليات النقل التي يبدأها المستخدم، وبعض حالات مزودي الخدمة أو النقل القانوني. لا تختصرها بجملة "أي SDK يعني مشاركة" أو "التشفير يعني عدم الجمع". اقرأ تعريف كل استثناء وطبقه على التدفق الفعلي.
المعالجة على الجهاز لا تعد جمعًا إذا لم تغادر البيانات فعلًا. لكن مجرد قول إن الميزة "محلية" لا يكفي إن كانت خدمة الأعطال أو التحليلات ترسل بيانات وصفية عنها.
راجع كل SDK وإعداده
مسؤولية التصريح تقع عليك، لا على Firebase أو AdMob أو مزود تسجيل الدخول. افتح وثيقة Data safety لكل SDK، ثم راجع الميزات التي فعّلتها أنت؛ نفس الحزمة قد تجمع أنواعًا مختلفة حسب الإعداد.
اسأل:
- هل يجمع SDK معرف إعلان أو معرف جهاز؟
- هل يرسل الموقع أو نشاط التطبيق؟
- هل يمكنك تعطيل الجمع أو جعله بموافقة؟
- هل البيانات تستخدم للإعلان أو التحليلات أو وظيفة التطبيق؟
- هل إصدار Android ونسخة SDK الحالية يغيران السلوك؟
وثيقة المزود نقطة بداية وليست نسخة تلصقها. اختبر الشبكة عند الحاجة، وراجع لوحة المزود وعقد معالجة البيانات.
أنواع البيانات والأغراض
يسألك النموذج عن فئات مثل الموقع والمعلومات الشخصية والمعلومات المالية والرسائل والصور والفيديو ونشاط التطبيق ومعرفات الجهاز. لكل نوع تحدد إن كان مطلوبًا أو اختياريًا، وكيف يستخدم، وما إذا كان مشتركًا.
اختر كل غرض ينطبق: وظيفة التطبيق، والتحليلات، وإدارة الحساب، والإعلان، والتخصيص، ومنع الاحتيال. لا تخفِ غرضًا ثانويًا، ولا تضف غرضًا "احتياطيًا" لا يحدث. البطاقة يجب أن تصف المنتج الحالي.
التشفير أثناء النقل وحذف البيانات
أجب بنعم عن التشفير أثناء النقل فقط إذا كانت كل البيانات ذات الصلة تستخدم نقلًا آمنًا. افحص HTTP القديم، وواجهات طرف ثالث، ورفع الملفات، لا طلبات API الأساسية فقط.
إذا كان تطبيقك يسمح بإنشاء حساب، فسياسة حذف الحساب تطلب مسارًا واضحًا داخل التطبيق ورابط ويب يتيح طلب الحذف. حذف التطبيق من الهاتف ليس حذف حساب. وضّح ما يُحذف وما قد تحتفظ به لأسباب قانونية ومدة الاحتفاظ.
نفّذ الطلب من البداية للنهاية بحساب تجريبي: اطلب الحذف، تحقق من قاعدة البيانات والتخزين والنسخ الثانوية الممكنة، ثم افحص ما يراه المستخدم.
طابق النموذج مع سياسة الخصوصية
ضع الجدول السابق بجوار سياسة الخصوصية ونموذج Data safety:
- إن قلت إنك تجمع الموقع للتحليلات، يجب أن يظهر ذلك في السياسة.
- إن قلت إن البيانات لا تشارك، لا تترك Ad SDK يرسلها إلى شبكة إعلانات بلا تصريح مناسب.
- إن وعدت بالحذف، يجب أن يعمل المسار.
- إن تغير SDK أو الغرض، حدّث النموذج والسياسة مع الإصدار.
يمكن أن يساعدك مولّد سياسة الخصوصية في إنشاء هيكل أولي، لكنه لا يكتشف SDK ولا يعرف ممارسات خادمك ولا يرسل النموذج. خصص النص بناء على الجرد الحقيقي، واقرأ دليل هل يحتاج تطبيقك سياسة خصوصية؟.
خطوات الإرسال في Play Console
- افتح تطبيقك في Play Console.
- انتقل إلى Policy and programs > App content ثم Data safety.
- صرّح إن كان التطبيق يجمع أو يشارك بيانات.
- أضف أنواع البيانات، وحالة الاختيار، والأغراض، والمشاركة.
- أجب عن التشفير والحذف.
- راجع الملخص كما سيراه المستخدم.
- قارن الإجابات بالسياسة وجدول SDK مرة أخيرة ثم أرسل.
مسميات القوائم قد تتحرك، لكن Google يبقي النموذج ضمن App content.
أخطاء عملية تتكرر
أكثر الأخطاء وضوحًا هو مراجعة شيفرتك ونسيان SDK. يليه إعلان "لا نجمع بيانات" بينما خدمة الأعطال ترسل معرفات. ومن الأخطاء أيضًا وصف نسخة تطوير واحدة بدل مجموع النسخ المنشورة، أو إضافة سياسة عامة لا تذكر المنتج والمطور ووسيلة الاتصال.
خطأ أخطر: افتراض أن موافقة Play تعني أن التصريح صحيح قانونيًا وتقنيًا. Google يقول إن المطور مسؤول وحده عن الإقرار، وقد تظهر المخالفة لاحقًا عبر مراجعة أو شكوى أو تحديث SDK.
قائمة فحص قبل الضغط على Submit
- جردت البيانات من التطبيق والخادم وكل SDK.
- راجعت المسارات المفتوحة والمغلقة والإنتاج والمناطق.
- اختبرت التشفير أثناء النقل.
- طابقت كل نوع مع الغرض والاختيار والمشاركة.
- تعمل آلية حذف الحساب داخل التطبيق وعبر الويب عند انطباق الشرط.
- سياسة الخصوصية عامة ومتاحة وتطابق النموذج.
- سجلت تاريخ المراجعة وإصدارات SDK لتعرف متى تعيد التدقيق.
أسئلة شائعة
هل أملأ النموذج إذا كان التطبيق لا يجمع شيئًا؟
نعم للتطبيقات ضمن المسارات المطلوبة. تصرح بعدم الجمع أو المشاركة وتضيف رابط سياسة خصوصية.
هل بيانات Firebase إجابة واحدة ثابتة؟
لا. Firebase مجموعة منتجات، والسلوك يعتمد على الخدمة والإعداد والإصدار. راجع وثيقة كل مكون تستخدمه.
هل Data safety يغني عن سياسة الخصوصية؟
لا. البطاقة ملخص منظم داخل المتجر، والسياسة وثيقة أوسع. يجب أن يتوافقا.
هل Google يضمن صحة النموذج بعد القبول؟
لا. المراجعة ليست تدقيقًا كاملًا لممارساتك، والمسؤولية على المطور.
الخلاصة
أفضل طريقة لملء Data safety ليست البحث عن "الإجابة الصحيحة"، بل بناء سجل بيانات يمكن إثباته. اجرد التطبيق وSDK والخادم، اختبر الحذف والتشفير، وطابق النموذج مع السياسة. عندما يتغير المنتج، اعتبر تحديث Data safety جزءًا من قائمة إصدارك، لا مهمة تُنجز مرة واحدة.
