هل يحتاج تطبيقك سياسة خصوصية؟ قائمة تجهيز Google Play وApp Store

جهزت لقطات الشاشة والوصف ثم توقف إرسال التطبيق عند خانة «Privacy Policy URL». إذا كنت تنشر على Google Play أو App Store، فتعامل مع سياسة الخصوصية كمتطلب أساسي حتى لو كان تطبيقك بسيطًا أو لا ينشئ حسابات. المتجر يريد رابطًا عامًا، والإفصاحات يجب أن تطابق ما يفعله التطبيق ومكتباته فعلًا.

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

الجواب الرسمي من Google وApple

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

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

أما Apple، فتذكر مرجعية App Store Connect أن Privacy Policy URL مطلوب لكل التطبيقات. كما تفرض إرشادات المراجعة رابطًا في بيانات المتجر وداخل التطبيق بطريقة سهلة الوصول.

النتيجة العملية: لا تنتظر رفضًا كي تبدأ كتابة السياسة.

ابدأ بجرد البيانات لا بقالب

أكثر سياسة غير مفيدة هي التي تقول «لا نجمع بيانات» بينما يحتوي التطبيق Firebase Analytics أو Crashlytics أو إعلانات أو تسجيل دخول. قبل كتابة أي فقرة، اصنع جدولًا:

راجع:

• ملف Manifest والأذونات.
• pubspec.yaml أو package.json أو قائمة Dependencies.
• إعدادات Firebase وخدمات الإعلان.
• سجل الشبكة أثناء استخدام كل ميزة.
• لوحة كل SDK وسياسة بياناته.
• ما يرسله الخادم، لا ما كتبته في واجهة التطبيق فقط.

السياسة تصف النظام الحقيقي؛ لا ينبغي أن تجبر النظام على مطابقة جملة تخمينية لاحقًا.

ماذا يجب أن تتضمن السياسة؟

رتبها بعناوين واضحة:

1. اسم التطبيق والمطور: الاسم الذي يظهر في المتجر أو اسم الكيان المسؤول.
2. البيانات التي تجمعها: أنواع محددة، لا «بعض المعلومات».
3. كيف تجمعها: إدخال المستخدم، أذونات، SDK، خادم.
4. لماذا تستخدمها: تشغيل ميزة، دعم، أمان، تحليلات أو إعلانات.
5. المشاركة: أسماء أو فئات الأطراف الثالثة والغرض.
6. الاحتفاظ: مدة أو معيار يحدد المدة.
7. الحذف: كيف يطلب المستخدم حذف حسابه وبياناته.
8. الأمان: وصف واقعي للإجراءات من دون ادعاء ضمان مطلق.
9. الأطفال: هل التطبيق موجه لهم وما المتطلبات الخاصة.
10. التغييرات: كيف ومتى تحدث السياسة.
11. التواصل: بريد يعمل أو نموذج واضح.
12. تاريخ السريان والتحديث.

لا تنسخ أسماء خدمات لا تستخدمها من قالب. ولا تكتب «نستخدم تشفيرًا عسكريًا» ما لم تستطع تعريف ما تقصده وإثباته.

سياسة الخصوصية ليست Data Safety

الاثنان مرتبطان لكنهما ليسا صفحة واحدة:

• سياسة الخصوصية وثيقة عامة تشرح الممارسات بالتفصيل.
• Data Safety في Google Play إجابات منظمة تظهر في صفحة المتجر.
• App Privacy في Apple ملصق وإجابات عن أنواع البيانات وربطها بالمستخدم والتتبع.
• إذن النظام طلب للوصول إلى كاميرا أو موقع أو صور.
• الإفصاح البارز رسالة داخل التطبيق قبل جمع غير متوقع لبيانات حساسة.

وجود سياسة لا يعوض تصريحًا خاطئًا في Data Safety. وGoogle توضح أن المطور مسؤول عن دقة الإفصاح وتوافقه مع التطبيق وSDK.

تجربة بناء المسودة

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

لكن المولد لا يعرف شفرتك. بعد إنشاء المسودة:

1. استبدل كل نص افتراضي بمعلومة حقيقية.
2. احذف الأقسام غير المنطبقة.
3. أضف SDK الفعلية وروابط سياساتها.
4. طابق أنواع البيانات مع نماذج المتجر.
5. راجع آلية حذف الحساب.
6. اطلب مراجعة قانونية عندما تكون البيانات حساسة أو الأسواق متعددة.

القالب نقطة بداية، وليس ختم امتثال.

أين تستضيف السياسة؟

استخدم صفحة ويب عامة:

• تعمل من دون تسجيل دخول.
• لها رابط ثابت.
• متوافقة مع الهاتف.
• لا تكون PDF يحتاج تنزيلًا.
• لا تمنع زاحف المتجر.
• تحمل عنوانًا صريحًا «سياسة الخصوصية».
• تعرض اسم التطبيق ووسيلة التواصل.
• تستخدم HTTPS.

اربط الصفحة في Play Console أو App Store Connect، وأضفها داخل «الإعدادات» أو «حول التطبيق». اختبر الرابط في نافذة خاصة للتأكد أنه لا يعتمد على جلسة دخولك.

إذا غيرت النطاق أو مسار الصفحة، أنشئ Redirect دائمًا بدل ترك رابط المتجر يعيد 404.

حالة «لا نجمع أي بيانات»

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

في Apple، توضح صفحة App Privacy Details أن البيانات التي تعالج فقط على الجهاز ولا ترسل إلى خادم لا تعد «مجموعة» لأغراض إجابات الملصق. لكن أي اتصال بالدعم أو شراء أو SDK قد يضيف مسارًا آخر.

اكتب سياسة تقول بوضوح ما لا تجمعه، وما تتم معالجته محليًا، وكيف يمكن للمستخدم التواصل. لا تترك الصفحة فارغة.

متى تحدّث السياسة؟

راجعها عند:

• إضافة Analytics أو Ads SDK.
• إضافة تسجيل دخول.
• استخدام الموقع أو الصور أو جهات الاتصال.
• إطلاق اشتراك أو مدفوعات.
• تغيير مزود الاستضافة.
• إضافة مزامنة سحابية.
• تغيير مدة الاحتفاظ.
• دخول سوق أو جمهور جديد.
• إضافة ميزة ذكاء اصطناعي ترسل المحتوى إلى API.

حدّث كذلك Data Safety وApp Privacy. تعديل الوثيقة وحدها لا يصلح إفصاح متجر قديمًا.

أخطاء تؤدي إلى رفض أو فقد الثقة

• رابط سياسة يعيد 404.
• سياسة لتطبيق آخر أو باسم مطور مختلف.
• جملة «لا نجمع بيانات» مع SDK معروفة بالجمع.
• عدم ذكر الحذف والاحتفاظ.
• إخفاء البريد داخل صورة لا يمكن نسخه.
• استخدام لغة قانونية مبهمة بلا أنواع بيانات.
• نسيان الأطفال أو البيانات الصحية عند انطباقها.
• اختلاف السياسة عن Data Safety.
• وضع السياسة في صفحة تتطلب قبول Cookies قبل قراءة أي شيء.

أسئلة شائعة

هل التطبيق الذي لا يجمع بيانات يحتاج سياسة؟

نعم عند النشر في المتاجر المذكورة. Google تطلب أيضًا إكمال Data Safety، ويمكنك التصريح بعدم الجمع إذا كان ذلك صحيحًا.

هل المولد المجاني يكفي؟

يكفي لمسودة منظمة، لا لإثبات الامتثال. راجع الشفرة وSDK والقوانين المنطبقة.

هل يجب وضع الرابط داخل التطبيق؟

نعم، Google وApple تتوقعان وصولًا سهلًا إلى السياسة داخل التطبيق، إضافة إلى بيانات المتجر.

هل سياسة موقع الشركة تكفي؟

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

الخلاصة

السؤال ليس فقط «هل يحتاج تطبيقك سياسة خصوصية؟» بل «هل تصف السياسة التطبيق الحقيقي؟». ابدأ بجرد البيانات وSDK، اكتب الإفصاحات والحذف والاحتفاظ بوضوح، استضف رابطًا عامًا، ثم طابق Google Play وApp Store. المولد يسرع المسودة؛ المراجعة التقنية والقانونية هي التي تجعلها صادقة.