useragent、ip、session_idによる一意の訪問者のクラスタリング

フォームのWebサイトアクセスデータsession_id, ip, user_agent、およびオプションでタイムスタンプを使用して、以下の条件に従って、セッションを一意の訪問者にどのようにクラスター化するのが最適ですか？

session_id：は、すべての新しい訪問者に与えられるIDです。有効期限はありませんが、ユーザーがCookieを受け入れない/ Cookieをクリアする/ブラウザーを変更する/デバイスを変更すると、ユーザーは認識されなくなります

IP 異なるユーザー間で共有することができ（無料のwi-fiカフェ、またはISPがIPを再割り当てすることを想像してください）、多くの場合、少なくとも2人の自宅と職場があります。

User_agentブラウザとOSのバージョンであり、デバイスを区別できます。たとえば、ユーザーは電話とラップトップの両方を使用する可能性がありますが、windows + appleラップトップを使用する可能性は低いです。同じセッションIDに複数のユーザーエージェントが存在することはほとんどありません。

データはフィドルのように見えるかもしれません：http ://sqlfiddle.com/#!2/ c4de40/1

もちろん、私たちは仮定について話していますが、それは可能な限り現実に近づくことです。たとえば、セッションIDが異なる限られた時間枠で同じipとuseragentに遭遇した場合、エッジケースの例外を除いて、それは同じユーザーであるという公正な仮定になります。

編集：問題が解決される言語は無関係であり、それは主に実装ではなくロジックに関するものです。擬似コードは問題ありません。

編集：フィドルの遅い性質のため、代わりに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

ここでの1つの可能性（そして、これはSean Owenが投稿したものの拡張です）は、「安定したユーザー」を定義することです。

与えられた情報に対して、ipのハッシュであるuser_idとユーザーエージェント情報（擬似コード）を作成することを想像できます。

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

次に、これらのIDに、ユーザーに対して観察される使用法に基づいて、「安定」または「不安定」のフラグを立てます。これは、特定の時間枠での訪問数のしきい値、Cookieが保持される期間、サイトでの何らかの終了アクション（これは元のログに記載されていなかったことがわかります）などです。

ここでの考え方は、Cookieをドロップしないユーザーと、Cookieをドロップしないユーザーを区別することです。

ここから、ログからsession_idsを安定したuidに関連付けることができます。そうすると、比較的不確かな不安定なユーザーのためにsession_idを「残す」ことになります。セッションのカウントが多すぎたり少なすぎたり、1人しかいない場合に複数の人に行動を帰属させたりする場合があります。しかし、これは少なくとも「今はよくわからない」ユーザーに限定されます。

次に、安定したグループで分析を実行し、それを不安定なグループに投影します。たとえば、ユーザー数を考えてみましょう。セッションの総数はわかっていますが、それらのセッションを生成したユーザーの数はわかりません。＃セッション/一意の安定したユーザーを見つけ、これを使用して、不安定なグループの一意のユーザーの「推定」数を予測できます。これは、そのグループに属するセッションの数がわかっているためです。

projected_num_unstable_users = num_sess_unstable / num_sess_per_stable_uid

これは不安定なユーザーのユーザーごとのレベルの調査には役立ちませんが、少なくとも一定期間持続する安定したユーザーのコホートから少なくともある程度の距離を得ることができます。さまざまな方法で、振る舞いやプロジェクトを不安定なグループに含めることができます。上記は、あなたが知りたいことの簡単な例です。一般的な考え方は、自信のあるユーザーのセットを定義し、測定したいものを測定し、特定のグラウンドトゥルース（検索数、訪問数、クリック数など）を使用して未知のユーザー空間に投影し、推定することです。それらのためにカウントします。

これは、ログインを必要としないサービスのユニークユーザーのカウント、ロギングなどにおける長年の問題です。

このデータだけではできることはあまりありませんが、できることは機械学習だけではありません。

はい、同じIPで異なるユーザーエージェントからのセッションは、ほぼ確実に別個のユーザーです。プロキシ/ Wi-Fiアクセスポイントの場合を除き、同じIPとUser-Agentを持つセッションは通常同じユーザーです。IPごとのセッションカウントの分布を調べて、「集約」IPの可能性があるものを特定することにより、それらを特定できます。時間的に重複する同じIP / User-Agentからのセッションは、ほぼ確実に区別されます。

ユーザーをさらに区別するには、さらに情報が必要です。たとえば、ユーザーが接続しているサイトまたはIPアドレスは、セッションを区別するための非常に強力な基盤となります。その後、セッションが同じユーザーであるか異なるユーザーであるかを把握するために、より高度な学習を始めることができます。