Useragent, ip, session_id द्वारा अद्वितीय विज़िटर का क्लस्टरिंग


15

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

session_id: हर नए आगंतुक को एक आईडी दी जाती है। यह समाप्त नहीं होता है, हालांकि अगर उपयोगकर्ता कुकीज़ को स्वीकार नहीं करता है / कुकीज़ / परिवर्तन ब्राउज़र / परिवर्तन डिवाइस को साफ़ करता है, तो वह अब नहीं होगा

IP विभिन्न उपयोगकर्ताओं के बीच साझा किया जा सकता है (एक मुफ्त वाई-फाई कैफे, या आपके आईएसपी पुन: असाइन किए गए आईपी की कल्पना करें), और उनके पास अक्सर कम से कम 2, घर और काम होंगे।

User_agentब्राउज़र + OS संस्करण है, जो उपकरणों के बीच अंतर करने की अनुमति देता है। उदाहरण के लिए एक उपयोगकर्ता फोन और लैपटॉप दोनों का उपयोग करने की संभावना रखता है, लेकिन विंडोज़ + ऐप्पल लैपटॉप का उपयोग करने की संभावना नहीं है। यह संभावना नहीं है कि एक ही सत्र आईडी में कई उपयोगकर्ता हैं।

डेटा यहाँ फ़ेडल के रूप में दिख सकता है: http://sqlfiddle.com/#/2/c4de40/1

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

संपादित करें: जिस भाषा में समस्या हल हो गई है वह irellevant है, यह अधिकतर तर्क के बारे में है और कार्यान्वयन नहीं है। स्यूडोकोड ठीक है।

संपादित करें: फिडेल की धीमी प्रकृति के कारण, आप वैकल्पिक रूप से mysql को पढ़ / चला सकते हैं:

select session_id, floor(rand()*256*256*256*256) as ip_num , floor(rand()*1000) as user_agent_id
from 
    (select 1+a.nr+10*b.nr as session_id, ceil(rand()*3) as nr
    from
        (select 1 as nr union all select 2 union all select 3   union all select 4 union all select 5
        union all select 6 union all select 7 union all select 8 union all select 9 union all select 0)a
    join
        (select 1 as nr union all select 2 union all select 3   union all select 4 union all select 5
        union all select 6 union all select 7 union all select 8 union all select 9 union all select 0)b
        order by 1
    )d
inner join
    (select 1 as nr union all select 2 union all select 3   union all select 4 union all select 5
    union all select 6 union all select 7 union all select 8 union all select 9 )e
    on d.nr>=e.nr

जवाबों:


9

यहाँ एक संभावना (और यह वास्तव में सीन ओवेन ने क्या पोस्ट किया है) "स्थिर उपयोगकर्ता" को परिभाषित करना है।

आपके पास दी गई जानकारी के लिए आप एक user_id बनाने की कल्पना कर सकते हैं जो कि IP का हैश हो और कुछ उपयोगकर्ता एजेंट जानकारी (pseb कोड):

uid = MD5Hash(ip + UA.device + UA.model)

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

यहां विचार उन उपयोगकर्ताओं को अलग करने का है जो उन लोगों से कुकीज़ नहीं छोड़ते हैं जो करते हैं।

यहाँ से आप अपने लॉग से सेशन को स्थिर रखने के लिए session_ids को देख सकते हैं। तब आपके पास अस्थिर उपयोगकर्ताओं के लिए "लेफ्ट ओवर" सेशन_एड्स होंगे जिनके बारे में आप अपेक्षाकृत अनिश्चित हैं। आप एक से अधिक लोगों के साथ व्यवहार के कारण, सत्रों की गिनती के दौरान या उससे अधिक हो सकते हैं, आदि ... लेकिन यह उन उपयोगकर्ताओं के लिए कम से कम सीमित है जिनके बारे में आप अब "कम निश्चित" हैं।

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

projected_num_unstable_users = num_sess_unstable / num_sess_per_stable_uid

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

यह अद्वितीय उपयोगकर्ता की गिनती, लॉगिंग, आदि ... में उन सेवाओं के लिए एक लंबे समय से समस्या है, जिनके लिए लॉग की आवश्यकता नहीं है।


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

1
कुकी मंथन उन सेवाओं के लिए काफी समस्या है जिनके लिए लॉग इन की आवश्यकता नहीं होती है। कई उपयोगकर्ता केवल कुकीज़ को नहीं समझते हैं, इसलिए आपके पास कुछ कॉहोर्ट होने की संभावना है जो आप एक प्रशंसनीय राशि के लिए अनुसरण कर सकते हैं।
cwharland

6

बहुत कुछ आप इस डेटा के साथ नहीं कर सकते हैं, लेकिन जो कुछ आप कर सकते हैं वह मशीन सीखने पर निर्भर नहीं करता है।

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

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


संदर्भ एक पार्टी साइट के साथ एक iframe के माध्यम से एक एकल साइट के भीतर ट्रैक करने योग्य जानकारी होगी। साइट ईकॉमर्स होगी। मुझे लगता है कि Google विश्लेषिकी ज्यादातर IP को देखता है, कभी-कभी useragent पर, और मैं केवल एक समयसीमा में IP को देखने से बहुत समान संख्या प्राप्त करने में सक्षम हूं। लेकिन गूगल एनालिटिक्स 30% ish द्वारा ओवर-रिपोर्ट करने के लिए जाना जाता है, संदर्भ के आधार पर
एड्रियनबीआर

विज़िट किए गए उत्पाद पृष्ठों को देखने से बहुत मदद नहीं मिलती है, क्योंकि दुकान की संरचना ऐसी है कि यह उपयोगकर्ताओं को पूर्वनिर्धारित रास्तों की ओर ले जाती है, जिससे बहुत समान व्यवहार होता है
AdrianBR

1
इसके अलावा, मुझे पता है कि एमएल इस सवाल के संदर्भ में फिट नहीं है। बल्कि, हार्ड कोडित एल्गोरिदम का उपयोग अधिकांश ट्रैकिंग समाधानों द्वारा किया जाता है जो समझदार परिणाम प्रदान करते हैं। सटीकता के अंतिम कुछ डिग्री, जो कि एमएल के साथ प्राप्त करने योग्य होंगे, कम प्रासंगिकता के होते हैं, क्योंकि इस जानकारी का उपयोग रुझानों को देखने के लिए किया जाता है।
एड्रियनबीआर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.