ディップ Advent Calendar の栄えあるクリスマスイブの記事です。（焦り）
そろそろエンジニアぽい記事を書きます。
概要
しばらく前に自分が担当したスマホ用Webサービスに適用した自作ヒートマップツールの話です。
巷によくあるヒートマップツールでは計測し辛い点をカバーした流れを書きます。
ヒートマップって？
ここで話すヒートマップとは、Webサイトの改善に使われる こんな感じのやつ です。
サイト訪問者が見ていたところに色を付けて可視化するやつですね。
今は便利な時代なので、無料で簡単にサイトに適用できるプロダクトが沢山あります。
既存のヒートマップで困ったところ
先述のヒートマップですが、基本的に「特定のページに対して絶対座標で集計される」想定になっています。
しかし今回対象となるサービスは「たくさんのコンテンツが（比較的）短いライフサイクルで入れ替わる」というものでした。
また当時自分は特定のコンテンツに対する改善ではなく、コンテンツページ全体に対する改善を検討していました。
そのため特定のコンテンツに対してヒートマップを見たとしても
- コンテンツが多数あるため、どのコンテンツを対象とすべきか決め辛い
- 一つのコンテンツへのアクセスの絶対量が少なくデータが偏る可能性がある
- コンテンツ毎に内容も違うため、特定コンテンツのデータではコンテンツページ全体の傾向を図りにくい
- 特定コンテンツのデータを分析する間に、そのコンテンツの寿命が終わる
といった理由で恩恵が得られにくいのです。
以上からコンテンツページ全体をグループ化して計測できれば……と思いましたが、ここで絶対座標による計測の罠が現れます。
絶対座標による計測の罠
例えば、とあるサービスにはこんな感じの構成のコンテンツがたくさんあるとします。
- タイトル
- 見出し画像
- 概要
- 主文
- ユーザアクションボタン
- 補足
コンテンツの具体例として「コンテンツ１号」を用意します。
そしてこのコンテンツ１号に対し メイン部分（やや下）がすごく見られてるよ！ というデータが得られたとしましょう。
しかしこのデータは他のコンテンツには流用できません。
なぜなら、下記のような少し全体的にコンパクトなコンテンツ２号があった場合
さきほどのコンテンツ１号で計測したデータを同様に反映させると
のように、全然違う要素であるユーザアクションボタンや補足の領域がよく見られていることになってしまいます。
この問題を解決するために ２つのアプローチ をとりました。
グループ化計測のポイントその１：コンテンツ分割
絶対座標によるヒートマップは特定のページ毎に計測するのであれば非常に強力です。
というのも 対象のページの構成を気にすることなく計測できる ためです。
今回の「コンテンツ１号」についても、このページだけを対象として考えるのであれば、コンテンツ全体がどういう構成（タイトルと概要と……と補足がある）を全く気にする必要はありません。
ですが今回は自作するということで、逆に 全力で特定のページ構成に特化する作り にしました。
具体的には、ヒートマップデータの計測する際にページ全体ではなく コンテンツを構成する各要素毎に分割して計測 するようにしました。
各ページで計測された値は計測エリア同士を対応付けた上で集計します。
こうすることで少なくとも 各コンテンツを跨いでの計測誤差 が発生しなくなります。
しかしこれではまだ不完全なのです。
グループ化計測のポイントその２：相対値での計測
コンテンツの分割によって少なくとも要素を跨いだ誤差は解消できました。
しかし 要素内における誤差はまだ残り続けています。
コンテンツ１号とコンテンツ２号では概要、本文、補足について内容量が大幅に異なります。
要素を分割したとしてもそのまま絶対値で計測すると、待っているのはこんな悲しい結果です。
ということで、絶対値計測を止めて 相対値計測 としました。
具体的には各計測エリアに対し どの点が見られていたではなく、どれ位の割合の領域が見られていたのか という方針に変えました。
こうすることで、各要素の内容の多寡での誤差を減らすことを狙いました。
これで同種別のページをグループ化しての計測ができるようになりました。めでたしめでたし。
実は他にもあった課題
そんなこんなでページをグループ化しての計測はできそうな気配が出てきました。しかし自分はもっと根本的な課題に気付いていなかったのです。
そもそもヒートマップは訪問者がコンテンツのどの要素に着目していたかを表すものです。
自分はその**「要素を見た」とはどうやって判断すべきか** について明確な回答を持っていませんでした。
また それらをトラッキングするタイミングはいつが最適であるか についても検討する必要がありました。
これらについて未だ正解は分かりませんが、当時自分が決めた内容を紹介します。
「要素を見た」判定
以下の2点で判断するようにしました。
- 要素が画面内に表示されている
- 一定時間スクロールが発生していない（またはごく微量である）
どちらも当たり前のような内容ですが解説をいれます。
1.についてはスマホWebということもあり単純化しました。
厳密にはタップなども考慮する必要があるかもしれませんが、そこから「見た」判定は厳しいと考え切り捨てました。
（PC版ではマウスカーソルを意識してなんやかんやするらしく大変そうですね）
2.については「見た」とするなら一定時間画面を制止させているはずだ、という点から入れました。
しかし画面に指を置きっぱなしにする人がいることを想定し、ある程度の微量のスクロールであれば許容するようにしました。
トラッキングするタイミング
これは他社のツールを参考に以下のように決めました。
- 要素を見た最初は短い時間（数秒）で一旦トラッキングする
- 同じ画面内容の場合、以降は広めの間隔でトラッキングする
こちら側の都合としては常に小まめにトラッキングをするのが理想ではありますが、それでは通信回数が増えて訪問者への負担となります。
それらの折衷案として、まず1.で挙げたように訪問者が 特定の要素を見始めたタイミングで早めにトラッキング します。
その後同じところを見続けているのであれば、2.にあるように広めの間隔でトラッキングします。
厳密な計測はし辛くなりますが、スマホで一度に表示される情報量を考慮すると ある要素を30秒見た場合と35秒見た場合を厳密に区別する必要性は薄い と判断しました。
今のところこの二つの合わせ技で上手くいっているようです。
終わりに
ホントは記事に挙げた内容のコードを張った方が分かりやすいんですが、執筆してる環境内にソースがないのでご容赦ください。
また 「お前のヒートマップはここが間違っている」 といったご指摘は大歓迎です。
お手間でなければバッサリとマサカリで切り倒していただけると嬉しく思います。
それでは良いクリスマスイブの夜をお過ごしください。
