Gruppieren eindeutiger Besucher nach Useragent, IP, Sitzungs-ID

Wenn Sie die Zugriffsdaten für die Website im Formular session_id, ip, user_agentund optional den Zeitstempel gemäß den folgenden Bedingungen angegeben haben, wie würden Sie die Sitzungen am besten zu eindeutigen Besuchern zusammenfassen?

session_id: ist ein Ausweis, der jedem neuen Besucher ausgehändigt wird. Es verfällt jedoch nicht, wenn der Benutzer keine Cookies akzeptiert / Cookies löscht / den Browser ändert / das Gerät ändert, wird er nicht mehr erkannt

IP kann zwischen verschiedenen Benutzern geteilt werden (Stellen Sie sich ein kostenloses Wi-Fi-Café oder Ihren ISP vor, der IPs neu zuweist), und sie haben oft mindestens 2, zu Hause und am Arbeitsplatz.

User_agentist die Browser- und Betriebssystemversion, mit der zwischen Geräten unterschieden werden kann. Beispielsweise wird ein Benutzer wahrscheinlich sowohl ein Telefon als auch einen Laptop verwenden, es ist jedoch unwahrscheinlich, dass er Windows + Apple-Laptops verwendet. Es ist unwahrscheinlich, dass dieselbe Sitzungs-ID mehrere Benutzeragenten hat.

Daten könnten hier wie die Geige aussehen: http://sqlfiddle.com/#!2/c4de40/1

Natürlich sprechen wir über Annahmen, aber es geht darum, der Realität so nahe wie möglich zu kommen. Wenn beispielsweise in einem begrenzten Zeitraum dieselbe IP-Adresse und derselbe Benutzeragent mit einer anderen Sitzungs-ID auftreten, ist die Annahme gerechtfertigt, dass es sich um denselben Benutzer handelt, abgesehen von einigen Ausnahmefällen.

Bearbeiten: Sprache, in der das Problem gelöst wird, ist irellevant, es geht hauptsächlich um Logik und nicht um Implementierung. Pseudocode ist in Ordnung.

Bearbeiten: Aufgrund der langsamen Natur der Geige können Sie alternativ die mysql lesen / ausführen:

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

Eine Möglichkeit hier (und dies ist wirklich eine Erweiterung dessen, was Sean Owen gepostet hat) ist, einen "stabilen Benutzer" zu definieren.

Für die angegebenen Informationen können Sie sich vorstellen, eine user_id zu erstellen, die ein Hash von ip und einige Benutzeragenteninformationen (Pseudocode) ist:

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

Dann kennzeichnen Sie diese IDs mit "stabil" oder "instabil", basierend auf den Nutzungsheuristiken, die Sie für Ihre Benutzer beobachten. Dies kann ein Schwellenwert für die Anzahl der Besuche in einem bestimmten Zeitfenster, die Dauer der Speicherung der Cookies, einige Endaktionen auf Ihrer Website (dies wurde meines Erachtens nicht in Ihrem ursprünglichen Protokoll angegeben) usw. sein.

Die Idee dabei ist, die Benutzer, die keine Cookies ablegen, von denen zu trennen, die Cookies ablegen.

Von hier aus können Sie session_ids stabilen Benutzer-IDs aus Ihren Protokollen zuordnen. Sie haben dann session_ids für instabile Benutzer "übrig", bei denen Sie sich relativ unsicher sind. Möglicherweise sind Sie über- oder unterzählt und weisen mehreren Personen Verhalten zu, wenn nur eine Person vorhanden ist usw. Dies ist jedoch zumindest auf die Benutzer beschränkt, bei denen Sie sich "weniger sicher" sind.

Anschließend führen Sie Analysen für Ihre stabile Gruppe durch und projizieren diese für die instabile Gruppe. Wenn Sie beispielsweise die Anzahl der Benutzer angeben, kennen Sie die Gesamtanzahl der Sitzungen, sind sich jedoch nicht sicher, wie viele Benutzer diese Sitzungen generiert haben. Sie können den Benutzer # sessions / unique stable finden und damit die "geschätzte" Anzahl eindeutiger Benutzer in der instabilen Gruppe projizieren, da Sie die Anzahl der Sitzungen kennen, die dieser Gruppe zugeordnet sind.

projected_num_unstable_users = num_sess_unstable / num_sess_per_stable_uid

Dies hilft nicht bei der Untersuchung instabiler Benutzer auf Benutzerebene, aber Sie können zumindest einige Meilen aus einer Kohorte stabiler Benutzer herausholen, die für einige Zeit bestehen bleiben. Sie können mit verschiedenen Methoden das Verhalten von Projekten und das Zählen in die instabile Gruppe festlegen. Das Obige ist ein einfaches Beispiel für etwas, das Sie vielleicht wissen möchten. Die allgemeine Idee ist es, eine Gruppe von Benutzern zu definieren, von denen Sie sicher sind, dass sie bestehen bleiben, zu messen, was Sie messen möchten, und bestimmte Grundwahrheiten (Anzahl Suchen, Besuche, Klicks usw.) zu verwenden, um in den unbekannten Benutzerbereich zu projizieren und zu schätzen zählt für sie.

Dies ist ein seit langem bestehendes Problem bei der Zählung, Protokollierung usw. eindeutiger Benutzer für Dienste, für die keine Anmeldung erforderlich ist.

Mit diesen Daten können Sie nicht viel anfangen, aber was Sie tun können, hängt nicht vom maschinellen Lernen ab.

Ja, Sitzungen mit derselben IP, aber unterschiedlichen Benutzeragenten sind mit ziemlicher Sicherheit unterschiedliche Benutzer. Sitzungen mit derselben IP und demselben User-Agent sind normalerweise derselbe Benutzer, mit Ausnahme von Proxies / Wi-Fi-Zugangspunkten. Diese können Sie anhand der Verteilung der Sitzungsanzahl pro IP identifizieren, um wahrscheinliche "aggregierte" IPs zu identifizieren. Sitzungen desselben IP / User-Agents, die sich zeitlich überschneiden, sind mit ziemlicher Sicherheit unterschiedlich.

Zur weiteren Unterscheidung von Benutzern benötigen Sie weitere Informationen. Beispielsweise sind die Sites oder IP-Adressen, mit denen der Benutzer eine Verbindung herstellt, eine sehr starke Basis für die Unterscheidung von Sitzungen. Dann könnten Sie sich in anspruchsvollere Lernprozesse einarbeiten, um herauszufinden, wann Sitzungen von denselben oder unterschiedlichen Benutzern durchgeführt werden.