Кластеризация уникальных посетителей по useragent, ip, session_id

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

session_id: это идентификатор для каждого нового посетителя. Срок его действия не истекает, однако, если пользователь не принимает куки-файлы / удаляет куки-файлы / меняет браузер / меняет устройство, он больше не будет распознаваться

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)

Затем вы помечаете эти идентификаторы как "стабильный" или "нестабильный" на основе эвристики использования, которую вы наблюдаете для своих пользователей. Это может быть порог количества посещений за определенный промежуток времени, продолжительности времени, в течение которого их куки сохраняются, некоторые конечные действия на вашем сайте (я понимаю, что это не было указано в вашем исходном журнале) и т. Д.

Идея здесь состоит в том, чтобы отделить пользователей, которые не сбрасывают куки, с тех, которые делают.

Отсюда вы можете приписать session_ids к стабильным uid из ваших логов. После этого у вас будут «оставшиеся» session_ids для нестабильных пользователей, в которых вы относительно не уверены. Вы можете считать больше или меньше подсчитывать сеансы, приписывать поведение нескольким людям, когда есть только один, и т. Д ... Но это, по крайней мере, ограничено пользователями, в которых вы сейчас "менее уверены".

Затем вы выполняете аналитику в своей стабильной группе и проецируете ее в нестабильную группу. Возьмем, например, количество пользователей, вы знаете общее количество сеансов, но вы не уверены, сколько пользователей сгенерировали эти сеансы. Вы можете найти # сессий / уникального стабильного пользователя и использовать его для проецирования «оценочного» количества уникальных пользователей в нестабильной группе, поскольку вы знаете количество сеансов, приписанных этой группе.

projected_num_unstable_users = num_sess_unstable / num_sess_per_stable_uid

Это не помогает при расследовании на уровне пользователя для нестабильных пользователей, но вы можете, по крайней мере, получить некоторое преимущество от группы стабильных пользователей, которые сохраняются в течение некоторого времени. Вы можете различными способами проектировать поведение и считать в нестабильную группу. Выше приведен простой пример того, что вы, возможно, захотите узнать. Общая идея заключается в том, чтобы снова определить группу пользователей, которых вы уверены, что вы сохраняете, измерить то, что вы хотите измерить, и использовать определенные основные истины (количество поисков, посещений, кликов и т. Д.) Для проецирования в неизвестное пространство пользователя и оценки рассчитывает на них.

Это давняя проблема в подсчете уникальных пользователей, ведении журнала и т. Д. Для сервисов, которые не требуют входа в систему.

С этими данными мало что можно сделать, но мало что можно сделать, не полагаясь на машинное обучение.

Да, сеансы с одного и того же IP, но разных User-Agent почти наверняка являются разными пользователями. Сеансы с одним и тем же IP-адресом и User-Agent обычно являются одним и тем же пользователем, за исключением случаев использования прокси / точек доступа Wi-Fi. Те, которые вы можете определить, посмотрев распределение количества сеансов по IP, чтобы определить вероятные «совокупные» IP. Сеансы одного и того же IP / User-Agent, которые перекрываются во времени, почти наверняка различны.

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