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

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

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

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

आइए, हम ऊपर बताए गए तरीकों के बारे में बात करते हैं. इन्हें अपनाकर, हम आपके कारोबार के लिए सबसे असरदार (लेकिन आपके कारोबार पर भी सबसे ज़्यादा असर डालने वाले) आएंगे. साथ ही, इन तरीकों को लागू करेंगे, ताकि आपके तरीके में कमी न हो.

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

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

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

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

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

उदाहरण

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

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

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

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

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

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

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

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

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

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

ऐसा क्यों करें

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