من الطرق الجيدة لتقليل المخاطر التي يواجهها المستخدمون عدم الاحتفاظ ببيانات حساسة عنهم لا تحتاج إليها والتي تؤثّر في خصوصيتهم. هناك عدد كبير من الطرق لإجراء ذلك مع مواصلة تحقيق أهداف نشاطك التجاري، ومن المفيد التفكير في كل طريقة. يمكنك القيام بما يلي:
- اشرح ما تحتاج إلى البيانات من أجله.
- جمع البيانات بدرجة دقة أقل
- إزالة البيانات بمجرد استخدامها.
- عدم جمعها في الأساس
يمكن أن تساعد كل طريقة من هذه الأساليب المستخدمين في الشعور براحة أكبر تجاه ما تفعله والسبب وراء ذلك، وهذا يساهم بشكل كبير لعلاقتك بهم. تعمل الشفافية على بناء الثقة، والأهم من ذلك، يمكن أن تكون الثقة نقطة بيع فريدة لك. يفترض العديد من الأشخاص أنّ المستخدمين والعملاء يثقون بهم تلقائيًا، ولكن المستهلكين يقيّمون المنتجات والخدمات باستمرار وقد لا يكون هذا هو الحال. إذا نجحت في بناء علاقة مع المستخدمين تجعلهم يثقون بك في ما يتعلّق بمعالجة بياناتهم وتفاعلاتك معهم، يمكن أن يمنحك ذلك ميزة تنافسية كمشروع أو نشاط تجاري، لأنّه عنصر تمييز حقيقي قد لا يتمكن منافسوك من مطابقته.
لنطّلع على الأساليب المذكورة أعلاه، بدءًا من الأكثر فعالية (والأكثر تأثيرًا في نشاطك التجاري أيضًا) وصولاً إلى الأقل فعالية، ولكن الأقل تأثيرًا في سير العمل عند تنفيذها.
عدم جمع هذه البيانات في الأساس
إنّ الطريقة الأكثر وضوحًا لتجنُّب اختراق بيانات المستخدمين هي عدم جمعها. إنّ جمع بعض البيانات ضروري لتقديم الخدمات، ولكن هناك أماكن أكثر مما تتوقّع يمكنك فيها تجنُّب جمع البيانات. ضع في اعتبارك، على سبيل المثال، إتمام الدفع بلا تسجيل دخول. عندما يريد المستخدمون شراء منتج باستخدام تطبيقك على الويب، يمكنك مطالبتهم بإنشاء حساب، لأنّ ذلك يتيح لك تسجيل تفاصيلهم الشخصية لاستخدامها لاحقًا: يمكن إضافتهم إلى القائمة البريدية، ويكونون مؤهَّلين مسبقًا كهيّا عملاء مهتمين، وما إلى ذلك. ومع ذلك، يلاحظ العملاء ذلك ولا يعجبهم: في عام 2021، تبيّن من خلال إحدى الدراسات أنّ عملية بيع واحدة من كل أربع عمليات بيع تم إلغاؤها لأنّه طلب الموقع الإلكتروني من المستخدم إنشاء حساب. وإذا لم تطلب إنشاء حساب، من المرجّح أن تحافظ على هؤلاء العملاء. من خلال إتاحة إكمال عملية شراء بدون الاشتراك، يمنحك المستخدمون خيارات أفضل، ويعني ذلك أيضًا أنّك لن تحتاج إلى حماية الكثير من بياناتهم.
تشويش بياناتك
بالطبع، قد لا يكون تجنب جمع البيانات على الإطلاق خيارًا متاحًا. من المهم جمع البيانات لتقديم الخدمات واتخاذ قرارات تجارية مدروسة. قد يكون من المفيد أيضًا إنشاء مراسلات تسويقية في سياق علاقة ثقة. ومع ذلك، من المهم أيضًا معرفة أنّ القرارات التي يتم اتخاذها بشكل مجمّع (أي التي تؤثّر في العديد من المستخدمين في آنٍ واحد) يتم اتخاذها بشأن البيانات بشكل مجمّع (أي بشأن الخصائص المجمّعة للبيانات).
على سبيل المثال، من المفيد أحيانًا تكوين فكرة عن الخصائص الديمغرافية لجمهورك: أي الفئات العمرية التي يندرجون ضمنها، وموقعك، وهكذا. وقد يؤدي ذلك إلى تغيير رسائلك أو أسلوبك. ولكن هذا لا يعني أنّك بحاجة إلى جمع العمر الدقيق لكل مستخدم لخدمتك. ما تبحث عنه غالبًا هو المؤشرات والخصائص العامة. إذا كان القرار الذي تريد اتخاذه يتأثّر بما إذا كان معظم جمهورك يندرج ضمن "الفئة الديمغرافية الرئيسية من 18 إلى 34 عامًا"، فإنّ السؤال الوحيد الذي تحتاج إلى طرحه هو ما إذا كان المستخدمون يندرجون ضمن هذه الفئة الديمغرافية. يؤدي ذلك إلى جمعها في مجموعتَين: في تلك المجموعة وليس في تلك المجموعة. قد تكون هناك مواقف تحتاج فيها إلى بيانات أكثر تفصيلاً من ذلك، ولكن من المنطقي تمامًا أن تأخذ قائمة الخصائص الديمغرافية. تستخدمها لاتخاذ القرارات وتطلب من المستخدمين تصنيف أنفسهم بهذه القائمة.
مثال
إذًا، إذا كان من المفيد معرفة كيفية تقسيم قاعدة المستخدمين لديك بين الفئات العمرية "18-34" و"35-49" و"49-64" و"65 فما فوق"، يمكنك بعدها أن تطلب من المستخدمين اختيار الفئات التي يندرجون تحتها. من المغري طلب بيانات مفصّلة للغاية وشخصية ومخصّصة، ثم تصنيف المستخدِمين بنفسك، لأنّ ذلك يتجنّب الحاجة إلى طرح السؤال نفسه مرة أخرى بمزيد من التفصيل لاحقًا. على سبيل المثال، يمكنك طلب العمر وتاريخ الميلاد بالضبط، ثم استخدام هذه المعلومات لإنشاء قوائم خاصة بك بعدد المستخدِمين في الفئة العمرية "من 35 إلى 49". من المهمّ معرفة كيف سيبدو ذلك: بما أنّ الدورة التدريبية قد غطّت هذه المستويات في السابق وستغطّيها مرة أخرى، فإنّ طلب مستويات مفصّلة من البيانات قد يثير انزعاج المستخدمين وبالتالي يقلل من ثقتهم في مؤسستك، ويزيد من المخاطر.
من المهم أيضًا مراعاة احتياجات بياناتك. في بعض الأحيان تكون "الحاجة" للحصول على بيانات أكثر دقة، يتطلب الأمر تخمينًا، "في حالة حدوث مجرد" المتطلب. ربما نحتاج في الوقت الحالي فقط إلى تصنيف المستخدمين ضمن تلك الفئات العمرية الأربع، ولكن في المستقبل قد نرغب في وبالتالي تضييق نطاق ذلك، وبالتالي ينبغي أن نجمع بيانات مفصلة للغاية الآن لإبقاء هذا الخيار مفتوحًا لوقت لاحق. قد يكون من المفيد التفكير في عدد المرات التي تم فيها استخدام البيانات الأكثر دقة في الماضي لتوجيه القرارات. إنّ طلب بيانات يُنظر إليها على أنّها تدخلية مقارنةً بالخدمة المقدَّمة يؤدي بالضرورة إلى انخفاض ثقة المستخدمين في مؤسستك. إذا كان يتم جمع هذه البيانات "فقط في حال"، قد لا تفقد ثقة المستخدمين فقط في ما يتعلّق باتخاذ قرارات تجارية محسّنة، بل قد تفقد ثقتهم أيضًا بسبب احتمالية اتخاذ قرار مستقبلي نظري قد لا يكون متوفّرًا، مع تحمل متطلبات الأمان لهذه المعلومات.
هناك طرق خوارزمية أكثر تفصيلاً لتقليل دقة البيانات التي يتم جمعها أيضًا. طرق الاستجابة العشوائية: تعني هذه الطرق أنّه يتم جمع البيانات بدرجة من عدم الدقة يمكن ضبطها، وقد تم استخدامها لعدة عقود في العلوم الاجتماعية عند جمع البيانات التي يُحتمل أن تكون مزعجة أو حسّاسة مع الحفاظ على سرية المجيب. تشير رسالة الأشكال البيانية أعلاه لجمع البيانات تتضمن توسيع إجابات المستخدم (لذا تصبح "كم عمرك" "أي من الفئات العمرية التالية تنطبق عليك")، حيث تتضمن الاستجابة العشوائية نسبة معينة من المستخدمين يكذبون بشأن إجاباتهم. إذا كانت نسبة المستخدمين الذين يقدّمون إجابات خاطئة معروفة، يمكن استخلاص استنتاجات مفيدة من البيانات التي تم جمعها، ولكن لا يتمّ انتهاك خصوصية المستخدِم الفردي لأنّ البيانات التي تم جمعها قد تكون خاطئة. في هذه الحالة، إذا ما زال 80٪ من جمهورك يذكرون أنهم ضمن الفئة الديموغرافية 18-34، فيمكنك وهي ثقة نسبيًا بأنّ هذه النسبة لا تزال هي النسبة الأكبر، حتى إذا تعمّد% 10 منهم تقديم إجابات غير صحيحة. يمكن أيضًا تغيير درجة الخطأ آليًا، حيث يتم طلب الإجابات الصحيحة دائمًا، ولكن يغيّر البرنامج نسبة مئوية معيّنة من الإجابات قبل إرسالها. يمكن أيضًا شرح هذه العملية وعواقبها للمستخدمين عند جمع البيانات: يعني ذلك أنّه ليس على المستخدمين الوثوق بك بأنّك لن تسيء استخدام البيانات التي يتم جمعها، لأنّ البيانات الفردية غير موثوقة.
هناك عملية مشابهة ولكنّها أكثر تعقيدًا من الناحية الفنية، وهي الخصوصية التفاضلية. يستخدم هذا تقنيات رياضية لتغيير تخزين البيانات بحيث لا تزال خصائص البيانات المجمعة موجودة، ولكن فلا يمكن حتى معرفة ما إذا كان شخص معين قد قدم بيانات، أو ما إذا كان هناك أي بيانات قدمها. مثل الردّ العشوائي، تحمي هذه الطريقة بيانات المستخدمين حتى منك، وتوضّح نية واضحة من جانبك: لا يمكنك استخدام بيانات المستخدمين إذا لم تكن لديك هذه البيانات.
توفّر هذه الأساليب والأساليب المشابهة أيضًا مزيدًا من الأمان ضد عمليات اختراق البيانات وتسرُّبها، وذلك لأنّ البيانات التي يتم جمعها ويقلل من المخاطر التي تهدد خصوصية المستخدم، حتى لك، وسيقلل أيضًا من مستوى الاختراق في حالة تسرُّب البيانات. يُرجى العِلم أنّه في حال كنت تطبّق تقنيات الخصوصية التفاضلية على الخادم (كي يرسل إليك المستخدمون بيانات غير مجمّعة ثم تستخدم هذه التقنيات لتجميعها)، لا يزال عليك تأمين بيانات المستخدمين الأوّلية ثم حذفها بعد معالجتها، ويجب أن تتّبع سياسات واضحة لتأكيد عدم استخدامها قبل التجميع (أو أن تكون واضحًا بشأن الغرض من استخدامها).
الاحتفاظ بالبيانات: جمع البيانات ثم إزالتها بعد استخدامها
ومن المفيد أن تتذكر أن البيانات التي تم جمعها لها دورة حياة؛ التي يتم جمعها، ويتم استخدامها لمساعدتك في اتخاذ قرارات العمل، ثم، في مرحلة ما، يجب أن تتم إزالته. هذه هي، مرة أخرى، المفاضلات: عندما تطرح أسئلة على المستخدمين أو تخزين معلومات عن مواقع الويب الأخرى التي زارها، أو تتبع الأشياء التي اطّلع عليها، ومدتها التنبؤات بتفضيلاتهم، فهذه هي البيانات التي يتم منحها لك لغرض معين، وليس منحة مفتوحة للمطور لاستخدامها على النحو الذي تراه مناسبًا. وعند عدم الحاجة إلى تلك البيانات لهذا الغرض، في بعض الأحيان بعد دقيقة، وأحيانًا بعد سنوات عديدة يجب حذفها.
عند جمع معلومات عن المستخدمين، يجب أن تعرف الغرض من استخدام هذه البيانات (راجِع المعلومات أدناه)، ويجب أيضًا معرفة متى ستتوقف عن الاحتفاظ بهذه البيانات وسبب ذلك. قد يحدث ذلك عندما يختار المستخدم حذفها أو عندما يوقّع أو بعد فترة زمنية محددة أو بعد وقوع حدث معين. طريقة ممتازة لبناء الثقة في العلاقة هي توضيح للمستخدمين كيفية التحكم في البيانات المتعلقة بهم، بما في ذلك، حيثما أمكن، إلغاء الاشتراك من جانب واحد. كيف تحذف هذه التطبيقات بيانات المستخدمين؟ كيف يحذفون حساباتهم؟ بالإضافة إلى المساعدة في بناء هذه العلاقة، من أفضل الممارسات تخزين البيانات لمدة لا تزيد عن المدة التي تحتاجها لمعالجتها، ويجب أن تتوفّر طريقة للمستخدمين لاطلاعهم على البيانات التي تجمعها منهم أو نيابةً عنهم وإزالتها. وقد يكون هناك تشريع في هذه المرحلة في المناطق الذي تديره.
هذا هو المجال الذي يمكنك فيه تحديد أهداف فنية واضحة تساعد المستخدمين في الخدمة الذاتية. إذا كان بإمكان المستخدمين إيقاف استخدام مستودع البيانات بدون الحاجة إلى طلب الإذن، سيشعرون بالراحة عند تفعيله، ولا يحتاج ذلك إلى أيّ موارد دعم لتنفيذه.
من المهمّ التعرّف على أهمية خيارات الإيقاف السهلة والتلقائية: "لتعزيز الثقة والاعتراف، يمكن للشركات البدء بالموافقة على اتّفاقية اجتماعية تلتزم فيها باحترام جمهورها في كل نقطة اتصال، والاستماع إلى احتياجاته والاستجابة وفقًا لذلك"، وفقًا لما ذكرته IAPP. تشير Nielsen Norman Group إلى أنّ المستخدمين "يحتاجون إلى علامة واضحة تدل على 'مخرج الطوارئ" للخروج من الإجراء غير المرغوب فيه بدون الحاجة إلى اتّباع عملية طويلة". يدرك الجميع أنه أن يكون الاشتراك أسهل من إلغاء الاشتراك ولكن، كما يقول نيلسن نورمان، فإن منح المستخدمين القدرة على الخروج دون الحاجة إلى القفز بين الإطارات، "يعزز الشعور بالحرية والثقة". تؤيد الدراسات الأكاديمية هذا المبدأ وتُطلق عليه اسم "مبدأ إمكانية الإبطال"، وتشير إلى أنّه "يجب أن تسمح الواجهة للمستخدم بإبطال الأذونات التي منحها بسهولة في أي مكان يكون فيه الإبطال ممكنًا. يجب أن يتمكّن المستخدمون من إبطال هذه الموافقة، وبالتالي تقليل صلاحيات الوصول إلى مواردهم. إن أمكن". (اطّلِع على Yee وIacono للحصول على أمثلة).
يختلف موضوع مدة الاحتفاظ بالبيانات والبيانات التي يجب الاحتفاظ بها كثيرًا بين المؤسسات وبين المشاريع، ولكن هناك بعض الإرشادات الشائعة التي يجب أخذها في الاعتبار.
الإجراءات الموصى بها
من المفيد هنا السماح للمستخدمين بحذف الحسابات (وأي بيانات مرتبطة بها، حيثما أمكن ذلك) وبشكل منتظم (على سبيل المثال، عند الخروج) محو البيانات المؤقتة والمخزّنة على الجهاز باستخدام العنوان Clear-Site-Data.
قدِّم رأس Clear-Site-Data
لإزالة بعض بيانات المستخدمين أو جميعها التي تم تخزينها من جهة العميل (سواءً في ملفات تعريف الارتباط أو localStorage أو IndexedDB أو في ذاكرة التخزين المؤقت للمتصفّح)، عندما يكون ذلك معقولاً. إن حالة الاستخدام الواضحة لـClear-Site-Data هي عندما يقوم مستخدم
تسجيل الخروج، ولكن يمكن استخدامه أيضًا بعد محاولات الاختراق الأمني لضمان عدم وجود أي آثار مستمرة للحساب المُحتمَل تعرّضه للاختراق
من البيانات المخترقة المخزنة على العميل.
تتضمن إضافة التوافق مع Clear-Site-Data
إرسال عنوان HTTP، مثل Clear-Site-Data
، عندما يسجِّل المستخدم خروجه (أو
الأوقات التي تريد فيها محو مساحة التخزين من جهة العميل)، على الصفحة التي تؤكد حالة تسجيل الخروج (https://your-site/logout
أو ما شابه ذلك). يمكن أن يحتوي هذا العنوان على بعض القيم التالية أو جميعها، أو "*"
لكل القيم:
Clear-Site-Data: "cache", "cookies", "storage"
تعمل هذه القيم على محو الصفحات المخزّنة مؤقتًا (وموارد HTTP الأخرى المخزّنة مؤقتًا) وملفات تعريف الارتباط المخزّنة وlocalStorage وIndexedDB وما شابه ذلك.
قد يظهر لك خيار آخر، وهو executionContexts
، ولكن هذا الخيار غير متوافق مع العديد من المتصفّحات.
يُرجى العِلم أنّ استخدام العنوان Clear-Site-Data
قد يكون أسهل من حذف جميع الموارد التي تم إنشاؤها بنفسك بشكلٍ فردي، لأنّه لا يتطلّب تنفيذ رمز JavaScript على العميل (وهي الطريقة الرسمية الوحيدة لمحو ذاكرة التخزين المؤقت للمتصفّح)، ولكنّه لا يتوافق مع جميع المتصفّحات.
ملاحظة حول الاستخدام: في حال محو ذاكرة التخزين المؤقت (من خلال إرسال Clear-Site-Data: cache
)، يجب عدم
إرسال العنوان Clear-Site-Data
في صفحة تسجيل الخروج الفعلية، ولكن على بعض الموارد الأخرى التي يتم تحميل الصفحة منها. هذا لأنه عندما يكون جهاز الكمبيوتر أبطأ
إذا كانت الصفحة تحتوي على ذاكرة تخزين مؤقت كبيرة، فستحظر الصفحة أثناء مسح ذاكرة التخزين المؤقت مما يمنع التنقل. قد يستغرق تنفيذ ذلك بضع دقائق،
مما سيجعل المستخدم محبطًا. من غير المرجّح حدوث ذلك، ولكن من الصعب اختباره، لذا من الأفضل أخذ ذلك في الاعتبار.
توضيح الغرض من استخدام البيانات
لقد تمّت الإشارة مرارًا وتكرارًا إلى أهمية الثقة في علاقة المستخدمين بخدمتك، لأنّها تزيد من فترة استخدامهم لخدمتك. كما يوفّر ميزة تنافسية. وإحدى الطرق لزيادة هذا المستوى من الثقة هي من خلال الشفافية في عملياتك، وأحد الطرق الجيدة للالتزام بالشفافية هي شرح الغرض من طلب البيانات. لقد تعرّفت في وقت سابق على أنّه يجب معرفة متى سيتم حذف كل عنصر يتم جمعه. لمعرفة ذلك، عليك معرفة سبب حاجتك إلى هذه البيانات والأسئلة المحدّدة التي تحتاج إليها لمحاولة العثور على إجابات، والقرارات التي ستستند إلى جمعها. بمجرد أن تعرف سبب احتياجك إلى هذه البيانات التي طلبت أن يستسلم، فسيساعد ذلك على بناء الثقة من خلال توضيح ذلك لهؤلاء المستخدمين. في سياسة الخصوصية أو عند طرح أسئلة حول إنشاء الحساب، يجب توضيح سبب حاجتك إلى الإجابة عن هذا السؤال تحديدًا، والغرض من استخدام هذه البيانات، ووقت وكيفية إزالتها.
وتكون هذه التفسيرات أكثر وضوحًا عند تقديمها مضمّنة. قد يبدو أنّ إخفاء التفسيرات في مستند سياسة كثيف في مكان آخر على الموقع الإلكتروني يهدف إلى إخفاءها. يمكن أن يعرض نموذج الاشتراك أو الدفع أو الطلب أسباب جمع البيانات بجانب عملية الجمع نفسها. غالبًا، قد يحتوي حقل النموذج على علامة النجمة (*) للإشارة إلى أن هذا الحقل مطلوب؛ تحتوي النماذج المعقدة غالبًا على رابط معلومات (1) لشرح ما يعنيه الحقل. ننصحك بإضافة وصف لسبب جمع البيانات إلى هذه التفسيرات. بشكل متكرر مستخدمة لهذه العبارة هي "لماذا نحتاج إلى هذا؟" بجانب حقل النموذج، والذي عند النقر عليه يعرض شرحًا منبثقًا.
قد تظهر بعض نماذج HTML على النحو التالي، ثم تعتني CSS وJavaScript بإخفاء <aside>
وعرضها في نافذة منبثقة عندما
عند النقر على الرابط. (احرص على التأكّد من إمكانية وصول المستخدمين إلى النموذج الذي تنشئه لموقعك الإلكتروني).
تعتمد كيفية تخطيط هذا بالضبط على أنماطك وأساليبك، ولكن النقطة الرئيسية هنا هي الربط المباشر بين جمع البيانات
شرحًا لسبب جمع هذه البيانات. وهذا ليس ضروريًا لكل حقل. لا يحتاج أحد إلى شرح سبب مطالبتك باختيار كلمة مرور عند الاشتراك. ولكن يمكن أن يساعد توضيح كيفية استخدام معلومات الاتصال والمعلومات الشخصية والاحتفاظ بها في
توضيح التزامك بحماية بيانات المستخدمين.
<div>
<label for="email">Email address*</label>
<input id="email" type="email" name="email" required aria-describedby="whyemail">
<a href="#whyemail">Why do we need this?</a>
<aside id="whyemail">We need this information as a unique identifier for you, and if you forget your password we can send you a reminder. We will use your email address to send you regular updates on the service if you choose, and will delete your email address from any mailing lists if you delete your account.</aside>
</div>
يمكن أن يساعدك أيضًا إجراء هذه العملية مع كل ما تجمعه عن المستخدِم في العمليات والمناقشات الداخلية. في وقت سابق، رأيت كيف يمكن أن يكون هناك إغراء لجمع البيانات "في حالة حدوث ذلك". عندما تكون شفافيًا بشأن أسباب جمع البيانات، قد يكون من الواضح تمامًا أنّك تفعل ذلك. إذا كنت تتردّد في تدوين ما تريد بشكل علني فعلها ببيانات المستخدم لأن هؤلاء المستخدمين لن يحبوا الشرح، فقد تكون هذه علامة على أن الأمر يستحق إعادة التفكير في جمع بها. وينطبق هذا سواء كان التفسير المزعج ذلك عدوانيًا للغاية ("سنستخدم هذا لتتبع الأماكن التي تزورها على أساس كل ساعة")، واسعة النطاق ("لا نعرف ما الذي سنستخدمه هذا حتى الآن ولكننا نريده في حالة التفكير في شيء ما له") أو شديد الغموض ("سنستخدم هذه المعلومات لأغراض داخلية لم يتم الإفصاح عنها"). لا يقتصر ذلك على الجانب الأخلاقي، فالمستخدمون على دراية بما سبق ذكره، ويتوقعون أنّ تجربة منتج معيّن لا تعني بدء التزام طويل الأمد. من الشائع في تصميم تجربة المستخدم أن يكون الاشتراك سلسًا وسهلاً قدر الإمكان، لأنّ المستخدم في المراحل الأولى لا يستثمر بشكل كبير في خدمتك (بحكم التعريف)، لذا من المهم السماح له بزيادة استثماراته بسهولة عندما لا يكون لديه ميل كبير لذلك. وإذا كان من السهل الخروج مرة أخرى، تصبح تجربته مع الخدمة تجربة فعلية وليست بداية غير مرغوب فيها لالتزام قسري على المدى الطويل. من المتناقض أنّ أفضل طريقة لبناء الثقة هي عدم اشتراط أن يثق المستخدمون بك. لا تريد ذلك.
لدى الأشخاص أسباب وجيهة لعدم مشاركة البيانات أو لمشاركة الحد الأدنى من البيانات. في بداية علاقتك بهم، قد لا يكون لديهم سبب للثقة بك، ولا يجب أن يكون لديهم سبب لذلك. وهدفك هو توضيح سبب ذلك.
الإجراءات الموصى بها
- حدد جميع البيانات التي تخطط لجمعها وسبب اهتمامك بها والمدة التي ستحتفظ بها فيها.
- عندما تطلب هذه البيانات، اشرح للمستخدمين سبب جمعك لها.
- حذفها من قواعد بيانات الخادم بعد استخدامها
- يتيح هذا الخيار للمستخدمين إمكانية حذف الحسابات التي أنشأها ومحو البيانات المخزَّنة من مساحة التخزين باستخدام العنوان
Clear-Site-Data
.
السبب
إن بناء علاقة مع المستخدمين يدور حول الثقة، والثقة تعني الانفتاح. إذا كان بإمكانك إثبات أنك لا مجرد جمع أكبر قدر ممكن من البيانات عن المستخدمين وإخفاء استخداماتك لذلك، فإن ذلك يساعد على بناء الثقة، مما قد ميزة تنافسية لك مقارنةً بالمنافسين الأقل شراسةً.