Кластеризація унікальних відвідувачів за допомогою useragent, ip, session_id

З огляду на дані про доступ до веб-сайтів у формі session_id, ip, user_agentта, можливо, часову позначку, дотримуючись наведених нижче умов, як ви найкраще класифікувати сеанси в унікальних відвідувачів?

session_id: - це ідентифікатор, який надається кожному новому відвідувачеві. Він не закінчується, проте якщо користувач не приймає файли cookie / очищення файлів cookie / зміни браузера / зміни пристрою, він більше не буде розпізнаний

IP їх можна ділитися між різними користувачами (уявіть собі безкоштовне кафе Wi-Fi або ваш Інтернет-провайдер, який переставляє IP-адреси), і вони часто матимуть як мінімум 2 дому та роботи.

User_agent- це версія браузера + ОС, що дозволяє розрізняти пристрої. Наприклад, користувач, швидше за все, буде використовувати телефон і ноутбук, але навряд чи використовувати Windows + Apple ноутбуки. Навряд чи той самий ідентифікатор сеансу має кілька користувачів.

Дані можуть виглядати як загадка тут: http://sqlfiddle.com/#!2/c4de40/1

Звичайно, ми говоримо про припущення, але мова йде про наближення до реальності, наскільки це можливо. Наприклад, якщо ми зустрічаємо одних і тих же ip та useragent у обмежені часові рамки з іншим session_id, було б справедливим припущенням, що це той самий користувач, за винятком кращих випадків.

Редагувати: мова, якою вирішується проблема, є невиправданою, здебільшого мова йде про логіку, а не про реалізацію. Псевдокод - це добре.

Редагувати: через повільний характер загадки ви можете альтернативно читати / запускати 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

Однією з можливих можливостей (а це дійсно розширення того, що розміщував Шон Оуен) є визначення "стабільного користувача".

Для даної інформації, яку ви маєте, ви можете уявити собі user_id, який є хешем ip та деякою інформацією про агента користувача (псевдокод):

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

Потім ви позначите ці ідентифікатори "стабільним" або "нестабільним" на основі евристики використання, яку ви спостерігаєте для своїх користувачів. Це може бути поріг # відвідувань у певному часовому вікні, тривалість часу збереження файлів cookie, деяка кінцева дія на вашому веб-сайті (я розумію, це не було зазначено у вашому оригінальному журналі) тощо.

Ідея тут полягає в тому, щоб відокремити користувачів, які не скидають файли cookie, від тих, що роблять.

Звідси ви можете віднести session_ids до стабільних UID із своїх журналів. Тоді вам залишиться "залишилося" session_ids для нестабільних користувачів, про які ви відносно не впевнені. Ви можете бути над чи під час підрахунку сеансів, приписуючи поведінку декільком людям, коли є лише один і т. Д. ... Але це принаймні обмежується користувачами, про яких ви зараз "менш певні".

Потім ви виконуєте аналітику на стабільній групі та проектуєте її на нестабільну групу. Візьмемо, наприклад, кількість користувачів, ви знаєте загальну кількість сеансів, але ви не знаєте, скільки користувачів створили ці сеанси. Ви можете знайти # сесії / унікального стабільного користувача та використовувати це для проектування "орієнтовної" кількості унікальних користувачів у нестабільній групі, оскільки ви знаєте кількість сеансів, віднесених до цієї групи.

projected_num_unstable_users = num_sess_unstable / num_sess_per_stable_uid

Це не допомагає досліджувати нестабільних користувачів на рівні кожного користувача, але ви можете принаймні отримати деякий пробіг із групи стабільних користувачів, які зберігаються деякий час. Ви можете за різними методами проектувати поведінку і зараховувати до нестабільної групи. Наведене вище - простий приклад того, що ви можете хотіти знати. Загальна ідея знову полягає в тому, щоб визначити набір користувачів, яких ви впевнено наполягаєте, виміряти те, що ви хочете виміряти, і використовувати певні основні істини (пошук чисел, відвідування, кліки тощо) для проектування у невідомий простір користувача та оцінки розраховує на них.

Це давня проблема унікального підрахунку користувачів, реєстрації даних тощо ... для служб, які не потребують входу.

З цим даними можна зробити не так багато, але те, що ти мало можеш зробити, не покладається на машинне навчання.

Так, сеанси одного і того ж IP, але різні користувацькі агенти майже напевно відрізняються від користувачів. Сесії з тим самим IP-адресою та Користувачем-агентом, як правило, є одним і тим же користувачем, за винятком випадків доступу до проксі-серверів / точок доступу Wi-Fi. Ті, кого ви можете ідентифікувати, переглянувши розподіл кількості сеансів на IP для виявлення ймовірних "сукупних" IP-адрес. Сеанси того ж IP / User-Agent, які перетинаються в часі, майже напевно відрізняються.

Для подальшого розмежування користувачів вам знадобиться більше інформації. Наприклад, сайти або IP-адреси, до яких підключається користувач, були б дуже сильною основою для диференціації сеансів. Тоді ви можете отримати більш складне навчання, щоб зрозуміти, коли сеанси однакові або різні користувачі.