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

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

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

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

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

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

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

अपने डेटा को "फ़ज़" करना

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

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

उदाहरण

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

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

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

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

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

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

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

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

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

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

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

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

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

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

क्यों

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