Grupowanie unikalnych użytkowników według useragent, ip, session_id

Biorąc pod uwagę dane dostępu do witryny w formularzu session_id, ip, user_agenti opcjonalnie znacznik czasu, zgodnie z poniższymi warunkami, w jaki sposób najlepiej podzielić sesje na unikalnych użytkowników?

session_id: to identyfikator nadawany każdemu nowemu odwiedzającemu. Nie wygasa, jednak jeśli użytkownik nie zaakceptuje plików cookie / wyczyści pliki cookie / zmieni przeglądarkę / zmieni urządzenie, nie będzie już rozpoznawany

IP mogą być współużytkowane przez różnych użytkowników (wyobraź sobie bezpłatną kawiarnię Wi-Fi lub zmianę adresu IP przez Twojego dostawcę usług internetowych), a często będą mieli co najmniej 2 osoby, dom i pracę.

User_agentto wersja przeglądarki + systemu operacyjnego, umożliwiająca rozróżnienie urządzeń. Na przykład użytkownik może używać zarówno telefonu, jak i laptopa, ale jest mało prawdopodobne, aby korzystał z laptopów z systemem Windows i Apple. Jest mało prawdopodobne, aby ten sam identyfikator sesji miał wielu użytkowników.

Dane mogą wyglądać jak skrzypce tutaj: http://sqlfiddle.com/#!2/c4de40/1

Oczywiście mówimy o założeniach, ale chodzi o to, aby zbliżyć się do rzeczywistości tak, jak to możliwe. Na przykład, jeśli napotkamy ten sam adres IP i identyfikator użytkownika w ograniczonym przedziale czasowym z innym identyfikatorem session_id, można założyć, że jest to ten sam użytkownik, z pewnymi wyjątkami dotyczącymi krawędzi.

Edycja: Język, w którym problem został rozwiązany, nie ma znaczenia, dotyczy głównie logiki, a nie implementacji. Pseudokod jest w porządku.

Edycja: ze względu na powolny charakter skrzypiec możesz alternatywnie czytać / uruchamiać 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

Jedną z możliwości (a tak naprawdę jest to rozszerzenie tego, co napisał Sean Owen), jest zdefiniowanie „stabilnego użytkownika”.

Dla podanych informacji możesz sobie wyobrazić utworzenie id_użytkownika, który jest skrótem adresu IP i niektórych informacji o kliencie użytkownika (pseudo-kod):

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

Następnie oflagujesz te identyfikatory jako „stabilne” lub „niestabilne” na podstawie heurystyki użytkowania, którą obserwujesz dla swoich użytkowników. Może to być próg liczby odwiedzin w danym oknie czasowym, czas przechowywania plików cookie, niektóre działania końcowe w witrynie (zdaję sobie sprawę, że nie było tego w oryginalnym dzienniku) itp.

Chodzi o to, aby oddzielić użytkowników, którzy nie upuszczają plików cookie, od tych, którzy to robią.

Stąd możesz przypisać session_ids do stabilnych UID z twoich logów. Będziesz wtedy miał „resztki” session_ids dla niestabilnych użytkowników, co do których jesteś stosunkowo niepewny. Być może sesje są nadmiernie lub niedostatecznie liczone, przypisując zachowanie wielu osobom, gdy jest tylko jedna itd. Ale to jest co najmniej ograniczone do użytkowników, których jesteś teraz „mniej pewny”.

Następnie wykonujesz analizy na stabilnej grupie i projektujesz ją na niestabilną grupę. Weźmy na przykład liczbę użytkowników, znasz całkowitą liczbę sesji, ale nie masz pewności, ilu użytkowników wygenerowało te sesje. Możesz znaleźć # sesji / unikalnego stabilnego użytkownika i użyć go do wyświetlenia „szacunkowej” liczby unikalnych użytkowników w niestabilnej grupie, ponieważ znasz liczbę sesji przypisanych do tej grupy.

projected_num_unstable_users = num_sess_unstable / num_sess_per_stable_uid

To nie pomaga w dochodzeniu na poziomie użytkowników niestabilnych użytkowników, ale możesz przynajmniej uzyskać przebieg z grupy stabilnych użytkowników, którzy utrzymują się przez pewien czas. Za pomocą różnych metod możesz projektować zachowanie i zaliczać się do niestabilnej grupy. Powyżej jest prostym przykładem czegoś, co możesz chcieć wiedzieć. Ogólnym pomysłem jest ponowne zdefiniowanie zestawu użytkowników, których zachowanie jest pewne, zmierzenie tego, co chcesz zmierzyć, i wykorzystanie pewnych podstawowych prawd (liczba wyszukiwań, odwiedzin, kliknięć itp.) W celu wyświetlenia w nieznanej przestrzeni użytkowników i oszacowania liczy się dla nich.

Jest to długotrwały problem związany z unikalnym liczeniem użytkowników, logowaniem itp. W przypadku usług, które nie wymagają logowania.

Z tymi danymi niewiele można zrobić, ale to, co niewiele można zrobić, nie zależy od uczenia maszynowego.

Tak, sesje z tego samego adresu IP, ale różni użytkownicy użytkownika są prawie na pewno różnymi użytkownikami. Sesje z tym samym adresem IP i User-Agent to zwykle ten sam użytkownik, z wyjątkiem serwerów proxy / punktów dostępu Wi-Fi. Te, które możesz zidentyfikować, patrząc na rozkład liczby sesji według adresu IP, aby zidentyfikować prawdopodobne „zagregowane” adresy IP. Sesje z tego samego IP / User-Agent, które nakładają się w czasie, są prawie na pewno różne.

Aby dodatkowo rozróżnić użytkowników, potrzebujesz więcej informacji. Na przykład witryny lub adresy IP, z którymi łączy się użytkownik, byłyby bardzo mocną podstawą do różnicowania sesji. Następnie możesz przejść do bardziej wyrafinowanej nauki, aby dowiedzieć się, kiedy sesje są tymi samymi lub różnymi użytkownikami.