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

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

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

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

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

عدم جمعها في الأساس

تتمثل الطريقة الأكثر وضوحًا لتجنب المساومة على بيانات المستخدمين في عدم جمعها. بعض جمع البيانات ضروري لتقديم الخدمات، ولكن هناك المزيد من الأماكن التي يمكنك تجنب جمع البيانات فيها أكثر مما تعتقد. فكر مثلاً في خيار إتمام الدفع بلا تسجيل دخول. عندما يأتي المستخدمون لشراء شيء ما باستخدام تطبيق الويب الخاص بك، قد تطلب منهم الاشتراك في حساب، لأنك بعد ذلك تحصل على تفاصيل شخصية لتوفيرها في وقت لاحق: يمكن إضافتهم إلى القائمة البريدية، ويكونون مؤهَّلين مسبقًا كعملاء مهتمين، وما إلى ذلك. يدرك العملاء ذلك ولا يعجبهم: في عام 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.

الأسباب

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