PVからセッションへ
uqid が意味を持った日

数字はあった。でも、何も分からなかった

前回、アクセスログに uqid を後から足しました。 最初は「毎アクセスにユニークなIDを振る」だけのもの。ログは溜まり、PV数も出ます。

ところが、肝心のことが分かりませんでした。「何人が来たのか」「ちゃんと読まれたのか」「すぐ帰ったのか」。 数字はあるのに、意味が無い。この停滞から抜け出すには、たった1つの発想の転換が必要でした。

「表示回数」だけでは、つぶれて見える

PV（ページビュー）は「ページが表示された回数」です。ここに落とし穴があります。 1人が10ページ見ても、10人が1ページずつ見ても、同じ10PV。まったく違う状況が、同じ数字に潰れます。

だから PV だけでは、訪問者数も、1人あたりの回遊も、すぐ帰ったかどうかも見えません。 そして毎アクセスに新しい uqid を振っていた頃は、その uqid も同罪でした。アクセスごとに別IDでは、 結局PVと同じ粒度。「同じ人」が繋がらないのです。

uqid を「セッション」に変える

発想を変えます。uqid を毎回振るのをやめ、同じ訪問者には、同じIDを一定時間持たせる。 そして「ひとまとまりの訪問」を1単位として数える——これがセッションです。

定義はシンプル。最後のアクセスから60分間、無操作が続いたら失効。次に来たら新しいセッション。 実装も、最終アクセス時刻を覚えておいて「今 − 最終 > 60分」で判定するだけです。

const TIMEOUT = 60 * 60 * 1000;   // 60分

function resolveSession(uqid, now){
  const last = store.get(uqid);            // 最終アクセス時刻
  if (!last || now - last > TIMEOUT){    // 60分無操作 → 新セッション
    store.newSession(uqid);
  }
  store.touch(uqid, now);               // 最終アクセスを更新
  return store.sessionId(uqid);
}

まとまりが、数字を生む

セッションという「まとまり」ができて初めて、計算できるようになった指標が3つあります。

ユニーク訪問者数

重複しない uqid の数。「何人来たか」が初めて分かります。PVでは決して出せなかった数字です。

PV / セッション

総PV ÷ セッション数。「1回の訪問で何ページ回ったか」——回遊の深さです。サイトの中を歩いてもらえたか。

直帰率

1ページだけ見て帰ったセッションの割合。「入口で満足せずに去ったか」——コンテンツの掴みが分かります。

3つとも、セッションという単位がなければ計算すらできなかった指標です。

生ログが、セッションになる

生のアクセスログ（時刻・uqid・uri）を、失効ルールで束ねます。失効時間スライダーを動かすと、 同じ訪問者でも無操作が続けば別セッションに割れ、指標が連動して動くのが見えます。

失効時間を短くするほど、1人の訪問が複数セッションに分断され、セッション数と直帰率が上がり、 PV/セッションは下がります。ユニーク訪問者数と総PVは変わりません—— 同じ生ログでも、セッションの定義しだいで、見える景色が変わるのです。

セッションは、近似である

失効時間は、何分が正解か

デモで見たとおり、失効時間は指標を直接動かします。短すぎると1つの訪問が分断され、 長すぎると別の訪問が繋がってしまう。一般的な慣習と、回遊のリズムを見て60分を選びました。 唯一の正解はなく、「何を1訪問とみなすか」という設計判断です。

Cookie拒否・共有IP — 完璧は狙わない

uqid が取れない、あるいは複数人で被ることもあります。セッションは個人の完璧な特定ではなく、 実用的な近似と割り切ります。傾向を読むには、それで十分です。

bot は、セッションから除く

ここで1本目の bot フラグが効きます。ボットのアクセスを混ぜると、回遊も直帰率も歪む。 だから指標を出す前に、ボットを除外します。「誰を数えるか」を絞ることも、分析の一部です。 ——では、そのボットや攻撃者を、どうやって見分けるのか。それが次回の主題です。