ब्लॉग पर वापस जाएँ

कई Target खातों के संचालन के लिए एनवायरनमेंट और डेटा की आवश्यकताएँ

Target खातों के बीच संबंध पहचानने के लिए डिवाइस विशेषताओं, भुगतान विधियों, शिपिंग पते और लॉगिन व्यवहार को देखता है। यह लेख बताता है कि ये संकेत कैसे साथ में देखे जाते हैं और एनवायरनमेंट व खाता डेटा को किन बातों पर खरा उतरना चाहिए।

Target, Walmart के बाद संयुक्त राज्य अमेरिका का दूसरा सबसे बड़ा रिटेल प्लेटफ़ॉर्म है और इसमें रोज़मर्रा का सामान, शिशु उत्पाद, कपड़े, इलेक्ट्रॉनिक्स और घरेलू उत्पाद शामिल हैं। बड़ा यूज़र बेस और स्थिर ट्रैफ़िक इसे कई सीमा-पार टीमों के लिए भी आकर्षक बनाते हैं जो अकाउंट संचालन तैयार करती हैं।

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

प्लेटफ़ॉर्म केवल खाता नहीं, बल्कि डिवाइस और ब्राउज़र विशेषताओं का पूरा समूह देखता है

Cookies इसका केवल एक हिस्सा हैं। ब्राउज़र द्वारा भेजी जाने वाली जानकारी में User-Agent, इंजन संस्करण, समय क्षेत्र और भाषा, ऑपरेटिंग सिस्टम, स्क्रीन रिज़ॉल्यूशन और इंस्टॉल किए गए फ़ॉन्ट की सूची भी शामिल होती है; ग्राफ़िक्स स्तर पर Canvas रेंडरिंग परिणाम, WebGL रिपोर्ट और GPU मॉडल होते हैं; स्टोरेज स्तर पर Cookies, LocalStorage और IndexedDB होते हैं। इन पैरामीटरों का संयोजन एक डिवाइस को दूसरे से अलग पहचानने के लिए पर्याप्त है।

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

तीन प्रमुख संकेत: भुगतान, पता और लॉगिन स्थान

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

लॉगिन स्थान एक और संकेत है। एग्ज़िट IP का क्षेत्र, नेटवर्क प्रदाता का प्रकार आवासीय है या डेटा सेंटर, और वह खाता-पंजीकरण क्षेत्र से मेल खाता है या नहीं—ये सभी मूल्यांकन का हिस्सा हो सकते हैं। कम समय में देशों के बीच तेज बदलाव और एक ही सबनेट से कई खातों का आना स्पष्ट संकेत हैं।

व्यवहार की गति भी रिकॉर्ड की जाती है। तुरंत क्लिक करना, हर बार एक ही क्लिक पथ अपनाना और पेज पर कोई ठहराव न होना सिस्टम में लगभग स्क्रिप्टेड गतिविधि जैसा दिख सकता है।

कई खातों को एक साथ जुड़ा हुआ क्यों माना जा सकता है

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

इसीलिए केवल एक बिंदु बदलने से खास लाभ नहीं होता। IP बदलने के बाद भी एनवायरनमेंट वही रहे, या डेटा बदलने के बावजूद पते की संरचना टेम्पलेट जैसी रहे, तो संबंध के संकेत बने रहते हैं।

एनवायरनमेंट स्तर पर सबसे जरूरी है कि कोई ओवरलैप न हो

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

PurpleMark जैसे टूल, जो विशेष रूप से मल्टी-अकाउंट एनवायरनमेंट आइसोलेशन के लिए बनाए गए हैं, इसी स्तर की समस्या को हल करते हैं। वे हर खाते का ब्राउज़र एनवायरनमेंट और नेटवर्क कॉन्फ़िगरेशन अलग रखते हैं, जिससे यह हाथ से याद रखने की जरूरत नहीं रहती कि कौन-सा कंप्यूटर किस खाते के लिए है।

नेटवर्क एग्ज़िट के बारे में एक और बात आसानी से छूट जाती है: उसका क्षेत्र और प्रकार लंबे समय तक स्थिर रहना चाहिए। एक खाता यदि लगातार उसी क्षेत्र का एग्ज़िट उपयोग करता है, तो वह बार-बार बदलने वाले खाते की तुलना में सामान्य यूज़र व्यवहार के अधिक करीब दिखता है। बड़े पैमाने पर पुनः उपयोग किए जाने वाले डेटा-सेंटर IP स्वयं ही उच्च जोखिम का संकेत होते हैं।

खाता डेटा वास्तविक इकाई से मेल खाना चाहिए

पंजीकरण डेटा की समस्या यह नहीं कि वह पर्याप्त रूप से यादृच्छिक है या नहीं, बल्कि यह है कि वह किसी वास्तविक इकाई से मेल खाता है या नहीं। यदि वही इकाई कई खातों में एक ही शिपिंग पता, भुगतान विधि या संपर्क जानकारी दोहराती है, तो लिखने का तरीका बदलने से संबंध समाप्त नहीं होता।

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

सामान्य संचालन की गति में स्वाभाविक रूप से बदलाव होता है

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

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

स्थिरता वास्तविक व्यवसाय से आती है

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