किसी डेटाबेस में अज्ञात/अतिथि उपयोगकर्ता के बारे में जानकारी संग्रहीत करने के तरीके क्या हैं?

Question

हमारे आवेदन में अन्य सुविधाओं के बीच एक ऑनलाइन दुकान है, और उपयोगकर्ताओं को सामान्य रूप से बिक्री पूरी करने से पहले पंजीकरण करने का अनुरोध किया जाता है, प्रक्रिया में एक अद्वितीय customer_ID बनाते हैं। जब वे वापस आते हैं, तो वे लॉग इन कर सकते हैं और उनके संपर्क विवरण और लेन-देन इतिहास डेटाबेस से पुनर्प्राप्त किए जाते हैं।

अब हम खोज रहे हैं कि 'अज्ञात' या 'अतिथि' ग्राहक के मामले में क्या करना है, उन ग्राहकों को ऑनलाइन दुकान खोलना जो पंजीकरण नहीं करना चाहते हैं, और बैकएंड एप्लिकेशन में बिक्री के लिए भी, जहां ग्राहक का ईमेल, डाक पता आदि लेना बहुत समय लगता है। समाधान में ऑनलाइन दुकान के बाहर भी एप्लिकेशन हैं।

एकाधिक कंपनियों में एक ही डेटाबेस का उपयोग, और डेटाबेस एक party model संरचना पर बनाया गया है, तो हमारे पास कुछ विकल्प का पता लगाया है: के तहत

1. स्टोर सभी अनाम ग्राहकों से एक पूर्व निर्धारित transaction तालिका में customer_ID:
   1. हर अनाम उपयोगकर्ता के लिए customer_ID = 0, और
      • हर वास्तविक उपयोगकर्ता यह मैं के लिए customer_ID > 0 आवेदन
      • लेकिन अधिक निर्धारित करने के लिए जो ग्राहकों जो कंपनी
      • चाहिए customer_ID = 0 के लिए विवरण डेटाबेस में या आवेदन में एक वस्तु के रूप customer तालिका में मौजूद के हैं शामिल में हार्ड-कोड के लिए सीधी-सपाट रहा है?
        • यदि डेटाबेस में, डेटाबेस-स्तर की बाधाओं को सुनिश्चित किया जा सकता है कि यह हमेशा मौजूद है?
        • तो डेटाबेस में नहीं, transaction.customer_ID से customer.customer_ID को तो विदेशी कुंजी की कमी अब काम
   2. customer_ID प्रत्येक कंपनी के लिए कुल बिक्री निर्धारित करने के लिए कंपनी party_ID
      • आसान रूप में ही है , आदि
      • इससे मामलों को भ्रमित कर दिया जाएगा क्योंकि ऐसा लगता है कि कंपनी अन्य अद्वितीय ग्राहकों की तुलना में अपना ग्राहक है
2. हर नई अज्ञात ग्राहक (प्रति सत्र)
   • क्या होगा यदि एक ही शारीरिक उपयोगकर्ता रिटर्न के लिए एक अनूठा customer_ID उत्पन्न? उसी प्रकार के डेटा को दोहराने वाले कई रिकॉर्ड होंगे; ईमेल, शिपिंग पता, आदि
3. एक ग्राहक
   • नहीं हमेशा विश्वसनीय के रूप में लोगों को कभी-कभी एक से अधिक ईमेल पते का उपयोग, या पुराने पते छोड़ने के लिए उल्लेख करने के लिए, इस तरह के ई-मेल पते के रूप में एक और अद्वितीय कुंजी, का प्रयोग करें पीछे।
   • क्या होगा यदि कोई ईमेल पता नहीं लिया गया है, जैसा दुकान की मंजिल, प्रो फॉर्मा चालान आदि पर मामला है?
4. कुछ अन्य स्टैक ओवरफ़्लो प्रेरित समाधान!

अलावा

# 2 और # 3 का एक संयोजन कहीं और सुझाव दिया गया है - प्रत्येक ग्राहक के लिए एक भी रिकॉर्ड स्टोर करने के लिए प्रयास, हर यात्रा के संबंध में ईमेल पता यदि संभव हो तो, या एक नया रिकॉर्ड का उपयोग कर अगर नहीं।

मैं कहना चाहिए कि हम जरूरत हर गुमनाम ग्राहक के लिए एक रिकॉर्ड स्टोर करने के लिए नहीं है, लेकिन यह सिर्फ लगता है कि संबंधपरक डेटाबेस संबंधों से निपटने के लिए बनाया गया था, तो एक शून्य या transaction में एक customer_ID होने तालिका जो वास्तविक ग्राहक रिकॉर्ड का संदर्भ नहीं देती है, केवल गलत लगता है ...

मुझे यह भी कहना चाहिए कि इस प्रश्न का उद्देश्य यह निर्धारित करना है कि 'आकस्मिक' लेन-देन रिकॉर्ड करने के लिए वास्तविक दुनिया समाधान क्या हैं, जहां कोई डाक पता नहीं है या ऑनलाइन पता लेनदेन के साथ ईमेल पता दिया गया है (एक सुपरमार्केट चेकआउट की कल्पना करें) जहां एक ईमेल पता और डाक पता दिया जाता है कि वे संग्रहीत हैं या नहीं।

अतीत में एसओ समुदाय का उपयोग किस समाधान से किया जाता है?

Answer 1

मान लें कि आप सभी ऑनलाइन आदेश के लिए एक ई-मेल एड्रेस की आवश्यकता होती है, तो आप प्रत्येक आदेश के पूरा होने पर हर ग्राहक के लिए एक अस्थायी खाता बना सकते हैं जब वे लॉग इन नहीं कर रहे हैं।

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

चूंकि आपके डेटाबेस में प्राथमिक कुंजी ग्राहक_आईडी है, इसलिए यदि वे पहले से ही डुप्लिकेट को रोकने के लिए कोड में हैं, तब तक उन्हें एक ही ई-मेल/पता/आदि के साथ नए खाते बनाना जारी नहीं रखना चाहिए। हालांकि किसी के लिए एक से अधिक अस्थायी खाता बनाने के लिए दुर्लभ है, क्योंकि उनके डेटा को दोबारा दर्ज करने से उन्हें पासवर्ड से लॉग इन करना आसान है।

बैकएंड ऑर्डर के लिए, हम आम तौर पर प्रत्येक ग्राहक के लिए उपरोक्त खाते में एक खाता बनाते हैं। हालांकि, अगर उनके पास कोई ई-मेल पता नहीं है (या वे केवल फोन द्वारा खरीदना चाहते हैं), तो हम उनकी शिपिंग जानकारी और एक खाली ई-मेल पता के साथ एक खाता उत्पन्न करते हैं (अस्थायी पासवर्ड न भेजने के लिए अपवाद को कोड करना होगा/रिक्त होने पर ऑर्डर पुष्टिकरण)। ग्राहक_आईडी उन्हें दिया जाता है, और भविष्य में आदेशों को देखने और तेज़ करने के लिए उनकी शिपिंग जानकारी और कंपनी का नाम खाते में संग्रहीत किया जाता है।

Answer 2

मैं आमतौर पर उपयोगकर्ता आईपी का उपयोग करता हूं, मैं केवल एक आईडी और उसके आईपी पते के साथ खाता बनाता हूं। जब वह पंजीकरण करता है, तो मैं बस अपना रिकॉर्ड अपडेट करता हूं। आईपी ​​की तुलना में अन्य चीजें भी (और चाहिए) का उपयोग भी किया जा सकता है, जैसे कुकी में डालने के लिए एक यादृच्छिक टोकन बनाने के लिए किसी भी सत्र प्रणाली को बाईपास करने के लिए ताकि आप इसे उदाहरण के लिए लंबे समय तक बना सकें।

अब, एप्लिकेशन में, आपको अपने उपयोगकर्ता वर्ग को अपने आईपी/टोकन, वास्तविक सत्र या किसी भी अन्य लॉगिन सिस्टम के साथ "उपयोगकर्ताओं" को पहचानने में सक्षम होना चाहिए।

Answer 3

मुझे संदेह है कि इस समस्या के लिए कोई सही समाधान है। आपको बस एक विकल्प बनाना होगा: एक ग्राहक को पूर्ण पंजीकरण प्रक्रिया के माध्यम से जाने के लिए मजबूर नहीं होने वाले रूपांतरणों में सुधार के विपरीत पहचानने योग्य ग्राहक इतिहास की गारंटी देना कितना महत्वपूर्ण है।

यदि आप पंजीकरण को मजबूर किए बिना जाते हैं, तो आप वापस आने वाले ग्राहकों को 100% समय पहचानने में सक्षम नहीं होंगे। कोई तर्क दे सकता है कि पंजीकरण के साथ भी संभव नहीं होगा, क्योंकि उपयोगकर्ता कभी-कभी विभिन्न कारणों से नए खाते बनाने का विकल्प चुनते हैं। लेकिन हो सकता है कि आप ऐसा कुछ कर सकें जो आपके पास पहले से मौजूद डेटा को समझकर "पर्याप्त" है।

उदाहरण के लिए, कुछ देशों में, पोस्टकोड काफी विशिष्ट हैं। क्या वे पर्याप्त विशिष्ट हैं? निर्भर करता है कि आप किन देशों को संचालित करते हैं और यह भी कि आपका ग्राहक आधार कैसे बनाया गया है। यदि आपके पास केवल प्रति उपयोगकर्ता एक उपयोगकर्ता है, तो हो सकता है।

या जो के आधार पर भुगतान विधियां समर्थन करते हैं, आप क्रेडिट कार्ड नंबर ("छद्म अद्वितीय ID") की एक एक तरह से हैश के निर्माण पर विचार हो सकता है। कुछ भुगतान समाधान वास्तव में एक अद्वितीय "भुगतानकर्ता आईडी" वापस करते हैं, जो कि सही हो सकता है - यह मानते हुए कि आपको उन सभी भुगतान सेवाओं से कुछ मिलता है जो आप समर्थन करते हैं।

Answer 4

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

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

यदि आप ऐसा नहीं करना चाहते हैं, तो कुकी सेट करना संभव है, हालांकि यदि आप ईयू (कुकी कानून) के भीतर से व्यापार कर रहे हैं तो आपको उपयोगकर्ता को चेतावनी देना होगा।

किसी व्यक्ति के साथ अलग-अलग ईमेल पते और डाक पते वाले समस्या यह हो सकती है कि वे व्यवसाय के लिए आदेश दें, फिर वे व्यक्तिगत उपयोग के लिए आदेश दे सकते हैं (कहना मुश्किल है क्योंकि हम नहीं जानते कि आप क्या बेच रहे हैं)।

Answer 5

चिंता आप कुकीज़ का उपयोग करके बिक्री सत्र को ट्रैक कर सकते हैं। लेकिन अज्ञात उपयोगकर्ताओं को अपनी साइट पर भी पंजीकृत करें लेकिन उन्हें यह एहसास न करें कि वे कोई पंजीकरण फॉर्म भर रहे हैं। उन्हें बिक्री प्रक्रिया का पालन करें और बिक्री प्रक्रिया के अंत में एक अद्वितीय ग्राहक आईडी उत्पन्न करें और उन्हें ईमेल करें और उस अधिसूचना को प्रदर्शित करें साइट पर अपनी बिक्री पूरी करने के बाद और उन्हें अपनी ग्राहक आईडी दर्ज करके साइट में लॉगिन करें।

Answer 6

जिस तरह से मैं यह करता हूं: बिलकुल नहीं।

बस शब्दों में कहें, लोगों को पेपैल के माध्यम से भुगतान करें या जो कुछ भी आप भुगतान समाधान के रूप में डालते हैं और वहां से डेटा प्राप्त करते हैं, स्वचालित रूप से उपयोगकर्ता को प्रदान करते हैं और प्रदान किए गए API का उपयोग करके भुगतान संसाधित होने के बाद आदेश बनाते हैं।

उस बिंदु पर आपके पास आवश्यक सभी जानकारी है और निश्चित रूप से आपके आंकड़े/ई-स्पैम मार्केटिंग के लिए पर्याप्त रूप से स्टोर कर सकती है।

इसे सरल रखें, कुछ भी नहीं, लोगों को ग्राहक आईडी या ई-मेल दर्ज करने की आवश्यकता नहीं है, और वे सभी इसे पसंद करेंगे।

ऐसा करना कि मेरे पास अभी भी हर जानकारी है जिसमें मुझे रूचि हो सकती है और उपयोगकर्ता अनुभव जितना तेज़/आसान हो सकता है।

Answer 7

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

Answer 8

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

लेकिन सभी गंभीरता में, जब तक आपकी संख्या में आईड्स सैकड़ों हजारों में नहीं मिल रहा है (और यदि यह है तो बधाई हो!), यह तब तक आपके डेटाबेस को चोट पहुंचाने वाला नहीं है जब तक आपके पास उचित इंडेक्स नहीं है ग्राहक आईडी कॉलम।

यदि आपके पास प्रत्येक ग्राहक के लिए आईडी = 0 था तो आपके पास उतनी ही पंक्तियां नहीं होंगी? मुझे लगता है कि अगर आप सभी डेटा रखना चाहते हैं, तो यह अनावश्यक है? शून्य आईडी आपकी अनुक्रमणिका को अतिरिक्त समस्याएं भी दे सकती है।