GTM（Google Tag Manager）を使って、ページの指定場所までのスクロールを計測しましょう
コンテンツ分析の場合、ユーザーがページのどこまでスクロールして読んだかを知りたいことが多いでしょう。
ネットで一番流行っているのは、ページの何%までスクロールしたかの計測方法です。 この計測方法は、ブログや記事などに向いています。 何故ならば、これらのコンテンツページの長さは違うとはいえ、分析では、ユーザーがどこまで読んだかをざっくりと知れば十分だからです。
しかし、公式サイトのTop PageやSEMなどをかけたLanding Pageなどに対して、具体的な場所まで読んだかどうかを知る必要があるので、%の計測方法では、分析するには少し難しいでしょう。
そのため、今日は、ページの指定場所までのスクロール計測の方法を紹介したいと思います。
文章の中に出てきたソースコードは、Githubのzukさんのものを参考にし、清水誠さんに今回の目的に合わせて改修していただいたものになります。
zukさんのリンク：https://github.com/zuk/jquery.inview 清水誠さんのブログ：http://www.cms-ia.info/ja/
実装する前に
まずは、ページ構造を簡単に説明します。
現実の中で、このようなページが多いでしょう。
通常は各divにclass名を付与することが多いと思いますが、本当はユニークのidのほうが理想です。 しかし、自社サイトならまだしも、エイジェンシーがクライアントのサイトを分析する場合、ソースコードを変えてくれなんて、弱気になって言えない営業さんがたくさんいるので、ここでは、上記の例を想定して、今日のブログを書かせていただきます。
次は、実装にあたっての判定基準も併せて説明します。
divの内容を精読（最後まで読んだ）と判定するには、そのdivがinview（スクリーンに出てくる）するだけでは弱い。理想なのは、次のdivがinviewしたら、その前のdivを精読したと判定したほうが最も正確でしょう。 ただし、実際のところ、ページの空白の長さや、重点的に読んで欲しい箇所が異なるので、必ずしも次のdivのidやclassで判定することはありません。
また、精読すると判定するのであれば、ただ単純にスクロールして、読んでいなければ、意味がないので、ここでさらに時間縛りを入れます。
最後に、綺麗に実装するために、一回発火したら、もう一回同じところにスクロールしても、もう一回発火しないようにコードを書かないといけません。
なので、次の部分は、上記の3つの基準に達することを前提に、計測方法をご紹介します。
STEP1｜inviewタグを作成
まずは、下記のように、custom HTML Tagを作成します。
中に書いているコードは、私がGithubにアップしました。 こちらでダウンロードすることが可能です： https://github.com/RaNxxx/GTM_specificscrolled/blob/master/specificscrolled_trackingJScode
JSが分かる方は説明要らないと思いますが、私のような、プログラミングを勉強したばかりの初心者もいるかもしれないので、簡単な説明と変える必要の箇所を一応下記に纏めます：
ソースをみると、上のキャプチャーのコードが複数に続いています。 こちらは、計測したい場所の数ごとにあります。
コードの意味は、あるid/class（#youneedtochangeit01で指定している）がスクリーンに3秒（3000）出てきた場合、初めてはdataLayerに、eventの種類（'event' : 'scrolled_specific'）とeventの詳細('event_specificarea' : '計測したい箇所1')を送り、初めてではない場合は、何も送らないと指示しています。
そのために、自分のサイトに合わせて、キャプチャーで黄色で標記している場所のみ変えれば、思う通りの実装ができるはずです。
このブログの例だと、「会社の特徴」というareaの精読を計測したい場合、"計測したい箇所1"を"会社の特徴"に変え、var o1 = の部分を、var o1 = "#service"; に変える必要があります。 3秒以上に読んでほしい場合は、3000を5000でもなんでも変えれば良いです。
STEP2｜ページ指定のトリガーを作成
本来は、このJSコードにページ指定の縛りも入れれば、こちらのトリガーを全ページ指定にすればよいです。
ただ、そうした場合、JSの初心者にとっては、あとあとのメンテナンスが面倒くさく、間違えやすいので、ここでは、ページ指定のトリガーの作成をお薦めします。
※将来は、こちらのコードを更に発展させ、ページ指定を入れてもシンプルで、かつ、計測したい箇所ごとに複数書く必要のないコードを書けるようにしたいと思います。
通常はPage Pathにequals / で指定すれば良いです。 私が実装したサイトはサブドメインの計測もしているので、Page Hostnameの縛りも入れました。
STEP3｜GAに送信するタグとトリガーを作成
こちらは説明するまでもなく、下記のキャプチャーを参考して、作ればできると思います。
タグはこちら：
トリガーはこちら：
STEP4｜実装検証
最近GTMの実装検証が本当に便利になりました。
なので、ここでは、GTMで検証する方法をご紹介します。
まずは、タグが指定の場所で正しく発火したかどうかを確認します。
STEP1のタグ発火に対して、１）指定のページのみ常に発火状態になっている、２）ほかのページでは発火していないことを確認できればよいです。
そして、STEP3のタグは、指定の場所まで指定の秒数が止まったら、タグが発火すれば良いです。
STEP1のタグが発火しないことはあまりなく、STEP3のタグが発火しないことになったら、STEP3自体の設定が間違っていなければ、STEP1のJSコードをもう一回チェックしたほうが良いです。
また、実装を検証する時は、ユーザーの気持ちを想像しながら、判定に使うid/classと滞在する時間の長さが適切かどうかも併せて、確認したほうが望ましいです。
その次に、GAに送信するデータが正しいかどうかをタグごとに確認します。
ここのAction、Category、Labelは思う通りになっているかどうかを確認すれば良いです。
最後は、翌日になって、GAに送信されたデータを確認し、データが取得できていることを確認できれば、全ての設定が終わりです。
THE END
ざっと書いてしまいましたが、いかがでしょうか？
もちろん、前にも述べたように、この手順の中のJS文が更に改善する余地はあると思います。 それができるようになったら、またこのブログで紹介させてください。
※既にこう書けばよいと分かっているお方がいれば、ご指摘頂ければ嬉しいです！
