Agrupación de visitantes únicos por useragent, ip, session_id

Dados los datos de acceso al sitio web en el formulario session_id, ip, user_agent, y opcionalmente la marca de tiempo, siguiendo las condiciones a continuación, ¿cómo agruparía mejor las sesiones en visitantes únicos?

session_id: es una identificación dada a cada nuevo visitante. No caduca, sin embargo, si el usuario no acepta cookies / borra cookies / cambia el navegador / cambia el dispositivo, ya no será reconocido

IP se pueden compartir entre diferentes usuarios (imagine un café con wifi gratuito o su ISP reasignando IP), y a menudo tendrán al menos 2, hogar y trabajo.

User_agentes la versión del navegador + SO, lo que permite distinguir entre dispositivos. Por ejemplo, es probable que un usuario use tanto el teléfono como la computadora portátil, pero es poco probable que use computadoras portátiles Windows + Apple. Es poco probable que la misma ID de sesión tenga múltiples agentes de uso.

Los datos pueden verse como el violín aquí: http://sqlfiddle.com/#!2/c4de40/1

Por supuesto, estamos hablando de suposiciones, pero se trata de acercarse lo más posible a la realidad. Por ejemplo, si encontramos la misma ip y useragent en un período de tiempo limitado con un session_id diferente, sería una suposición justa que es el mismo usuario, con algunas excepciones de casos extremos.

Editar: El lenguaje en el que se resuelve el problema es irrelevante, se trata principalmente de lógica y no de implementación. El pseudocódigo está bien.

Editar: debido a la naturaleza lenta del violín, también puede leer / ejecutar 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 posibilidad aquí (y esto es realmente una extensión de lo que Sean Owen publicó) es definir un "usuario estable".

Para la información dada que tiene, puede imaginarse creando un user_id que sea un hash de ip y alguna información de agente de usuario (pseudocódigo):

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

Luego marca estos identificadores con "estable" o "inestable" según las heurísticas de uso que observe para sus usuarios. Esto puede ser un umbral de # de visitas en un período de tiempo determinado, el tiempo que persisten sus cookies, alguna acción final en su sitio (me doy cuenta de que esto no se indicó en su registro original), etc.

La idea aquí es separar a los usuarios que no eliminan las cookies de los que sí lo hacen.

Desde aquí puede atribuir session_ids a uids estables de sus registros. A continuación, tendrá "session_ids" restantes para usuarios inestables de los que está relativamente inseguro. Puede estar sobre o debajo de las sesiones de conteo, atribuyendo el comportamiento a varias personas cuando solo hay una, etc. Pero esto se limita al menos a los usuarios de los que ahora está "menos seguro".

Luego realiza análisis en su grupo estable y lo proyecta al grupo inestable. Tome un recuento de usuarios, por ejemplo, conoce el número total de sesiones, pero no está seguro de cuántos usuarios generaron esas sesiones. Puede encontrar las # sesiones / usuario estable único y utilizarlo para proyectar el número "estimado" de usuarios únicos en el grupo inestable ya que conoce el número de sesiones atribuidas a ese grupo.

projected_num_unstable_users = num_sess_unstable / num_sess_per_stable_uid

Esto no ayuda con la investigación por nivel de usuario en usuarios inestables, pero al menos puede obtener algo de kilometraje de una cohorte de usuarios estables que persisten durante algún tiempo. Puede, mediante varios métodos, proyectar el comportamiento y los recuentos en el grupo inestable. Lo anterior es un ejemplo simple de algo que quizás desee saber. La idea general es nuevamente definir un conjunto de usuarios en los que confía persistir, medir lo que desea medir y usar ciertas verdades básicas (búsquedas numéricas, visitas, clics, etc.) para proyectar en el espacio de usuario desconocido y estimar cuenta para ellos.

Este es un problema de larga data en el conteo único de usuarios, el registro, etc. para servicios que no requieren iniciar sesión.

No puede hacer mucho con solo estos datos, pero lo poco que puede hacer no depende del aprendizaje automático.

Sí, las sesiones de la misma IP pero diferentes User-Agents son casi seguramente usuarios distintos. Las sesiones con la misma IP y User-Agent suelen ser el mismo usuario, excepto en el caso de proxies / puntos de acceso wi-fi. Aquellos que pueda identificar observando la distribución del recuento de sesiones por IP para identificar posibles IP 'agregadas'. Las sesiones del mismo IP / User-Agent que se superponen en el tiempo son casi seguramente distintas.

Para distinguir aún más a los usuarios, necesitaría más información. Por ejemplo, los sitios o las direcciones IP a las que se conecta el usuario serían una base muy sólida para diferenciar las sesiones. Entonces podría entrar en un aprendizaje más sofisticado para descubrir cuándo las sesiones son los mismos o diferentes usuarios.