Pregunta

Los datos dado acceso web en forma session_id, ip, user_agent, y opcionalmente marca de tiempo, siguiendo las siguientes condiciones, ¿cómo te mejores racimo en las sesiones de visitantes únicos?

session_id: es un identificador dado a cada nuevo visitante. No expira, sin embargo, si el usuario no acepta cookies / suprime las cookies / navegador cambia / cambia de dispositivo, no será reconocido más

IP puede ser compartida entre los diferentes usuarios (Imagínese un café wi-fi libre, o su ISP reasignación de direcciones IP), y que a menudo tendrá al menos 2, casa y trabajo.

User_agent es la versión del navegador + OS, lo que permite distinguir entre dispositivos. Por ejemplo, un usuario es probable que utilice tanto el teléfono y un ordenador portátil, pero es poco probable que utilicen ventanas + portátiles de Apple. Es poco probable que el mismo identificador de sesión tiene múltiples AgentesDeUsuario.

Los datos puede tener un aspecto como el violín aquí: http://sqlfiddle.com/#!2/c4de40/1

Por supuesto, estamos hablando de suposiciones, pero se trata de conseguir lo más cercano posible a la realidad. Por ejemplo, si nos encontramos con la misma IP y agente de usuario en un marco de tiempo limitado con un session_id diferente, sería razonable suponer que es el mismo usuario, con algunas excepciones de casos de borde.

Editar: Idioma en el que se resuelve el problema es irellevant, es sobre todo acerca de la lógica y de no aplicación. Pseudocódigo está muy bien.

Editar: debido a la naturaleza lenta del violín, alternativamente puede leer / ejecutar el 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
¿Fue útil?

Solución

Una posibilidad aquí (y esto es realmente una extensión de lo que Sean Owen publicado) es definir un "usuario estable."

Para la información dada que tiene se puede imaginar haciendo un user_id que es un hash de IP y algo de información de agente de usuario (pseudo código):

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

A continuación, se marca con estos identificadores de "estable" o "inestable", basada en la heurística de uso que observa para sus usuarios. Esto puede ser un umbral de # de visitas en una ventana de tiempo dado, la longitud de tiempo que sus galletas persisten, alguna acción final en su sitio (que dan cuenta de esto no se mencionó en el registro original), etc ...

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

Desde aquí se puede atribuir a session_ids líquidos estables de sus registros. A continuación, habrá "sobrantes" session_ids para usuarios inestables que son relativamente seguros acerca. Usted puede estar encima o debajo de las sesiones de conteo, la atribución de un comportamiento a varias personas cuando sólo hay uno, etc ... Pero esto es, al menos, limitada a los usuarios de las cuales ahora "menos seguro" acerca de.

A continuación, realiza análisis de su grupo estable y proyecto que al grupo inestable. Tomar un número de usuarios, por ejemplo, se conoce el # total de sesiones, pero no está seguro de cuántos usuarios generada esas sesiones. Usted puede encontrar el usuario / estable única sesiones # y usar esto para proyectar el número "estimado" de usuarios únicos en el grupo inestable ya que se 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 usuario de nivel en usuarios inestables, pero al menos puedes conseguir algo de provecho de una cohorte de usuarios estables que persisten durante algún tiempo. Se puede, por varios métodos, el comportamiento del proyecto y los recuentos en el grupo inestable. Lo anterior es un ejemplo sencillo de algo que podría querer saber. La idea general es de nuevo para definir un conjunto de usuarios a los que se tiene la certeza persisten, mida lo que se desea medir, y el uso de ciertas verdades de tierra (num búsquedas, visitas, clics, etc ...) para proyectarse en el espacio de usuario desconocido y estimación conteos para ellos.

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

Otros consejos

No hay mucho que puede hacer con sólo estos datos, pero lo poco que puede hacer no se basa en el aprendizaje automático.

Sí, sesiones desde la misma IP, pero diferentes User-Agents son casi con toda seguridad a los usuarios distintos. Las sesiones con la misma IP y el agente de usuario por lo general son el mismo usuario, excepto en el caso de las delegaciones puntos de acceso / Wi-Fi. Aquellos que pueden identificar observando la distribución de número de sesiones por IP para identificar probables de los PI agregada. Sesiones desde la misma IP / User-Agent que se solapan en el tiempo son casi seguramente distinto.

A fin de distinguir a los usuarios que se necesita más información. Por ejemplo, los sitios o direcciones IP que se conecta el usuario a que sería una base muy fuerte para la diferenciación de las sesiones. Posteriormente, se podría llegar a un aprendizaje más sofisticada de averiguar cuando las sesiones son los mismos o diferentes usuarios.

Licenciado bajo: CC-BY-SA con atribución
scroll top