استخدام البيانات التي تحتاجها فقط

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

  • اشرح ما تحتاج إلى البيانات من أجله.
  • يجب جمع البيانات بدقة أقل.
  • إزالة البيانات بمجرد استخدامها.
  • عدم جمعها في المقام الأول.

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

لنستعرض المناهج المذكورة أعلاه، بالترتيب من الأكثر فعالية (ولكنّ الأكثر تأثيرًا في نشاطك التجاري) إلى الأقل فعالية ولكنه أقل إزعاجًا للتنفيذ.

عدم جمعها في المقام الأول

أكثر الطرق وضوحًا لتجنُّب المساس بتجربة المستخدمين البيانات هي عدم جمعها. يعد بعض جمع البيانات ضروريًا لتقديم الخدمات، ولكن هناك أماكن أكثر يمكنك فيها تجنب جمع البيانات أكثر مما تعتقد. ضع في اعتبارك، على سبيل المثال، إتمام الدفع بلا تسجيل دخول. عندما يشتري المستخدمون شيئًا باستخدام تطبيق الويب، قد تطلب منهم الاشتراك في حساب، لأنه بعد ذلك حصولك على التفاصيل الشخصية لتوفيرها لاحقًا: يمكن إضافتها إلى القائمة البريدية لأنّها مؤهَّلة مسبقًا. كعميل مهتم، وهكذا. ومع ذلك، فإن العملاء يعرفون هذا، ولا يحبونه: في عام 2021، توصّلت دراسة إلى أنّ واحدة من أصل أربع مبيعات تم التخلي عنها كانت بسبب طلب الموقع من المستخدم إنشاء حساب. إذا لم تكن بحاجة إلى حساب، من المرجح أن تحتفظ بهؤلاء العملاء. من خلال السماح بإكمال عملية شراء بدون اشتراك، يمكنك للمستخدمين خيارات أفضل ويعني أيضًا عدم توفر قدر كبير من بياناتهم لحمايتها وتأمينها.

"Fuzz" بياناتك

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

على سبيل المثال، من المفيد أحيانًا تكوين فكرة عن الخصائص الديمغرافية لجمهورك: أي الفئات العمرية التي يندرجون ضمنها، وموقعك، وهكذا. وقد يؤدي ذلك إلى تغيير رسالتك أو أسلوبك. ولكن هذا لا يعني أنك بحاجة إلى جمع البيانات، وعمر كل مستخدم لخدمتك. ما تبحث عنه غالبًا هو المؤشرات والخصائص العامة. إذا كان القرار الذي تريد مدى وصولك إلى المستخدمين يتأثر بما إذا كان معظم جمهورك ضمن "الفئة الديموغرافية الرئيسية 18 إلى 34"، فإن السؤال الوحيد الذي تحتاجه عليك طرحها هو ما إذا كان المستخدمون لديك ضمن تلك الفئة الديمغرافية. يؤدي ذلك إلى جمعها في "حزمتَين": في تلك المجموعة وليس في تلك المجموعة. قد تكون هناك مواقف تحتاج فيها إلى بيانات أكثر تفصيلاً من ذلك، ولكن من المنطقي تمامًا أن تأخذ قائمة الخصائص الديمغرافية. تستخدمها لاتخاذ القرارات وتطلب من المستخدمين تصنيف أنفسهم بهذه القائمة.

مثال

إذًا، إذا كان من المفيد معرفة كيفية تقسيم قاعدة المستخدمين لديك بين الفئات العمرية "18-34" و"35-49" و"49-64" و"65 فما فوق"، يمكنك بعدها أن تطلب من المستخدمين اختيار الفئات التي يندرجون تحتها. إنه من المغري أن تطلب تفاصيل دقيقة للغاية، البيانات الشخصية والمخصصة، ثم تصنيف المستخدمين بنفسك، حيث إن ذلك يتجنب الحاجة إلى طرح نفس السؤال مرة أخرى في بمزيد من التفصيل في وقت لاحق؛ على سبيل المثال، لطلب معلومات دقيقة عن العمر وتاريخ الميلاد، ومن ثم استخدام هذه المعلومات لإنشاء قوائمك الخاصة يظهر العديد من المستخدمين ضمن الفئة "35-49" . لكن من المهم أن تدرك كيف يبدو هذا: حيث إن الدورة قد تناولت بالفعل مرة أخرى، فإن طلب مستويات مفصلة من البيانات يمكن أن يجعل الأشخاص غير مرتاحين وبالتالي يقلل ثقة المستخدم في مؤسستك، مع إضافة المخاطر.

من المهم أيضًا مراعاة احتياجات بياناتك. في بعض الأحيان تكون "الحاجة" للحصول على بيانات أكثر دقة، يتطلب الأمر تخمينًا، "في حالة حدوث مجرد" المتطلب. ربما نحتاج في الوقت الحالي فقط إلى تصنيف المستخدمين ضمن تلك الفئات العمرية الأربع، ولكن في المستقبل قد نرغب في وبالتالي تضييق نطاق ذلك، وبالتالي ينبغي أن نجمع بيانات مفصلة للغاية الآن لإبقاء هذا الخيار مفتوحًا لوقت لاحق. قد يستحق الأمر مع الأخذ في الاعتبار عدد المرات التي تم فيها استخدام البيانات الأكثر دقة في الماضي لتوجيه القرارات. يُعد طلب البيانات إذا تم اعتبارها عدوانية مقارنةً بالخدمة المقدمة، يؤدي بالضرورة إلى انخفاض مدى ثقة المستخدمين التنظيم. وإذا تم جمع هذه البيانات لأسباب "تحسّبًا للظروف"، قد لا تكون مجرد تاجر ثقة للمستخدم قرارات الأعمال المحسنة، ولكن التداول فقط بعيدًا عن احتمالية اتخاذ بعض القرارات النظرية المستقبلية التي قد حتى مع مراعاة متطلبات الأمان لهذه المعلومات.

وهناك طرق خوارزمية أكثر تفصيلاً لتقليل دقة البيانات التي يتم جمعها أيضًا. طرق الاستجابة العشوائية أنه يتم جمع البيانات بدرجة مضبوطة من عدم الدقة، وأنها مستخدمة لعقود في البيانات الحساسة عند جمع بيانات يحتمل أن تكون عدوانية أو حساسة مع الحفاظ على سرية المجيب. تشير رسالة الأشكال البيانية أعلاه لجمع البيانات تتضمن توسيع إجابات المستخدم (لذا تصبح "كم عمرك" "أي من الفئات العمرية التالية تنطبق عليك")، حيث تتضمن الاستجابة العشوائية نسبة معينة من المستخدمين يكذبون بشأن إجاباتهم. إذا كانت نسبة المستخدمين الذين يجيبون بشكل غير صحيح معروفة، فعندئذ تكون استنتاجات ذات مغزى من البيانات التي تم جمعها، ولكن لا تتعرض خصوصية كل مستخدم للخطر لأن بياناته التي تم جمعها قد غير صحيحة. في هذه الحالة، إذا ما زال 80٪ من جمهورك يذكرون أنهم ضمن الفئة الديموغرافية 18-34، فيمكنك وهي ثقة نسبيًا بأنّ هذه النسبة لا تزال هي النسبة الأكبر، حتى إذا تعمّد% 10 منهم تقديم إجابات غير صحيحة. ويمكن أيضًا تغيير درجة عدم الدقة آليًا، حيث يتم دائمًا طلب الإجابات الصحيحة ولكن برنامج تغيير نسبة معينة من الإجابات قبل الإرسال. يمكن أن تؤدي هذه العملية وعواقبها أيضًا للمستخدمين عند جمع البيانات، ما يعني أنّ المستخدمين غير مضطرين إلى الوثوق بأنّك لن تسيء استخدام البيانات التي تم جمعها، لأن البيانات الفردية غير موثوقة.

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

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

الاحتفاظ بالبيانات: جمع البيانات ثم إزالتها بعد استخدامها

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

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

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

من المهم إدراك أهمية عمليات الإيقاف السهلة والافتراضية: "لبناء الثقة والاعتراف، يمكن للشركات بالموافقة على عقد اجتماعي يلتزم فيه باحترام الجمهور في كلّ نقطة اتصال والاستماع إلى احتياجاته والاستجابة وفقًا لذلك"، تنص على IAPP. أفادت مجموعة Nielsen Norman Group أنّ المستخدمين "يحتاجون إلى علامة "الخروج الطارئ" لترك الإجراء غير المرغوب فيه بدون الحاجة إلى الخضوع لعملية ممتدّة". يدرك الجميع أنه أن يكون الاشتراك أسهل من إلغاء الاشتراك ولكن، كما يقول نيلسن نورمان، فإن منح المستخدمين القدرة على الخروج دون الحاجة إلى القفز بين الإطارات، "يعزز الشعور بالحرية والثقة". وتدعم الدراسات الأكاديمية هذا الأمر وتسميته "مبدأ قابلية الإلغاء"، مفادها: "يجب أن تسمح الواجهة للمستخدم بإبطال المراجع التي منحها المستخدم بسهولة وفي أي مكان إمكانية إبطالها. يجب أن يتمكّن المستخدمون من إبطال هذه الموافقة، وبالتالي تقليل صلاحيات الوصول إلى مواردهم. إن أمكن". (يمكنك الانتقال إلى Yee وIacono للاطّلاع على أمثلة).

يختلف موضوع مدة الاحتفاظ بالبيانات والبيانات التي يجب الاحتفاظ بها اختلافًا كبيرًا بين المؤسسات بين المشروعات، ولكن هناك بعض الإرشادات الشائعة التي يجب مراعاتها.

الإجراءات الموصى بها

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

أدخِل عنوان 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.

السبب

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