क्रॉस-डिवाइस ट्रैकिंग: बिना लॉगिन के सेशन जोड़ना

जब कोई उपयोगकर्ता सुबह अपने लैपटॉप पर और दोपहर में अपने फोन पर आपकी साइट देखता है, तो अधिकांश analytics प्लेटफॉर्म दो पूरी तरह अलग visitors देखते हैं। हमारा device identification एल्गोरिदम signal overlap का विश्लेषण करके और device graphs बनाकर इन सेशनों को probabilistic ढंग से — बिना लॉगिन की आवश्यकता के — जोड़ सकता है।

क्रॉस-डिवाइस समस्या

पारंपरिक fingerprinting हर ब्राउज़र इंस्टेंस के लिए एक अलग ID बनाती है। लैपटॉप पर Chrome एक ID बनाता है; iPhone पर Safari दूसरा। एक ही डिवाइस पर भी अलग-अलग ब्राउज़र अलग-अलग fingerprint बनाते हैं, क्योंकि उनके user agent अलग होते हैं, feature support अलग होता है, और rendering की विशेषताएँ अलग होती हैं।

लेकिन उपयोगकर्ता ब्राउज़रों के रूप में नहीं सोचते। वे सेशनों के रूप में सोचते हैं। वे लंच के दौरान अपने फोन पर खरीद शुरू करते हैं और घर पर अपने लैपटॉप पर उसे पूरा करते हैं। वे अपने टैबलेट पर किसी उत्पाद पर शोध करते हैं और अपने डेस्कटॉप पर उसे खरीदते हैं। fraud detection और personalization के लिए यह समझना महत्वपूर्ण है कि ये सेशन एक ही व्यक्ति के हैं।

Probabilistic Signal Matching

हमारी क्रॉस-डिवाइस लिंकिंग एक person graph के इर्द-गिर्द बनी है जिसमें तीन तरह के nodes होते हैं: visitor (एक ब्राउज़र प्रोफ़ाइल), device (वह मशीन जो कई ब्राउज़र प्रोफ़ाइलों के नीचे होती है), और एक hashed identifier जो हस्ताक्षरित ईमेल पते या फोन नंबर से निकाला जाता है और जिसे आपका अपना एप्लिकेशन हमें भेजता है। इन nodes के बीच के edges ही दो सेशनों को एक व्यक्ति में जोड़ते हैं।

इस सूची से जानबूझकर बाहर रखे गए हैं: IP address और ASN। साझा नेटवर्क लुभावना signal है और गलत भी — कोई ऑफिस, कैंपस या carrier-grade NAT हज़ारों असंबंधित लोगों को एक ही पते के पीछे रख देता है, इसलिए IP पर आधारित edge ठीक वैसा ही गलत लिंक बनाता है जिसे पलटना सबसे महँगा पड़ता है। जो deterministic edges हम वाकई इस्तेमाल करते हैं — वही डिवाइस, वही hashed identifier, वही canonical visitor root — उन्हें साझा नेटवर्क गढ़कर पैदा नहीं कर सकता।

इसके ऊपर एक सीमित probabilistic हिस्सा भी है: किसी visitor के पुष्ट behavioral जोड़ों को जुड़ाव के उम्मीदवार के रूप में देखा जा सकता है, प्रति visitor छोटी-सी संख्या तक सीमित और केवल न्यूनतम confidence सीमा से ऊपर। यह उस cluster को चौड़ा करता है जिसे deterministic edges पहले ही टिका चुके हैं; अपने आप यह कोई cluster शुरू नहीं करता।

Device Graph का निर्माण

सेशनों के बीच हर पुष्ट या उच्च-संभावना वाला लिंक device graph में एक edge बनाता है। यह graph ब्राउज़र इंस्टेंसों को device nodes से, और device nodes को person nodes से जोड़ता है। समय के साथ, जैसे-जैसे अधिक सेशन जमा होते हैं, graph की सटीकता बढ़ती जाती है।

Graph के निर्माण में सतर्क दृष्टिकोण अपनाया जाता है। एक deterministic edge — दो ब्राउज़र प्रोफ़ाइलों के नीचे पहचाना गया वही डिवाइस, या दो अकाउंटों के लिए दिया गया वही hashed identifier — लिंक को सीधे बना देता है। इससे कमज़ोर हर चीज़ को लिंक नहीं, बल्कि उम्मीदवार माना जाता है, उसे न्यूनतम confidence सीमा पार करनी होती है, और उस पर ऊपरी सीमा लगी होती है ताकि एक visitor अपने पीछे असीमित cluster न घसीट सके। क्वारंटीन में पड़े visitor या bridge को शक के आधार पर मिलाने के बजाय पूरी तरह छोड़ दिया जाता है।

Fraud Detection में अनुप्रयोग

क्रॉस-डिवाइस लिंकिंग fraud detection के लिए विशेष रूप से शक्तिशाली है। जो fraudster कई ब्राउज़र प्रोफ़ाइलों पर अकाउंट चलाता है, उसकी पहचान तब हो जाती है जब वे प्रोफ़ाइलें नीचे मौजूद एक ही डिवाइस पर आ मिलती हैं, या जब वही हस्ताक्षरित identifier उनमें से दो अकाउंटों के पीछे दिखाई देता है। ऐसे डिवाइस पर उपयोग किया गया चोरी का credit card, जो कभी कार्डधारक के device graph से जुड़ा नहीं रहा, तुरंत अलर्ट ट्रिगर करता है।

हमने ऐसी fraud rings देखी हैं जहाँ एक ही ऑपरेटर दर्जनों virtual machines चलाकर नकली अकाउंट बनाता है। हर VM अलग browser fingerprint दिखाती है, लेकिन वे सब एक ही भौतिक hardware पर चलती हैं, और device resolution ही उन्हें वापस एक मशीन पर समेट देता है। वही साझा device node वह edge है जिस पर graph खड़ा होता है — यह किसी साझा पते का सहारा लिए बिना, एक ही पता चले अकाउंट से पूरी ring को उजागर कर देता है।

Privacy-संरक्षक डिज़ाइन

क्रॉस-डिवाइस लिंकिंग वाजिब privacy चिंताएँ उठाती है। हमारा दृष्टिकोण कई डिज़ाइन निर्णयों के माध्यम से इन्हें कम करता है। पहला, यह परत डिफ़ॉल्ट रूप से बंद रहती है — यह किसी deployment के साथ अपने आप नहीं आती, बल्कि किसी workspace के लिए जानबूझकर चालू की जाती है, और तब तक कोई person graph बनता ही नहीं। दूसरा, लिंकिंग server-side होती है और कभी ब्राउज़र के सामने उजागर नहीं होती, इसलिए लिंक किया गया graph क्लाइंट से पढ़ा नहीं जा सकता, और मोड हमारी तरफ़ से तय होता है, न कि पेज से भेजी गई किसी चीज़ से। तीसरा, identifier वाला edge तभी मौजूद होता है जब आपका अपना एप्लिकेशन हस्ताक्षरित ईमेल या फोन देना चुनता है — हम इसे visitor से खुद नहीं निकालते। चौथा, आपके privacy इंटरफ़ेस के माध्यम से उपयोगकर्ताओं को जुड़े हुए डिवाइसों के बारे में पारदर्शिता दी जा सकती है।

सटीकता के मापदंड

यह tradeoff जानबूझकर किया गया है और यह recall के मुकाबले precision को तरजीह देता है: हम गलत लिंक बनाने के बजाय किसी लिंक को चूक जाना पसंद करेंगे। यह तरजीह किसी सुर्खी वाले आँकड़े में नहीं, बल्कि डिज़ाइन में दिखती है — लिंक deterministic edges बनाते हैं, कमज़ोर signals सिर्फ़ पहले से टिके हुए clusters को चौड़ा करते हैं, क्वारंटीन किए गए bridges छोड़ दिए जाते हैं, और हर cluster पर ऊपरी सीमा लगी होती है। चूका हुआ लिंक आपसे बस एक fraud पैटर्न की कीमत लेता है, जो बाद में किसी दूसरे तरीके से वैसे भी पकड़ में आ जाता। गलत लिंक दो असली ग्राहकों को एक व्यक्ति में मिला देता है, और वह गलती उसके बाद लिए गए हर निर्णय में फैल जाती है।

इस पर भरोसा करने से पहले इसे अपने ट्रैफ़िक पर मापें। क्रॉस-डिवाइस recall इस बात पर निर्भर करता है कि आपके कितने उपयोगकर्ता वाकई प्रमाणीकरण करते हैं — identifier वाला edge सबसे मज़बूत उपलब्ध edge है, और वह वहीं मौजूद होता है जहाँ आपका एप्लिकेशन उसे देता है।