Clustering di visitatori unici per useragent, ip, session_id

Dati i dati di accesso al sito Web nel modulo session_id, ip, user_agente, facoltativamente, il timestamp, seguendo le condizioni seguenti, come sarebbe meglio raggruppare le sessioni in visitatori unici?

session_id: è un ID assegnato a ogni nuovo visitatore. Non scade, tuttavia se l'utente non accetta i cookie / cancella i cookie / cambia il browser / cambia il dispositivo, non verrà più riconosciuto

IP possono essere condivisi tra diversi utenti (immagina un caffè wi-fi gratuito o il tuo ISP che riassegna gli IP) e spesso avranno almeno 2, a casa e al lavoro.

User_agentè la versione browser + sistema operativo, che consente di distinguere tra dispositivi. Ad esempio, è probabile che un utente utilizzi sia il telefono che il laptop, ma è improbabile che utilizzi Windows + laptop Apple. È improbabile che lo stesso ID di sessione abbia più useragent.

I dati potrebbero apparire come il violino qui: http://sqlfiddle.com/#!2/c4de40/1

Certo, stiamo parlando di ipotesi, ma si tratta di avvicinarsi il più possibile alla realtà. Ad esempio, se incontriamo lo stesso ip e useragent in un periodo di tempo limitato con un session_id diverso, sarebbe ragionevole supporre che si tratti dello stesso utente, con alcune eccezioni edge case.

Modifica: la lingua in cui viene risolto il problema è irrilevante, riguarda principalmente la logica e non l'implementazione. Lo pseudocodice va bene.

Modifica: a causa della natura lenta del violino, puoi alternativamente leggere / eseguire il 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

Una possibilità qui (e questa è davvero un'estensione di ciò che Sean Owen ha pubblicato) è quella di definire un "utente stabile".

Per le informazioni che hai puoi immaginare di creare un user_id che sia un hash di ip e alcune informazioni dell'agente utente (pseudo codice):

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

Quindi contrassegni questi ID con "stabile" o "instabile" in base all'euristica di utilizzo che osservi per i tuoi utenti. Questa può essere una soglia di n. Di visite in una determinata finestra temporale, la durata del tempo in cui i loro cookie persistono, alcune azioni finali sul tuo sito (mi rendo conto che questo non è stato indicato nel log originale), ecc ...

L'idea qui è quella di separare gli utenti che non rilasciano i cookie da quelli che lo fanno.

Da qui puoi attribuire session_ids a uids stabili dai tuoi log. Avrai quindi lasciato "session_ids" per utenti instabili di cui non sei relativamente sicuro. Potresti avere più o meno conteggi delle sessioni, attribuire il comportamento a più persone quando ce n'è solo una, ecc ... Ma questo è almeno limitato agli utenti di cui ora sei "meno sicuro".

Quindi si eseguono analisi sul proprio gruppo stabile e lo si proietta sul gruppo instabile. Prendi ad esempio un conteggio degli utenti, conosci il numero totale di sessioni, ma non sei sicuro di quanti utenti abbiano generato quelle sessioni. Puoi trovare # sessioni / utente unico stabile e usarlo per proiettare il numero "stimato" di utenti unici nel gruppo instabile poiché conosci il numero di sessioni attribuite a quel gruppo.

projected_num_unstable_users = num_sess_unstable / num_sess_per_stable_uid

Questo non aiuta con le indagini a livello di utente su utenti instabili, ma puoi almeno ottenere un chilometraggio da una coorte di utenti stabili che persistono per qualche tempo. È possibile, con vari metodi, proiettare comportamenti e conteggi nel gruppo instabile. Quanto sopra è un semplice esempio di qualcosa che potresti voler sapere. L'idea generale è di nuovo di definire un insieme di utenti di cui si è certi che persistano, misurare ciò che si desidera misurare e utilizzare determinate verità di base (ricerche numeriche, visite, clic, ecc ...) per proiettare nello spazio utente sconosciuto e stimare conta per loro.

Questo è un problema di vecchia data nel conteggio degli utenti unici, registrazione, ecc ... per i servizi che non richiedono l'accesso.

Non c'è molto che puoi fare solo con questi dati, ma quel poco che puoi fare non si basa sull'apprendimento automatico.

Sì, sessioni dallo stesso IP ma diversi User-Agent sono quasi certamente utenti distinti. Le sessioni con lo stesso IP e User-Agent sono in genere lo stesso utente, tranne nel caso di proxy / punti di accesso wi-fi. Quelli che potresti identificare guardando la distribuzione del conteggio delle sessioni per IP per identificare probabili IP "aggregati". Le sessioni dello stesso IP / User-Agent che si sovrappongono nel tempo sono quasi sicuramente distinte.

Per distinguere ulteriormente gli utenti avrai bisogno di maggiori informazioni. Ad esempio, i siti o gli indirizzi IP a cui l'utente si sta connettendo sarebbe una base molto solida per differenziare le sessioni. Quindi potresti entrare in un apprendimento più sofisticato per capire quando le sessioni sono gli stessi o diversi utenti.