Clustering visiteurs uniques par useragent, ip, id_session

Question

Compte tenu des données d'accès du site sous forme session_id, ip, user_agent, et éventuellement horodatage, suivant les conditions ci-dessous, comment voulez-vous mieux regrouper les sessions en visiteurs uniques?

session_id: est un identifiant donné à chaque nouveau visiteur. Il ne prend pas fin, si l'utilisateur n'accepte pas les cookies / Efface les cookies / navigateur change / change périphérique, il ne sera pas reconnu plus

IP peut être partagé entre les différents utilisateurs (Imaginez un café wi-fi gratuit ou votre fournisseur d'accès réaffectant IP), et ils ont souvent au moins 2, la maison et le travail.

User_agent est le navigateur + version OS, ce qui permet de faire la distinction entre les appareils. Par exemple, un utilisateur est susceptible d'utiliser le téléphone et un ordinateur portable, mais il est peu probable d'utiliser des fenêtres + ordinateurs portables Apple. Il est peu probable que le même identifiant de session a plusieurs useragents.

Les données peuvent se présenter comme le violon ici: http://sqlfiddle.com/#!2/c4de40/1

Bien sûr, nous parlons d'hypothèses, mais il est à obtenir le plus près possible de la réalité. Par exemple, si nous rencontrons la même adresse IP et useragent dans un laps de temps limité avec un id_session différent, ce serait une hypothèse juste que c'est le même utilisateur, à quelques exceptions de cas limite.

Edit: Langue dans laquelle le problème est résolu est irellevant, il est la plupart du temps sur la logique et non mise en œuvre. Pseudocode est très bien.

Edit: en raison de la lenteur du violon, vous pouvez également lire / exécuter le 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

Answer 1

Une possibilité ici (ce qui est vraiment une extension de ce que Sean Owen a affiché) est de définir un « utilisateur stable ».

Pour les informations que vous avez donné, vous pouvez imaginer faire un user_id qui est un hachage de la propriété intellectuelle et quelques informations de l'agent utilisateur (pseudo code):

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

Ensuite, vous marquez ces ids avec « stable » ou « instable » basée sur des heuristiques d'utilisation que vous observez pour vos utilisateurs. Cela peut être un seuil de nombre de visites dans une fenêtre de temps donné, la durée de leurs cookies persistent, une action de fin sur votre site (je me rends compte cela n'a pas été déclaré dans votre journal d'origine), etc ...

L'idée ici est de séparer les utilisateurs qui ne laissez pas tomber les cookies de ceux qui le font.

De là, vous pouvez attribuer à session_ids uids stables de vos journaux. Vous aurez alors la « gauche » sur session_ids pour les utilisateurs instables que vous êtes relativement incertain au sujet. Vous pouvez être plus ou moins des séances de comptage, en attribuant un comportement à plusieurs personnes quand il n'y a qu'un seul, etc ... Mais cela est au moins limitée aux utilisateurs que vous êtes maintenant « moins sûr » au sujet.

Vous effectuez ensuite des analyses sur votre groupe stable et projet au groupe instable. Prenez un nombre d'utilisateurs par exemple, vous connaissez le # total de sessions, mais vous n'êtes pas sûr de combien d'utilisateurs générés ces sessions. Vous pouvez trouver l'utilisateur stable # sessions / unique et l'utiliser pour projeter le nombre « estimé » d'utilisateurs uniques dans le groupe instable puisque vous connaissez le nombre de sessions attribuées à ce groupe.

projected_num_unstable_users = num_sess_unstable / num_sess_per_stable_uid

Cela ne aide par une enquête de niveau utilisateur sur les utilisateurs instables mais vous pouvez au moins obtenir un certain kilométrage d'une cohorte d'utilisateurs stables qui persistent pendant un certain temps. Vous pouvez, par différentes méthodes, le comportement du projet et compte dans le groupe instable. Ce qui précède est un exemple simple de quelque chose que vous pourriez vouloir savoir. L'idée générale est à nouveau de définir un ensemble d'utilisateurs que vous êtes confiant persistez, mesurez ce que vous voulez mesurer et utiliser certaines vérités terrestres (recherches num, des visites, des clics, etc ...) pour se projeter dans l'espace utilisateur inconnu et estimation compte pour eux.

Ceci est un problème de longue date dans le comptage d'utilisateur unique, l'exploitation forestière, etc ... pour les services qui ne nécessitent pas se connecter.

Answer 2

Il n'y a pas grand-chose que vous pouvez faire avec juste ces données, mais ce peu que vous pouvez faire ne repose pas sur l'apprentissage de la machine.

Oui, les sessions de la même adresse IP, mais différents User-Agents sont presque certainement des utilisateurs distincts. Sessions avec la même adresse IP et User-Agent sont généralement le même utilisateur, sauf dans le cas des procurations / wi-fi points d'accès. Ceux que vous pourriez identifier en regardant la distribution de nombre de sessions par IP pour identifier les adresses IP probables « globaux ». Sessions de la même adresse IP / User-Agent qui se chevauchent dans le temps sont presque sûrement distinctes.

Pour distinguer davantage les utilisateurs que vous auriez besoin de plus d'informations. Par exemple, les sites ou adresses IP que l'utilisateur se connecte à une base serait très forte pour différencier les sessions. Ensuite, vous pouvez entrer dans un apprentissage plus sophistiqué pour savoir quand les sessions sont les utilisateurs identiques ou différents.