ウェブサイトのユーザー行動分析のための仕組みについて考察する(1)

はじめに

エンジニアの松原です。一時期ホームページなどでアクセスログやユーザーの行動履歴を収集、解析するためにGoogle Analyticsを活用することが流行っていましたが、私自身は実際は裏側で動いている仕組み自体を知らないまま使っていました。
以前日本では一時期ビックデータ呼ばれていたものの例の一つにアクセスログやユーザーの行動履歴も含まれていました。仕事でクラウドサービスを使うようになり、最近まではクラウドサービス上の開発に興味関心が移っていたため、アクセスログのデータがどのように作ればよいかあまり考えてきませんでした。
AWSにも AthenaQuickSight などのサービスがあり、サービスを連携させることによってほぼGoogle Analyticsと同様な解析ができるようになりました。
今回はアクセスログやユーザーの行動履歴について、一から作ってみたい場合にオレオレ仕様での仕組みを考えてみました。今回は特定のページに対するアクセス解析はどのようにできそうか、またそのデータを解析するためにどんな種類のデータがサーバーに保存されるか考えてみました。

ホームページ構成とそのグラフ構造

ホームページの構成を概念化する際、画面遷移(状態遷移)をベースにするとわかりやすいようです。また、状態遷移に関して理論立てる方法として、一般的にはグラフ構造(状態遷移図)で表すことで分かりやすくなります。
例としてSynamonのテックブログのサイトは大きく分けて3つの構造を持っています。

  • ホーム画面(またはトップページ)
  • 記事一覧画面
  • 個別の記事の画面

さらに外部からテックブログのアクセスをトリガーする、外部のウェブサイトやSNSの画面を含めた4構成になっています。トップページや記事一覧画面以外は厳密には特定、不特定含めて多数存在するため、それぞれ Zn(Z1, Z2, ..., Zn)Cn(C1, C2, ..., Cn) 、また特定の記事画面を Cp と表現しています。

ここからは画面遷移の図をベースにアクセス解析やユーザー行動についていくつかの定義を整理してみます。

特定の記事への画面遷移のパターン

先ほどのグラフの図を分解して、特定の記事へユーザーがアクセスする方法をいくつかの画面遷移のパターンに分解してみます。主に5つのパターンが考えられます。最後は具体的な画面遷移が発生しないパターンになっています。

  • ホーム画面からその記事にアクセス
  • 記事一覧画面からその記事にアクセス
  • 外部サイトの画面(埋め込まれたリンク)からその記事にアクセス
  • 同サイトの別の記事(埋め込まれたリンク)からその記事にアクセス
  • ブラウザのブックマーク機能か、URL直打ちからその記事にアクセス

実際はこのようなシンプルなものだけではなく、これらのパターンが組み合わさり、以下のように複数の画面遷移を経て特定の記事にアクセスされるケースが多いかと思います。

アクセスログを取得する方法

アクセスログ自体は、特定のページにアクセスしたという記録があればサーバーに残っていれば後から解析できますが、画面遷移の導線をたどるためにアクセスログを利用したい場合は、 どこからそのページに遷移してきたか という遷移元の情報を取得することで再現できます。
具体的な方法としてはHTTPヘッダーに含まれるリファラを利用することで遷移元の情報をURLという形で取ることができます。ただし、遷移元と遷移先のドメインの異なる場合、プライバシーやセキュリティの面からURLの一部しか提供されないケースがあります。
下図のように、リファラから簡単な画面遷移のパターンを探ることができます。

リファラを利用する以外にも取りうる方法(Cookieを利用するなど)はありますが、今回の記事の本質ではないので割愛します。

また、これらのユーザー行動に伴う画面遷移に関して、ユーザー毎の特定時間範囲での行動を一般的にセッションと名付けられていることがあります。 アクセスログからセッション単位のユーザーの行動履歴を最低限分析することはできるようになりますが、以下の課題があります。

複数記事への画面遷移を伴った状態の課題

見出しがややこしいですが、ある特定の記事へユーザーがアクセスした場合、セッションの前後関係でその記事に興味を持っているかどうかわからないケースがあります。以下の図で表します。
この図では、ユーザーの遷移前と遷移後のサイトへのアクセスログのみではどの記事を目的としてサイトを訪れているかわからない二つのケースを示しています。
一つ目はユーザーが1回のセッションで分析対象の記事画面より前に複数の記事を参照しているケースです。二つ目は同じセッションで分析対象の記事画面以外の記事にもアクセスしているケースです。

遷移前と遷移後のサイトの情報だけだと、これ以上の分析が行えないので、ほかの情報もユーザー行動として含めて記録しておく必要があります。

滞在時間、読了率、PV数について

画面ごとの 滞在時間読了率PV(ページビュー)数 をユーザー行動として記録しておくことで、後で分析する際に役に立つケースがあります。
滞在時間 はその画面にユーザーが何秒留まっていたかを記録しており、「興味関心がないものであれば滞在時間は低いだろう」という仮説を元に記録することが多いかと思います。
読了率 は対象の記事の内容がユーザーにどれぐらいの量を読まれたかを記録します。実装方法の例として、その記事の開始から終了までの画面スクロール範囲と、実際にユーザーがスクロールした範囲などを取得することで「記事中の範囲はユーザーが見ているので興味関心を持っているだろう」という仮説を元に読了率を定めています。
PV数 はそのページが 秒/分/時/日/週/年 単位ごとにどれぐらいアクセスされたかを記録したものです。PV数に関しては仮説ではなく実測値のため、扱いやすくはありますが、組み合わせて利用することによってより分析に役立てることができます。

以下にこれらの利用例を挙げます。

滞在時間、読了率からユーザーの興味関心を読み取る

先ほどの課題を例にしてみます。1回のセッションで複数の記事を表示している場合、ユーザーの行動の目的がどこにあるかわからない場合があります。ここに滞在時間や読了率を含めて比較することで見えてくる傾向があります。
基本的には先ほどの仮説の通り、滞在時間と読了率が高い記事のページがユーザー関心があると重み付けをし、1回のセッションでの対象の記事とその他の記事の滞在時間と読了率を比較することである程度目安を作ることができます。
ただし、1ユーザーのみのセッションを単純に比較するのは意味が薄く、ほかのユーザーのセッションも含めて比較する必要があるため、複数のユーザーのアクセスログやユーザー行動の記録をある程度の期間以上蓄積してから解析するのがよさそうです。

PV数を利用して記事の人気傾向を読みとる

上記課題以外にも、滞在時間、読了率、さらにPV数を比較することにより、その記事の人気傾向を読みとることができるかもしれません。
過去の記事の滞在時間、読了率、PV数の傾向を先にいくつか算出しておくことで、目的の記事が今後どのような立ち位置になるか予測することができそうです。

ただし、傾向の分類は数値を目視して決め打ちで算出するのではなく、統計的に分析されていることが必要になります。また、この方法は実際に利用していくためには時系列解析も必要になります。(時系列解析はそれだけで記事のボリュームがすごいことになるので割愛します。)

アクセスログとユーザー行動の取得タイミングと再現方法について

分析を行う前に、データとして記録されておく必要があります。ここでは記録そのものの方法と再現方法について取りあげます。

アクセスログとユーザー行動の取得と保存について

アクセスログに関しては、対象のページにアクセスした際に、Webブラウザを利用している場合は遷移前のページはリファラを参照することで取得できます。
ユーザー行動である滞在時間、読了率に関しては、スクリプトを仕込んで特定タイミングでサーバーに送る必要があります。アクセスログとユーザー行動を別に記録する方法もありますし、以下の例のようにスクリプトを利用してページ移動前にアクセスログとユーザー行動をまとめてログ保存用のサーバーに送信する方法もあります。
合わせて、あとでユーザーごとに分離できるように、ユーザー毎にユニークな情報をキーとして設定しておき、それをログに含めておくことで後で分離することもできます。ただし、プライバシーにかかわってくるため、ユーザーを特定できる情報に個人情報が含まれていることもあるため、慎重に取り扱う必要があります。

ただし、ブラウザから画面をクローズしたときは情報が取れないため、滞在時間、読了率に関しては別のタイミングで送ることも以下のように検討します。
下図ではスクリプトから画面スクロールにトリガーしてサーバー側に送信する方法を示しています。

セッションの再現について

記録したアクセスログとユーザー行動からセッションの情報を再現します。特定の時系列で保存されているデータをユーザーごとに分離することができればセッションとして再現することができます。

おわりに

今回はウェブサイトのユーザー行動分析のためにどのような構造が考えられ、どのようにデータをとらえるか、どのような方法で取得、保存できるかを考察してみました。
次回は再現したセッションのデータを用いて分析する方法について取りあげてみたいと思います。