Google Analyticsを使用して、ページの読み込み時間と、ユーザーの行動(滞在時間）の関係を見る。
ユーザーの体感速度をGoogle Analyticsで可視化する
という記事があって、スクリプトまで載っていたので、コピペして使わせてもらいました。
おかげで、ユーザの体感速度(読み込みのみ）が可視化されたので、それをアクショナブルなものにしようとした。
- ページ事の読み込み時間の差を認識して、改善対象ページを特定する
- 読み込み時間の差が、サイト内行動に制約を与えてないかを特定する。
ぐらいは、簡単に評価できそうだった。で、この２つをやってみた。
1.ページ毎の読み込み時間を出す
数が少ないので、なんとも言えないけど、この場合だと一つのページは、DOM構築までに時間が掛かっているのがわかる。
改善対象が１ページなら、やる気も減退しないし、日にちを区切っていけば、問題の原因をつかめるかもしれない。
イベント値が、そのままdocumentのload開始から、contentLoadできるまでのミリ秒になります。
平均が見られるのは便利。一個、異常値がある。
2.読み込み時間とサイト内行動の制約
ユーザがストレスを感じて、クリックなどに影響が出てないかを見る。
滞在時間とページビューの差があれば、そのストレスを感じてるとする。
これは、利用状況を見れば良い。
数字をもう一度。
| Dom構築まで | page-view | time_on_site | サンプル数 |
| -999 | 4.33 | 27:11 | 3 |
| 1000-1999 | 3.22 | 0:09:14 | 9 |
| 2000-2999 | 2.88 | 0:10:17 | 8 |
| 3000-3999 | 2.80 | 0:10:39 | 5 |
| 4000-4999 | 2.0 | 0:00:03 | 4 |
| 5000- | 3.22 | 0:09:14 | 7 |
何とも言えないし、因果関係は逆で、page-viewが進めば(2番目のpage-viewから？）、cacheが効いて、読み込みが早くなる気がする。
なんとも言い難い。
などと考えていると、、、
サイト全体のセッション数が１５、ページビューが３２で、イベント発生数が16?。
下の考えは間違い。ページビューのカウントが間違いぽい。原因は不明。イベントは、上書きされる事はなく、シンプルに送られた値が記録されていると考える方がいいみたい。よくわかってないので、こう考える方が自然。
ページを読み込む事にeventが発生してるはずなのだが、、、、
イベントのトラッキングは、セッション単位での計測になって、最後のページビューの数値しか残らない？
javascriptからはデータが送られているけど、Googleのデータ管理-レポートの段階で、ゴニョゴニョされてるよう。
セカンドディメンジョンに閲覧開始ページを出してみる(と言うことは、セッションでの管理という事？？？)
以下は、参考画像。
よくわからなくなった。
砂遊びって言葉が脳内に浮かんできた、、