सिर्फ़ उस डेटा का इस्तेमाल करें जिसकी आपको ज़रूरत है

उपयोगकर्ताओं को होने वाले जोखिम को कम करने का एक अच्छा तरीका यह है कि अपने पास ऐसी कोई संवेदनशील जानकारी न रखें जिसकी आपको ज़रूरत न हो और जिससे उनकी निजता पर असर पड़ता हो. अपने कारोबार के लक्ष्यों को पूरा करने के साथ-साथ, ऐसा कई तरीकों से किया जा सकता है और हर तरीके के बारे में सोचें. ये काम किए जा सकते हैं:

• बताएं कि आपको किसलिए डेटा की ज़रूरत है.
• कम जानकारी के साथ डेटा इकट्ठा करें.
• इस्तेमाल हो जाने के बाद डेटा हटा दें.
• पहली जगह में यह जानकारी इकट्ठा न करें.

इनमें से हर एक तरीका इस्तेमाल करने से आपके उपयोगकर्ता सहज महसूस कर सकते हैं कि आप क्या कर रहे हैं और क्यों कर रहे हैं. इसमें हमें काफ़ी योगदान मिलेगा उनके साथ आपके संबंध को कैसे बेहतर बना सकता है. पारदर्शिता से आप पर भरोसा बढ़ता है. खास तौर पर, भरोसा आपके लिए बिक्री का खास ज़रिया हो सकता है. कई लोग यह मानकर चलते हैं कि डिफ़ॉल्ट रूप से उपयोगकर्ता और ग्राहक उन पर भरोसा करते हैं, लेकिन उपभोक्ता लगातार प्रॉडक्ट और सेवाओं का आकलन करते रहते हैं. इस वजह से ऐसा नहीं होता. अगर उपयोगकर्ताओं के साथ आपके ऐसे संबंध हैं जहां वे अपने डेटा और आपके इंटरैक्शन को मैनेज करने के लिए आप पर भरोसा करते हैं, तो सम्मान के साथ, यह आपको एक प्रोजेक्ट या व्यवसाय के रूप में एक प्रतिस्पर्धी लाभ दे सकता है: यह कुछ ऐसा है जो आपके प्रतिद्वंद्वी शायद जो दूसरों से अलग है.

चलिए, ऊपर दिए गए तरीकों के बारे में जानते हैं. हम ऐसा इसलिए करते हैं, ताकि आपके कारोबार के लिए सबसे असरदार (लेकिन आपके कारोबार के लिए सबसे असरदार) से लेकर सबसे कम असरदार तरीके तक हो सके लेकिन इसे लागू करने में बहुत कम रुकावट आती है.

इसे पहले जगह पर इकट्ठा न करें

अपने उपयोगकर्ताओं से समझौता करने से बचने का सबसे आसान तरीका डेटा को इकट्ठा न किया जाए. सेवाएं देने के लिए, कुछ डेटा इकट्ठा करना ज़रूरी है. हालाँकि, कई ऐसी जगहें हैं जहां डेटा इकट्ठा करने से बचा जा सकता है. उदाहरण के लिए, लॉग इन किए बिना खरीदारी करने पर ध्यान दें. जब उपयोगकर्ता आपके वेब ऐप्लिकेशन से कुछ खरीदने के लिए आते हैं, तो आपको उन्हें किसी खाते के लिए साइन अप करने के लिए कहना पड़ सकता है, क्योंकि तब आपने बाद में ऑर्डर भेजने के लिए निजी जानकारी इकट्ठा की हो: उसे ईमेल पाने वाले लोगों की सूची में जोड़ा जा सकता हो और वे पहले से ही मंज़ूरी पा चुके हों दिलचस्पी है, वगैरह. हालांकि, ग्राहक इसे समझते हैं और इसे पसंद नहीं करते हैं: साल 2021 में की गई एक स्टडी के मुताबिक, चार में से एक बिक्री साइट ने उपयोगकर्ता से एक खाता बनाने की मांग की हो. अगर आपको किसी खाते की ज़रूरत नहीं है, तो संभावना है कि आप उन ग्राहकों को अपने साथ बनाए रखें. साइन अप किए बिना खरीदारी पूरी करने की सुविधा का इस्तेमाल करने पर, आपको उपयोगकर्ता को बेहतर विकल्प मिलते हैं. साथ ही, यह भी इसका मतलब है कि आपके पास उनकी सुरक्षा के लिए ज़्यादा डेटा नहीं होता है.

"फ़ज़" आपका डेटा

बेशक, डेटा इकट्ठा करने से बचना ज़रूरी नहीं है. सेवाएं देने और उन्हें बेहतर बनाने के लिए, डेटा इकट्ठा करना ज़रूरी है के बारे में सोच-समझकर फ़ैसले लेते हैं. यह एक भरोसेमंद रिश्ते के मामले में मार्केटिंग से जुड़ी बातचीत को तैयार करने में भी मदद कर सकता है. हालांकि, यह समझना भी ज़रूरी है कि कुल मिलाकर लिए गए फ़ैसले (जिससे कई उपयोगकर्ताओं पर एक साथ असर पड़ता हो) वे ही लिए जाते हैं पूरे डेटा के बारे में जानकारी देता है (यानी डेटा की सामूहिक प्रॉपर्टी के बारे में).

उदाहरण के लिए, कभी-कभी अपने दर्शकों की डेमोग्राफ़िक्स (उम्र, लिंग, आय, शिक्षा वगैरह) के बारे में जानकारी हासिल करना फ़ायदेमंद हो सकता है: वे किस उम्र समूह में आते हैं, स्थान वगैरह. इससे आपकी मैसेज सेवा या आपके काम करने का तरीका बदल सकता है. हालांकि, इसका यह मतलब नहीं है कि आपको उम्र की पुष्टि करने के लिए किया जा सकता है. आम तौर पर, आपको रुझान और कुल प्रॉपर्टी के बारे में जानकारी मिलती है. अगर आपको यह फ़ैसला लेना है कि विज्ञापन की पहुंच पर इस बात से असर पड़ता है कि क्या आपकी ज़्यादातर ऑडियंस "18 से 34 की डेमोग्राफ़िक (उम्र, लिंग, आय, शिक्षा वगैरह)" में शामिल है. ऐसे में, आपके लिए सिर्फ़ एक सवाल होना ज़रूरी है यह भी पता करना चाहिए कि आपके उपयोगकर्ता उस डेमोग्राफ़िक (उम्र, लिंग, आय, शिक्षा वगैरह) में हैं या नहीं. इससे वे उन्हें दो "बकेट" में इकट्ठा करते हैं: उस ग्रुप में, न कि उस ग्रुप में. कुछ मामलों में, आपको ज़्यादा जानकारी वाले डेटा की ज़रूरत पड़ सकती है. हालांकि, डेमोग्राफ़िक्स (उम्र, लिंग, आय, शिक्षा वगैरह) की सूची लेना सही होगा की मदद से फ़ैसला लिया जा सकता है और अपने उपयोगकर्ताओं से कहा जाता है कि वे उस सूची के हिसाब से उन चीज़ों की कैटगरी तय करें.

उदाहरण

इसलिए, अगर यह जानने से मदद मिलती है कि आपका उपयोगकर्ता आधार "18-34", "35-49", "49-64", और "65+" उम्र वाली कैटगरी के बीच किस तरह बंटा है, तो अपने उपयोगकर्ताओं से यह चुनने के लिए कहा जा सकता है कि वे इनमें से किस कैटगरी में आते हैं. बहुत ज़्यादा जानकारी वाला अनुरोध करने में मन लगता है, उपयोगकर्ता के निजी और मनमुताबिक डेटा इकट्ठा कर सकते हैं. इसके बाद, वे खुद ही अपने उपयोगकर्ताओं की कैटगरी तय कर सकते हैं. ऐसा इसलिए, क्योंकि इससे आपको वही सवाल फिर से पूछने की ज़रूरत नहीं पड़ती ज़्यादा जानकारी बाद में; उदाहरण के लिए, सही उम्र और जन्म की तारीख जानने के लिए, और फिर इसका इस्तेमाल कई उपयोगकर्ता "35-49" श्रेणी. हालांकि, यह समझना ज़रूरी है कि यह फ़ॉर्मैट कैसा दिखता है: क्योंकि इस कोर्स में पहले ही सभी विषय शामिल किए जा चुके हैं और फिर से कवर करेगा, डेटा का पूरा ब्यौरा मांगने से लोग असहज महसूस कर सकते हैं और इस वजह से आपके संगठन में उपयोगकर्ता का भरोसा भी कम होता है, और जोखिम भी जोड़ते हैं.

साथ ही, अपने डेटा से जुड़ी ज़रूरतों को ध्यान में रखना भी ज़रूरी है. कभी-कभी, "ज़रूरत" ज़्यादा जानकारी के लिए, डेटा अनुमान पर आधारित है, "स्थितियों में" ज़रूरी है. शायद हमें अभी उपयोगकर्ताओं को उन चार आयु समूहों में ही वर्गीकृत करना है, लेकिन भविष्य में शायद हम उसे सीमित कर दें. इसलिए, हमें अभी काफ़ी जानकारी वाला डेटा इकट्ठा करना होगा, ताकि बाद में उस विकल्प को खुला रखा जा सके. यह फ़ायदेमंद हो सकता है इस बात पर ध्यान देना कि फ़ैसले लेने के लिए, ज़्यादा जानकारी वाले डेटा का इस्तेमाल कितनी बार किया गया है. ऐसे डेटा के लिए पूछना को दी जा रही सेवा की तुलना में आक्रामक माना जाता है. इसका नतीजा यह होता है कि इससे उपयोगकर्ताओं को आपके कारोबार पर भरोसा करने में संगठन. अगर डेटा को “सिर्फ़ ज़रूरत के हिसाब से” वजहों से इकट्ठा किया जा रहा है, तो हो सकता है कि आप उपयोगकर्ता के भरोसे को भूल न जाएं जिससे आगे के लिए तय सैद्धांतिक तौर पर फ़ैसला लेने की संभावना होती है. उस जानकारी की सुरक्षा से जुड़ी ज़रूरतों को पूरा करने के साथ-साथ, उस जानकारी का मौजूद न हो.

इकट्ठा किए गए डेटा की जानकारी का स्तर कम करने के लिए, ज़्यादा जानकारी वाले एल्गोरिदम भी हैं. किसी भी क्रम में जवाब देने के तरीके इसका मतलब है कि डेटा को कई सटीक तरीकों से इकट्ठा किया जाता है. साथ ही, इनका इस्तेमाल दशकों से संभावित घुसपैठ या संवेदनशील डेटा को इकट्ठा करते समय, जवाब देने वाले व्यक्ति की गोपनीयता को बनाए रखते हुए, विज्ञान के बारे में ज़्यादा जानें. कॉन्टेंट बनाने डेटा इकट्ठा करने का ऊपर दिया गया तरीका इस्तेमाल करने पर, ज़्यादा उपयोगकर्ताओं के जवाबों का दायरा बढ़ाना होता है (इसलिए, "आपकी उम्र क्या है" "आप इनमें से किस उम्र समूह में आते हैं"), जहां बिना किसी क्रम के दिए गए जवाब का एक खास अनुपात होता है लोग अपने जवाबों के बारे में झूठ बोलते हैं. अगर गलत जवाब देने वाले उपयोगकर्ताओं के अनुपात के बारे में आपको पता है, तो सही नतीजे मिलेंगे भी इकट्ठा किए गए डेटा से लिया जा सकता है, लेकिन किसी उपयोगकर्ता की निजता से छेड़छाड़ नहीं की जाती. इसकी वजह यह है कि इकट्ठा किया गया डेटा जानकारी गलत हो. इस मामले में, अगर आपकी 80% ऑडियंस अब भी कहती है कि वे 18 से 34 की उम्र, लिंग, आय, शिक्षा वगैरह में आते हैं, तो उन्हें इस बात पर भरोसा होता है कि अब भी इसी हिस्से में सबसे ज़्यादा योगदान है, भले ही उनमें से 10% लोग जान-बूझकर गलत जवाब दे रहे हों. गलत जवाबों की सीमा को प्रोग्राम के हिसाब से भी बदला जा सकता है. ऐसा इसलिए किया जा सकता है, जब हमेशा सही जवाबों की मांग की जाती हो, लेकिन ट्रांसमिट करने से पहले सॉफ़्टवेयर, जवाबों के कुछ प्रतिशत में बदलाव कर देता है. यह प्रक्रिया और इसके नतीजे डेटा इकट्ठा किए जाने पर उपयोगकर्ताओं को बताया जाना चाहिए: इसका मतलब है कि उपयोगकर्ताओं को यह भरोसा नहीं है कि आप उनका गलत इस्तेमाल नहीं करेंगे क्योंकि अलग-अलग डेटा पर भरोसा नहीं किया जा सकता.

ऐसी ही एक ऐसी प्रोसेस है जिसमें तकनीकी तौर पर भी डिफ़रेंशियल प्राइवसी शामिल होती है. इसमें गणित की तकनीकों का इस्तेमाल करके, डेटा के स्टोरेज में बदलाव किया जाता है, ताकि डेटा की एग्रीगेट प्रॉपर्टी मौजूद रहे. हालांकि, यहां तक कि यह भी नहीं बताया जा सकता कि किसी व्यक्ति ने कौनसा डेटा उपलब्ध कराया था या कौनसा डेटा उपलब्ध कराया था. किसी भी क्रम में मिलने वाले जवाब की तरह ही, यह उपयोगकर्ताओं को आपके पास मौजूद डेटा भी शामिल नहीं किया जाएगा और वह आपके मकसद को साफ़ तौर पर दिखाता है: आप अपने उपयोगकर्ताओं की का इस्तेमाल करें.

इन तरीकों और इस तरह के दूसरे तरीकों से, डेटा के गलत इस्तेमाल और लीक होने के मामलों से सुरक्षा भी बढ़ती है, क्योंकि इकट्ठा किया गया डेटा इससे उपयोगकर्ता की निजता को लेकर किसी तरह के खतरे को कम किया जाता है. यहां तक कि आप पर भी इसका असर नहीं पड़ता. साथ ही, अगर डेटा लीक हो जाता है, तो उसकी निजता को भी नुकसान नहीं पहुंचता है. हालांकि, याद रखें कि अगर सर्वर पर डिफ़रेंशियल प्राइवसी तकनीकें लागू की जा रही हैं, ताकि आपके उपयोगकर्ता आपको एग्रीगेट नहीं किया गया डेटा है और फिर उसे एग्रीगेट करने के लिए तकनीकों का इस्तेमाल किया जाता है), तब भी आपको उपयोगकर्ता के उस रॉ डेटा को सुरक्षित रखना होगा और फिर उसे प्रोसेस करने के बाद मिटा दें. साथ ही, नीतियों के मुताबिक साफ़ तौर पर यह पुष्टि की जा सकती है कि इसे पहले इस्तेमाल नहीं किया जा रहा है एग्रीगेशन (या साफ़ तौर पर बताएं कि इसका इस्तेमाल किस काम के लिए किया जा रहा है).

निजी डेटा का रखरखाव: डेटा इकट्ठा करें और इस्तेमाल किए जाने के बाद उसे हटा दें

याद रखें कि इकट्ठा किए गए डेटा का एक लाइफ़साइकल होता है; जानकारी इकट्ठा की जाती है. इसके इस्तेमाल से आपको कारोबार से जुड़े फ़ैसले लेने में मदद मिलती है. और फिर, कुछ समय पर इसे हटा दिया जाना चाहिए. एक बार फिर, ये फ़ायदे भी हैं: उपयोगकर्ताओं से सवाल पूछने पर या उनके द्वारा देखी गई अन्य वेबसाइटों की जानकारी स्टोर करते हैं या आप यह ट्रैक करते हैं कि उन्होंने किन चीज़ों को देखा और कितनी देर तक देखा यह वह डेटा होता है जो आपको किसी खास मकसद से दिया जाता है, न कि डेवलपर को अपनी ज़रूरत के हिसाब से इस्तेमाल करने के लिए, विस्तार से अनुमति दी जाती है. जब उस काम के लिए डेटा की अब ज़रूरत न हो-कभी-कभी एक मिनट के बाद, कभी-कभी कई सालों के बाद, आपको इसे मिटा देना चाहिए.

जब भी आप अपने उपयोगकर्ताओं के बारे में जानकारी इकट्ठा करें, तो आपको यह पता होना चाहिए कि आप डेटा का इस्तेमाल किस काम के लिए करेंगे (नीचे देखें) और आपको यह भी जानें कि आपका डेटा कब और क्यों बंद करना होगा. ऐसा तब हो सकता है, जब उपयोगकर्ता इसे मिटाने का विकल्प चुनता है या जब वे साइन इन करते हैं किसी ख़ास समयावधि के बाद या किसी इवेंट के होने के बाद. रिश्ते में भरोसा जीतने का शानदार तरीका इससे अपने उपयोगकर्ताओं को साफ़ तौर पर यह बताया जाता है कि वे अपने डेटा को कैसे कंट्रोल कर सकते हैं. इसमें जहां भी मुमकिन हो, एकतरफ़ा ऑप्ट-आउट शामिल है. वह अपना डेटा कैसे मिटाता है? वह अपना खाता कैसे मिटाता है? वह रिश्ता बनाने में मदद करने के अलावा, डेटा को तब तक सेव करके रखें, जब तक कि आपको उसे प्रोसेस करना हो और न कि लंबे समय तक. साथ ही, यह भी ज़रूरी है कि आपके उपयोगकर्ता ऐसा कर सकें उस डेटा को देख और हटा सकता है जिसे आपने कंपनी या उनकी तरफ़ से इकट्ठा किया है. ऐसा हो सकता है कि इन देशों/इलाकों में, इस मुद्दे से जुड़ा कानून जिसे आप ऑपरेट करते हैं.

इससे साफ़ तौर पर तकनीकी लक्ष्य तय किए जा सकते हैं. इससे उपयोगकर्ताओं को सेल्फ़-सर्विस करने में मदद मिलती है; अगर आपके उपयोगकर्ता ऑप्ट आउट कर सकते हैं बिना अनुमति के डेटा वेयरहाउस से ऑप्ट-इन करके, वे ज़्यादा सहज महसूस कर सकते हैं और उन्हें इसके लिए, किसी सहायता संसाधन की मदद लें.

आसान और डिफ़ॉल्ट ऑप्ट आउट की अहमियत को समझना ज़रूरी है: "भरोसा और पहचान बनाने के लिए, कंपनियां शुरुआत करने के लिए एक सामाजिक अनुबंध पर सहमति दें, जहां वे हर टचपॉइंट पर अपने दर्शकों का सम्मान करें, IAPP से जुड़े. Nielsen नॉर्मन ग्रुप का कहना है कि उपयोगकर्ताओं को "खास तौर पर, 'आपातकालीन निकास' इसके बाद, अनचाही कार्रवाई को हटाने के लिए, लंबी प्रोसेस को पूरा करने की ज़रूरत नहीं होती". हर किसी को पता है कि यह सदस्यता छोड़ने से ज़्यादा आसान होते हैं. हालांकि, जैसा कि नीलसन नॉर्मन कहते हैं, उपयोगकर्ताओं को आगे बढ़ें, "आज़ाद और आत्मविश्वास की भावना को बढ़ावा दें". अकादमिक अध्ययनों ने इसे मज़बूत बनाया है और इसे "सिद्धांत रद्द करने की क्षमता" के मुताबिक: "इंटरफ़ेस से उपयोगकर्ता को उन संस्थाओं को आसानी से रद्द करने की सुविधा मिलनी चाहिए जिन्हें उपयोगकर्ता ने कहीं भी अनुमति दी है रद्द किया जा सकता है. उपयोगकर्ताओं के पास, इस तरह की सहमति को रद्द करने का विकल्प होना चाहिए. इसका मतलब यह है कि उनके पास संसाधनों को ऐक्सेस करने के अधिकार कम हैं का इस्तेमाल करें." उदाहरण के लिए, Yee और Iacono देखें.

डेटा को कितने समय तक और किस डेटा को सेव करके रखा जाए, यह एक ऐसा विषय है जो संगठनों और हालाँकि, कुछ सामान्य दिशा-निर्देशों का पालन किया जा सकता है.

यह करें

उपयोगकर्ताओं को खाते (और कोई भी संबंधित डेटा, जहां ऐसा किया जा सकता है) मिटाने और नियमित रूप से (उदाहरण के लिए, साइन आउट करने पर) करने की अनुमति देना यहां फ़ायदेमंद है Clear-Site-Data हेडर से, साइन आउट करने पर, कुछ समय के लिए सेव किया गया और डिवाइस पर सेव किया गया डेटा मिटाएं.

क्लाइंट-साइड से सेव किए गए, उपयोगकर्ता के कुछ या पूरे डेटा को हटाने के लिए, Clear-Site-Data हेडर डालें. इससे कोई फ़र्क़ नहीं पड़ता है कि वह डेटा, कुकी, localStorage या IndexedDB या ब्राउज़र की कैश मेमोरी में सेव किया जा सकता है. किसी उपयोगकर्ता ने साइट के डेटा को लॉग आउट कर जाता है, लेकिन सुरक्षा से जुड़ी घटनाओं के बाद भी इसका इस्तेमाल किया जा सकता है. इससे यह पक्का किया जा सकता है कि जिस खाते के साथ छेड़छाड़ की जा सकती है उसमें कोई बचा हुआ खाता तो नहीं है को स्टोर किया गया है.

Clear-Site-Data के लिए सहायता जोड़ने में, उपयोगकर्ता के साइन आउट करने पर या किसी दूसरे डिवाइस पर, एचटीटीपी हेडर Clear-Site-Data भेजना शामिल है कितनी बार आपको क्लाइंट-साइड स्टोरेज खाली करना है. यह जानकारी, लॉग आउट होने की स्थिति (https://your-site/logout) की पुष्टि करने वाले पेज पर दिखती है या इससे मिलता-जुलता). इस हेडर में, इनमें से कुछ या सभी वैल्यू या सभी के लिए "*" हो सकता है:

Clear-Site-Data: "cache", "cookies", "storage"

ये वैल्यू कैश मेमोरी में सेव किए गए पेजों और एचटीटीपी से कैश मेमोरी में सेव किए गए अन्य रिसॉर्स, स्टोर की गई कुकी, localStorage और IndexedDB वगैरह से जुड़ी जानकारी को साफ़ करती हैं. आपको किसी अन्य विकल्प, executionContexts का रेफ़रंस दिख सकता है. हालांकि, यह कई ब्राउज़र पर काम नहीं करता. ध्यान दें कि खुद बनाए गए सभी संसाधनों को अलग-अलग मिटाने के बजाय, Clear-Site-Data हेडर का इस्तेमाल करना ज़्यादा आसान होता है. ऐसा इसलिए, क्योंकि इसके लिए JavaScript कोड की ज़रूरत नहीं होती क्लाइंट पर चलाया जाता है (और ब्राउज़र की कैश मेमोरी को मिटाने का यही एक आधिकारिक तरीका है), लेकिन यह सभी ब्राउज़र पर काम नहीं करता.

उपयोग नोट: अगर आप कैश मेमोरी मिटा रहे हैं (Clear-Site-Data: cache भेजकर), तो Clear-Site-Data हेडर अपने असल साइन-आउट पेज पर भेजा जाता है, लेकिन किसी दूसरे रिसॉर्स पर पेज लोड होता है. ऐसा इसलिए होता है, क्योंकि कंप्यूटर धीमा होने पर अगर कैश मेमोरी ज़्यादा है, तो कैश मेमोरी हटाने तक पेज ब्लॉक हो जाएगा और इस वजह से नेविगेशन नहीं हो पाएगा. इसमें कुछ मिनट लग सकते हैं, जिससे उपयोगकर्ता को निराशा होगी. ऐसा होने की संभावना नहीं है, लेकिन इसका टेस्ट करना मुश्किल है. इसलिए, इसे ध्यान में रखना सबसे सही तरीका है.

बताएं कि आपको किस चीज़ के लिए डेटा की ज़रूरत है

आपके उपयोगकर्ताओं की विश्वसनीयता की अहमियत आपकी सेवा के साथ संबंध बार-बार बताया गया है, क्योंकि इससे उपयोगकर्ता लंबे समय तक काम करता है. इससे प्रतिस्पर्धी लाभ भी मिलता है. उस स्तर का भरोसा बढ़ाने का एक तरीका यह है कि अपनी प्रोसेस में पारदर्शिता रखें और तो साफ़ तौर पर यह बताएं कि आपको किस काम के लिए डेटा चाहिए. आपने पहले सीखा था कि इकट्ठा की गई हर चीज़ के बारे में आपको पता होना चाहिए कब मिटाया जाएगा. यह जानने के लिए, आपको यह जानना होगा कि आपको यह डेटा क्यों चाहिए और किन सवालों में यह डेटा चाहिए साथ ही, जवाब इकट्ठा करके कौन-कौनसे फ़ैसले लिए जा सकते हैं. यह जानने के बाद कि आपको इस डेटा की ज़रूरत क्यों है उसके बारे में पूछने के लिए . आपकी निजता नीति में या खाते पर सवाल पूछते समय बताएं कि आपको इस सवाल का जवाब क्यों चाहिए, इस डेटा का इस्तेमाल कैसे किया जाएगा, और इसे कब और कैसे हटाया जा सकता है.

ये एक्सप्लेनेशंस ज़्यादा बेहतर तरीके से तब दिखते हैं, जब इन्हें इनलाइन दिखाया जाता है. वेबसाइट पर किसी और जगह पर, नीति से जुड़े बड़े दस्तावेज़ में एक्सप्लेनेशंस को शामिल करना उन्हें छिपाने की कोशिश की जा सकती है. साइन-अप, चेकआउट या अनुरोध फ़ॉर्म में, कलेक्शन के साथ डेटा इकट्ठा करने की वजहें बताई जा सकती हैं वह भी ऐसा कर सकता है. अक्सर, फ़ॉर्म फ़ील्ड में तारे का निशान (*) हो सकता है. इससे पता चलता है कि किसी फ़ील्ड की ज़रूरत है; मुश्किल फ़ॉर्म में अक्सर जानकारी का लिंक होता है (i) फ़ील्ड का मतलब समझाने के लिए. इन जानकारी में यह जानकारी जोड़ें कि डेटा क्यों इकट्ठा किया जा रहा है. अक्सर वाक्यांश का इस्तेमाल किया गया है यह है: "हमें इसकी ज़रूरत क्यों है?" इस फ़ॉर्म पर क्लिक करने पर, एक पॉप-अप जानकारी दिखती है.

एचटीएमएल के कुछ उदाहरण इस तरह दिख सकते हैं. इसके बाद, सीएसएस और 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 हेडर का इस्तेमाल करके, उपयोगकर्ताओं को अपने बनाए गए खाते मिटाने और डिवाइस के स्टोरेज में सेव किया गया डेटा मिटाने की अनुमति दें.

क्यों

अपने उपयोगकर्ताओं के साथ एक रिश्ता बनाने का मतलब उनके भरोसे को कायम रखना है. साथ ही, भरोसा जीतने का मतलब है उन्हें सबके साथ जुड़ना. अगर आप यह दिखा सकें कि आप हम उपयोगकर्ताओं का ज़्यादा से ज़्यादा डेटा इकट्ठा करते हैं और इसके इस्तेमाल को छिपाते हैं. इससे उनका भरोसा जीतने में मदद मिलती है. ज़्यादा ईमानदार मुकाबला करने वालों के मुकाबले आपको ज़्यादा फ़ायदा होगा.