Phân cụm khách truy cập duy nhất theo useragent, ip, session_id


15

Đưa ra dữ liệu truy cập trang web trong biểu mẫu session_id, ip, user_agentvà dấu thời gian tùy chọn, theo các điều kiện bên dưới, làm thế nào tốt nhất bạn có thể phân cụm các phiên thành khách truy cập duy nhất?

session_id: là một id được cung cấp cho mọi khách truy cập mới. Nó không hết hạn, tuy nhiên nếu người dùng không chấp nhận cookie / xóa cookie / thay đổi trình duyệt / thay đổi thiết bị, anh ta sẽ không được nhận ra nữa

IP có thể được chia sẻ giữa những người dùng khác nhau (Hãy tưởng tượng một quán cà phê wi-fi miễn phí hoặc IP gán lại ISP của bạn) và họ thường sẽ có ít nhất 2, tại nhà và nơi làm việc.

User_agentlà phiên bản trình duyệt + HĐH, cho phép phân biệt giữa các thiết bị. Ví dụ, người dùng có thể sử dụng cả điện thoại và máy tính xách tay, nhưng không thể sử dụng máy tính xách tay windows + apple. Không chắc là cùng một id phiên có nhiều người dùng.

Dữ liệu có thể trông giống như câu đố ở đây: http://sqlfiddle.com/#!2/c4de40/1

Tất nhiên, chúng ta đang nói về các giả định, nhưng đó là về việc càng gần với thực tế càng tốt. Ví dụ: nếu chúng ta gặp cùng một ip và useragent trong một khung thời gian giới hạn với một session_id khác, thì đó sẽ là một giả định hợp lý rằng đó là cùng một người dùng, với một số trường hợp ngoại lệ.

Chỉnh sửa: Ngôn ngữ giải quyết vấn đề không chính đáng, chủ yếu là về logic và không triển khai. Mã giả là tốt.

Chỉnh sửa: do tính chất chậm của fiddle, bạn có thể thay thế đọc / chạy 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

Câu trả lời:


9

Một khả năng ở đây (và đây thực sự là một phần mở rộng của những gì Sean Owen đã đăng) là xác định "người dùng ổn định".

Đối với thông tin đã cho, bạn có thể tưởng tượng việc tạo user_id là hàm băm của ip và một số thông tin tác nhân người dùng (mã giả):

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

Sau đó, bạn gắn cờ các id này bằng "ổn định" hoặc "không ổn định" dựa trên các phương pháp phỏng đoán sử dụng mà bạn quan sát được cho người dùng của mình. Đây có thể là ngưỡng của số lượt truy cập trong một cửa sổ thời gian nhất định, thời gian cookie của họ tồn tại, một số hành động kết thúc trên trang web của bạn (tôi nhận ra điều này không được nêu trong nhật ký ban đầu của bạn), v.v ...

Ý tưởng ở đây là tách những người dùng không bỏ cookie khỏi những người làm.

Từ đây, bạn có thể gán session_ids cho các uids ổn định từ nhật ký của bạn. Sau đó, bạn sẽ có session_ids "còn lại" cho người dùng không ổn định mà bạn tương đối không chắc chắn. Bạn có thể kết thúc hoặc dưới các phiên đếm, quy kết hành vi cho nhiều người khi chỉ có một, v.v ... Nhưng điều này ít nhất là giới hạn đối với người dùng mà bạn hiện "ít chắc chắn" hơn.

Sau đó, bạn thực hiện phân tích về nhóm ổn định của bạn và dự án đó cho nhóm không ổn định. Lấy số người dùng làm ví dụ, bạn biết tổng số # phiên, nhưng bạn không chắc có bao nhiêu người dùng đã tạo các phiên đó. Bạn có thể tìm thấy # session / người dùng ổn định duy nhất và sử dụng số này để chiếu số lượng người dùng duy nhất "ước tính" trong nhóm không ổn định vì bạn biết số phiên được quy cho nhóm đó.

projected_num_unstable_users = num_sess_unstable / num_sess_per_stable_uid

Điều này không giúp ích cho việc điều tra theo cấp độ người dùng đối với người dùng không ổn định nhưng ít nhất bạn có thể nhận được một số dặm từ một nhóm người dùng ổn định tồn tại trong một thời gian. Bạn có thể, bằng nhiều phương pháp, hành vi dự án và tính vào nhóm không ổn định. Trên đây là một ví dụ đơn giản về một cái gì đó bạn có thể muốn biết. Ý tưởng chung là một lần nữa để xác định một nhóm người dùng mà bạn tự tin kiên trì, đo lường những gì bạn muốn đo và sử dụng một số sự thật cơ bản (tìm kiếm, truy cập, nhấp chuột, v.v.) để chiếu vào không gian người dùng và ước tính không xác định tính cho họ.

Đây là vấn đề tồn tại lâu dài trong việc đếm, đăng nhập, v.v. của người dùng đối với các dịch vụ không yêu cầu đăng nhập.


Một câu trả lời rất hay! Đối với những người đọc, tôi muốn thêm rằng trong trường hợp cookie của bên thứ 3, nhiều phiên bản di động của safari sẽ không lấy chúng theo mặc định và các trình duyệt khác có cùng đường ống. Giữ những người trong tâm trí và đối xử với họ riêng biệt.
AdrianBR

1
Cookie churn khá là vấn đề đối với các dịch vụ không yêu cầu đăng nhập. Nhiều người dùng đơn giản là không hiểu cookie mặc dù vậy bạn có thể có một số đoàn hệ mà bạn có thể theo dõi trong một khoảng thời gian đáng kể.
cwharland

6

Bạn không thể làm gì nhiều với dữ liệu này, nhưng những gì bạn có thể làm không phụ thuộc vào học máy.

Có, các phiên từ cùng một IP nhưng Đại lý người dùng khác nhau hầu như chắc chắn là những người dùng khác biệt. Các phiên có cùng IP và Tác nhân người dùng thường là cùng một người dùng, ngoại trừ trong trường hợp proxy / điểm truy cập wi-fi. Những người bạn có thể xác định bằng cách xem phân phối số phiên trên mỗi IP để xác định IP 'tổng hợp' có khả năng. Các phiên từ cùng một IP / Tác nhân người dùng trùng lặp về thời gian gần như chắc chắn là khác biệt.

Để phân biệt người dùng, bạn sẽ cần thêm thông tin. Ví dụ: các trang web hoặc địa chỉ IP mà người dùng đang kết nối sẽ là cơ sở rất mạnh để phân biệt các phiên. Sau đó, bạn có thể học tập tinh vi hơn để tìm ra khi nào các phiên là cùng hoặc khác người dùng.


Bối cảnh sẽ có thể theo dõi thông tin trong một trang web với cookie của bên thứ 3, thông qua iframe. Các trang web sẽ được thương mại điện tử. Tôi thấy google phân tích chủ yếu nhìn vào IP, đôi khi ở useragent và tôi có thể nhận được những con số rất giống nhau khi chỉ nhìn vào IP trong một khung thời gian. Nhưng Google Analytics được biết là đã báo cáo quá mức 30%, tùy thuộc vào ngữ cảnh
AdrianBR

Nhìn vào các trang sản phẩm được truy cập cũng không giúp được gì nhiều, vì cấu trúc của cửa hàng dẫn đến việc người dùng đi theo những con đường được xác định trước, dẫn đến hành vi rất giống nhau
AdrianBR

1
Ngoài ra, tôi biết rằng ML không phù hợp với bối cảnh của câu hỏi này. Thay vào đó, các thuật toán mã hóa cứng được sử dụng bởi hầu hết các giải pháp theo dõi cung cấp kết quả hợp lý. Một vài mức độ chính xác cuối cùng, có thể đạt được với ML ít liên quan hơn, vì thông tin này được sử dụng để quan sát xu hướng.
AdrianBR
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.