Mengelompokkan pengunjung unik berdasarkan agen pengguna, ip, session_id


15

Diberikan data akses situs web dalam formulir session_id, ip, user_agent, dan cap waktu opsional, mengikuti kondisi di bawah ini, bagaimana cara terbaik Anda mengelompokkan sesi menjadi pengunjung unik?

session_id: adalah id yang diberikan kepada setiap pengunjung baru. Itu tidak kedaluwarsa, namun jika pengguna tidak menerima cookie / menghapus cookie / perubahan browser / perubahan perangkat, ia tidak akan dikenali lagi

IP dapat dibagikan di antara pengguna yang berbeda (Bayangkan kafe wi-fi gratis, atau ISP Anda yang mengatur ulang IP), dan mereka akan sering memiliki setidaknya 2, rumah dan kantor.

User_agentadalah versi browser + OS, memungkinkan untuk membedakan antara perangkat. Misalnya, pengguna cenderung menggunakan ponsel dan laptop, tetapi tidak mungkin menggunakan laptop windows + apple. Tidak mungkin id sesi yang sama memiliki beberapa agen pengguna.

Data mungkin terlihat seperti biola di sini: http://sqlfiddle.com/#!2/c4de40/1

Tentu saja, kita berbicara tentang asumsi, tetapi tentang mendapatkan sedekat mungkin dengan kenyataan. Misalnya, jika kita menemukan ip dan agen yang sama dalam kerangka waktu terbatas dengan session_id yang berbeda, itu akan menjadi asumsi yang adil bahwa itu adalah pengguna yang sama, dengan beberapa pengecualian kasus tepi.

Sunting: Bahasa di mana masalah diselesaikan adalah tidak sopan, sebagian besar tentang logika dan bukan implementasi. Kodesemu baik-baik saja.

Sunting: karena sifat biola yang lambat, Anda dapat membaca / menjalankan mysql sebagai alternatif:

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

Jawaban:


9

Satu kemungkinan di sini (dan ini benar-benar perpanjangan dari apa yang diposting Sean Owen) adalah mendefinisikan "pengguna stabil."

Untuk info yang diberikan, Anda dapat membayangkan membuat user_id yang merupakan hash dari ip dan beberapa info agen pengguna (kode semu):

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

Kemudian Anda menandai id ini dengan "stabil" atau "tidak stabil" berdasarkan heuristik penggunaan yang Anda amati untuk pengguna Anda. Ini bisa menjadi ambang batas # kunjungan di jendela waktu tertentu, lamanya cookie mereka bertahan, beberapa tindakan akhir di situs Anda (saya menyadari ini tidak disebutkan dalam log asli Anda), dll ...

Idenya di sini adalah untuk memisahkan pengguna yang tidak menjatuhkan cookie dari yang melakukannya.

Dari sini Anda dapat mengaitkan session_ids dengan cairan stabil dari log Anda. Kemudian Anda akan memiliki "sisa" session_ids untuk pengguna yang tidak stabil yang relatif tidak Anda yakini. Anda mungkin melebihi atau di bawah sesi penghitungan, menghubungkan perilaku ke beberapa orang ketika hanya ada satu, dll ... Tapi ini setidaknya terbatas pada pengguna yang sekarang Anda "kurang yakin" tentang.

Anda kemudian melakukan analisis pada grup stabil Anda dan memproyeksikannya ke grup yang tidak stabil. Sebagai contoh, hitung jumlah pengguna, Anda tahu jumlah total sesi, tetapi Anda tidak yakin berapa banyak pengguna yang menghasilkan sesi tersebut. Anda dapat menemukan # sesi / pengguna stabil unik dan gunakan ini untuk memproyeksikan "perkiraan" jumlah pengguna unik dalam grup tidak stabil karena Anda tahu jumlah sesi yang dikaitkan dengan grup itu.

projected_num_unstable_users = num_sess_unstable / num_sess_per_stable_uid

Ini tidak membantu dengan penyelidikan tingkat pengguna pada pengguna yang tidak stabil tetapi Anda setidaknya bisa mendapatkan jarak tempuh dari kohort pengguna stabil yang bertahan selama beberapa waktu. Anda dapat, dengan berbagai metode, memproyeksikan perilaku dan menghitung ke dalam kelompok yang tidak stabil. Di atas adalah contoh sederhana dari sesuatu yang Anda mungkin ingin tahu. Gagasan umum lagi adalah untuk menetapkan seperangkat pengguna yang Anda yakini bertahan, mengukur apa yang ingin Anda ukur, dan menggunakan kebenaran dasar tertentu (pencarian angka, kunjungan, klik, dll ...) untuk memproyeksikan ke ruang pengguna yang tidak diketahui dan perkiraan diperhitungkan untuk mereka.

Ini adalah masalah yang sudah berlangsung lama dalam penghitungan pengguna unik, masuk, dll ... untuk layanan yang tidak memerlukan login.


Jawaban yang sangat bagus! Bagi mereka yang membaca, saya ingin menambahkan bahwa dalam kasus cookie pihak ke-3, banyak versi seluler safari tidak akan mengambilnya secara default, dan peramban lain memiliki yang sama di saluran pipa mereka. Ingatlah hal itu dan perlakukan secara terpisah.
AdrianBR

1
Cookie churn adalah masalah bagi layanan yang tidak memerlukan login. Banyak pengguna yang tidak mengerti cookie sehingga Anda mungkin memiliki beberapa kelompok yang dapat Anda ikuti untuk waktu yang cukup lama.
cwharland

6

Tidak banyak yang dapat Anda lakukan hanya dengan data ini, tetapi sedikit yang dapat Anda lakukan tidak bergantung pada pembelajaran mesin.

Ya, sesi dari IP yang sama tetapi Agen-Pengguna yang berbeda hampir pasti adalah pengguna yang berbeda. Sesi dengan IP dan User-Agent yang sama biasanya merupakan pengguna yang sama, kecuali dalam hal proxy / titik akses wi-fi. Yang mungkin Anda identifikasi dengan melihat distribusi jumlah sesi per IP untuk mengidentifikasi kemungkinan IP 'agregat'. Sesi dari IP / User-Agent yang sama yang tumpang tindih dalam waktu hampir pasti berbeda.

Untuk lebih membedakan pengguna Anda perlu info lebih lanjut. Misalnya, situs atau alamat IP yang terhubung dengan pengguna akan menjadi dasar yang sangat kuat untuk sesi pembeda. Kemudian Anda bisa masuk ke pembelajaran yang lebih canggih untuk mencari tahu kapan sesi adalah pengguna yang sama atau berbeda.


Konteksnya adalah info dapat dilacak dalam satu situs dengan cookie pihak ke-3, melalui iframe. Situs tersebut adalah e-niaga. Saya menemukan sebagian besar analisis google terlihat pada IP, kadang-kadang pada agen pengguna, dan saya bisa mendapatkan angka yang sangat mirip dari hanya melihat IP dalam jangka waktu. Tetapi Google analytics diketahui melaporkan berlebihan dengan 30% ish, tergantung pada konteksnya
AdrianBR

Melihat halaman produk yang dikunjungi juga tidak banyak membantu, karena struktur toko sedemikian rupa sehingga mengarahkan pengguna ke jalur yang telah ditentukan, mengarah ke perilaku yang sangat mirip
AdrianBR

1
Saya juga sadar bahwa ML tidak sesuai dengan konteks pertanyaan ini. Alih-alih, algoritma kode keras digunakan oleh sebagian besar solusi pelacakan yang menawarkan hasil yang masuk akal. Beberapa tingkat akurasi terakhir, yang dapat dicapai dengan ML kurang relevan, karena info ini agak digunakan untuk mengamati tren.
AdrianBR
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.