การจัดกลุ่มผู้เยี่ยมชมที่ไม่ซ้ำกันตาม useragent, ip, session_id


15

ข้อมูลการเข้าถึงเว็บไซต์ที่ระบุในแบบฟอร์มsession_id, ip, user_agentและเวลาเลือกปฏิบัติตามเงื่อนไขด้านล่างคุณจะจัดกลุ่มเซสชันเป็นผู้เยี่ยมชมที่ไม่ซ้ำได้อย่างไร

session_id: เป็นรหัสที่มอบให้แก่ผู้เข้าชมใหม่ทุกคน มันไม่หมดอายุอย่างไรก็ตามหากผู้ใช้ไม่ยอมรับคุกกี้ / ล้างคุกกี้ / เปลี่ยนเบราว์เซอร์ / เปลี่ยนอุปกรณ์เขาจะไม่ถูกจดจำอีกต่อไป

IP สามารถใช้ร่วมกันระหว่างผู้ใช้ที่แตกต่างกัน (ลองจินตนาการถึงร้านกาแฟ Wi-Fi ฟรีหรือ ISP ของคุณกำหนด IP) และพวกเขามักจะมีอย่างน้อย 2 บ้านและที่ทำงาน

User_agentเป็นเวอร์ชันของเบราว์เซอร์ + OS ที่อนุญาตให้แยกความแตกต่างระหว่างอุปกรณ์ ตัวอย่างเช่นผู้ใช้มีแนวโน้มที่จะใช้ทั้งโทรศัพท์และแล็ปท็อป แต่ไม่น่าจะใช้ windows + apple laptop ไม่น่าเป็นไปได้ที่รหัสเซสชันเดียวกันจะมีผู้ใช้หลายคน

ข้อมูลอาจดูเป็นซอที่นี่: http://sqlfiddle.com/#!2/c4de40/1

แน่นอนว่าเรากำลังพูดถึงสมมติฐาน แต่มันเกี่ยวกับการเข้าใกล้ความเป็นจริงให้มากที่สุด ตัวอย่างเช่นหากเราพบ ip และ useragent เดียวกันในกรอบเวลาที่ จำกัด ด้วย session_id ที่แตกต่างกันมันจะเป็นข้อสันนิษฐานที่ยุติธรรมว่าเป็นผู้ใช้เดียวกันโดยมีข้อยกเว้นกรณีขอบบางอย่าง

แก้ไข: ภาษาที่แก้ไขปัญหานั้นไม่เกี่ยวข้องกับภาษาส่วนใหญ่เกี่ยวกับตรรกะและไม่ใช้งาน Pseudocode นั้นใช้ได้

แก้ไข: เนื่องจากลักษณะซอช้าคุณสามารถอ่าน / เรียกใช้ 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

ความเป็นไปได้อย่างหนึ่งที่นี่ (และนี่คือส่วนขยายของสิ่งที่ Sean Owen โพสต์) คือการกำหนด "ผู้ใช้ที่เสถียร"

สำหรับข้อมูลที่ได้รับคุณสามารถจินตนาการได้ว่าการสร้าง user_id ซึ่งเป็นแฮชของ ip และข้อมูลตัวแทนผู้ใช้บางส่วน (รหัสเทียม):

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

จากนั้นคุณติดธงรหัสเหล่านี้ด้วย "เสถียร" หรือ "ไม่เสถียร" ตามการวิเคราะห์พฤติกรรมการใช้งานที่คุณสังเกตเห็นสำหรับผู้ใช้ของคุณ นี่อาจเป็นเกณฑ์ของจำนวนการเข้าชม # ในหน้าต่างเวลาที่กำหนดระยะเวลาคุกกี้ของพวกเขายังคงมีอยู่การกระทำบางอย่างบนไซต์ของคุณ (ฉันรู้ว่านี่ไม่ได้ระบุไว้ในบันทึกเดิมของคุณ) ฯลฯ ...

แนวคิดในที่นี้คือการแยกผู้ใช้ที่ไม่ปล่อยคุกกี้ออกจากที่ทำ

จากที่นี่คุณสามารถระบุแอตทริบิวต์ session_ids ถึง uids ที่เสถียรจากบันทึกของคุณ จากนั้นคุณจะมี "ส่วนที่เหลือ" session_ids สำหรับผู้ใช้ที่ไม่เสถียรซึ่งคุณไม่แน่ใจ คุณอาจจะอยู่เหนือหรือนับเซสชันซึ่งมีพฤติกรรมหลายคนเมื่อมีเพียงคนเดียว ฯลฯ ... แต่อย่างน้อยก็มีข้อ จำกัด สำหรับผู้ใช้ที่คุณกำลัง "มั่นใจน้อยลง" เกี่ยวกับเรื่องนี้

จากนั้นคุณทำการวิเคราะห์ในกลุ่มที่มั่นคงของคุณและโครงการที่ไปยังกลุ่มที่ไม่เสถียร ยกตัวอย่างเช่นคุณรู้จำนวนเซสชันทั้งหมด แต่คุณไม่แน่ใจว่ามีผู้ใช้กี่คนที่สร้างเซสชันเหล่านั้น คุณสามารถค้นหา # เซสชัน / ผู้ใช้ที่มีความเสถียรที่ไม่ซ้ำกันและใช้สิ่งนี้เพื่อคาดการณ์จำนวนผู้ใช้ที่ไม่ซ้ำ "โดยประมาณ" ในกลุ่มที่ไม่เสถียรเนื่องจากคุณทราบจำนวนเซสชันที่เกี่ยวข้องกับกลุ่มนั้น

projected_num_unstable_users = num_sess_unstable / num_sess_per_stable_uid

สิ่งนี้ไม่ได้ช่วยในการตรวจสอบระดับผู้ใช้กับผู้ใช้ที่ไม่เสถียร แต่อย่างน้อยคุณก็สามารถได้รับไมล์สะสมจากผู้ใช้ที่มีเสถียรภาพที่มีอยู่เป็นระยะเวลาหนึ่ง คุณสามารถทำได้โดยใช้วิธีการต่าง ๆ พฤติกรรมของโครงการและนับเป็นกลุ่มที่ไม่เสถียร ด้านบนเป็นตัวอย่างง่ายๆของสิ่งที่คุณอาจต้องการทราบ แนวคิดทั่วไปอีกครั้งคือการกำหนดกลุ่มผู้ใช้ที่คุณมั่นใจว่ายังคงมีอยู่วัดสิ่งที่คุณต้องการวัดและใช้ความจริงพื้นฐานบางอย่าง (การค้นหาจำนวนการเข้าชมการคลิก ฯลฯ ... ) เพื่อคาดการณ์พื้นที่ผู้ใช้ที่ไม่รู้จัก นับสำหรับพวกเขา

นี่เป็นปัญหาที่ยาวนานในการนับจำนวนผู้ใช้ที่ไม่ซ้ำการบันทึก ฯลฯ ... สำหรับบริการที่ไม่จำเป็นต้องลงชื่อเข้าใช้


คำตอบที่ดีมาก! สำหรับการอ่านเหล่านั้นฉันต้องการเพิ่มว่าในกรณีของคุกกี้บุคคลที่สามเวอร์ชันมือถือของซาฟารีจำนวนมากจะไม่รับสิ่งเหล่านี้ตามค่าเริ่มต้นและเบราว์เซอร์อื่น ๆ จะมีคุณสมบัติเหมือนกันในท่อของตน โปรดจำไว้ว่าพวกเขาและรักษาพวกเขาแยกกัน
AdrianBR

1
Cookie churn ค่อนข้างเป็นปัญหาสำหรับบริการที่ไม่จำเป็นต้องมีการเข้าสู่ระบบผู้ใช้หลายคนก็ไม่เข้าใจคุกกี้แม้ว่าคุณจะมีกลุ่มคนที่คุณสามารถติดตามได้เป็นระยะเวลาหนึ่ง
cwharland

6

มีข้อมูลไม่มากที่คุณสามารถทำได้ แต่สิ่งเล็ก ๆ น้อย ๆ ที่คุณทำได้ไม่ต้องพึ่งพาการเรียนรู้ของเครื่อง

ใช่เซสชันจาก IP เดียวกัน แต่ตัวแทนผู้ใช้ที่แตกต่างกันเป็นผู้ใช้ที่แตกต่างกัน เซสชันที่มี IP และตัวแทนผู้ใช้เดียวกันมักจะเป็นผู้ใช้เดียวกันยกเว้นในกรณีของจุดเชื่อมต่อพร็อกซี / wi-fi สิ่งที่คุณอาจระบุโดยดูจากการกระจายจำนวนเซสชันต่อ IP เพื่อระบุ IP รวมที่น่าจะเป็น เซสชันจาก IP / User-Agent เดียวกันที่ทับซ้อนกันในเวลานั้นแทบจะแตกต่างกันอย่างแน่นอน

หากต้องการแยกแยะผู้ใช้เพิ่มเติมคุณต้องมีข้อมูลเพิ่มเติม ตัวอย่างเช่นไซต์หรือที่อยู่ IP ที่ผู้ใช้เชื่อมต่อจะเป็นพื้นฐานที่แข็งแกร่งมากสำหรับการแยกเซสชัน จากนั้นคุณสามารถเข้าสู่การเรียนรู้ที่ซับซ้อนยิ่งขึ้นเพื่อทราบว่าช่วงเวลาใดที่มีผู้ใช้เหมือนหรือต่างกัน


บริบทจะเป็นข้อมูลที่ติดตามได้ภายในไซต์เดียวที่มีคุกกี้บุคคลที่สามผ่านทาง iframe เว็บไซต์จะเป็นอีคอมเมิร์ซ ฉันพบว่า Google Analytics ส่วนใหญ่ดูที่ IP บางครั้งที่ useragent และฉันสามารถรับตัวเลขที่คล้ายกันมากจากการดูเฉพาะ IP ในกรอบเวลา แต่ Google Analytics นั้นรายงานมากกว่า 30% โดยขึ้นอยู่กับบริบท
AdrianBR

การดูหน้าผลิตภัณฑ์ที่เข้าชมไม่ได้ช่วยอะไรมากนักเนื่องจากโครงสร้างของร้านค้านั้นทำให้ผู้ใช้ลงเส้นทางที่กำหนดไว้ล่วงหน้าซึ่งนำไปสู่พฤติกรรมที่คล้ายกันมาก
AdrianBR

1
นอกจากนี้ฉันทราบว่า ML ไม่เหมาะกับบริบทของคำถามนี้ ค่อนข้างใช้อัลกอริธึมแบบตายตัวโดยโซลูชันติดตามส่วนใหญ่ที่ให้ผลลัพธ์ที่สมเหตุสมผล ความแม่นยำระดับสองสามครั้งสุดท้ายที่สามารถทำได้ด้วย ML นั้นมีความเกี่ยวข้องน้อยกว่าเนื่องจากข้อมูลนี้ค่อนข้างใช้สำหรับการสังเกตแนวโน้ม
AdrianBR
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.