Googleタグマネージャーによるスマートスクロールトラッキング
公開: 2020-01-23Google Tag Manager(GTM)を使用している場合、スクロールトラッキングは、 GTMに組み込まれているスクロール深度トリガーを使用していくつかの簡単な手順で実行できるため、これは非常に簡単なタスクです。 過去数年間にこれを何度も実装してきましたが、すぐに使用できるGTMトリガーにはいくつかの制限があることがわかりました。 このため、スクロールトラッキングをカスタマイズするときに役立つと思われるいくつかのトリックを紹介します。
私たちのアプローチは確かにより正確なスクロールトラッキングデータを提供し、バウンス率などのメトリックをはるかに意味のあるものに変えることを可能にし、コンテンツの品質を真に測定することができます。
その背後にあるアイデア
私たちのカスタムソリューションは、コンテンツの多いサイトがある場合に特に興味深いものです。 標準のスクロール深度トリガーの問題の1つは、ページが長いか短いかを気にしないことです。 ページが非常に短い場合は、ページが読み込まれたときにすべてのしきい値に達する可能性があります。これにより、ユーザーがスクロールしなかった場合でも、多くのgtm.scrollDepthイベントがデータレイヤーにプッシュされ、タグが発生します。 。 GTMのインタラクションヒット設定によっては、バウンス率が急落する可能性があります。
誰も自分のウェブサイトを手動で調べて短いページと長いページをフィルタリングしたくないので(そして新しいコンテンツが公開されたときにスタンバイ状態になる)、これに対するより簡単な解決策があります:長さを自動的に測定するカスタムJavascript変数を使用しますページのスクロールトラッキングの対象であるかどうか、つまり「十分な長さ」であるかどうかを判断し、その場合にのみ、ページのスクロールトラッキングトリガーをアクティブにします。
ステップ1:カスタムスクロール深度しきい値変数とトリガーを構成する
しきい値が自動収集されていないページでのみスクロール追跡タグを起動するには、ページが追跡に適した長さである場合にのみトリガーが起動するように条件を設定する必要があります。
GTMコンテナで、次のようなカスタムJavascript変数を作成します(クレジットはSimo Ahavaに送られます)。 要件に一致するように、以下の変数を編集します。

- maximumRatio :これは0から1までの値であり、ブラウザのビューポートの高さとページの高さの比率を反映します。 0.25の値は、ページの最大25%がブラウザのビューポートに表示され、残りはさらに下にスクロールすることによってのみ表示されることを意味します。
- verticalScrollDepths :これらはページが追跡するために設定できるさまざまなしきい値です。
- fallbackDepths :これを「101」のままにしておくことをお勧めします。これにより、最大比率を超えた場合のフォールバック/デフォルト値が変数に与えられます。
次に、この変数{{Custom JS – Vertical Scroll Depths}}をScrollTriggerの「VerticalScrollDepths」Percentagesフィールドに追加し、すべてのページで「WindowLoad」を有効にします。
ステップ2:非相互作用ヒットを設定する
このパラメータには、GoogleAnalyticsがイベントヒットを登録する方法に影響を与えるさまざまな設定があります。
- falseに設定:デフォルトでは、ユーザーがページでイベントをトリガーすると、ユーザーがページを操作していることを意味するため、バウンスとしてカウントされません。 スクロールトラッキングに関連して、バウンス率がゼロに近くなるため、この設定は注意して処理する必要があります。
- trueに設定:スクロールイベントがバウンス率にまったく影響を与えたくない場合は、これが適切な設定です。 ただし、ユーザーの行動についての深い洞察も妨げられます。
- カスタマイズされた設定:長いページを含むコンテンツの多いサイトがある場合は、「クイックスクロール」とエンゲージメントのあるユーザーを区別することをお勧めします。 より現実的なアプローチとして、このソリューションをお勧めします。たとえば、75%を超えてスクロールするユーザーは、意味があると見なされます。 多くの場合すぐに到達するスクロール深度(25%など)は、非インタラクティブイベントとしてGoogleアナリティクスに送信されます。 これにより、ユーザーの真意を反映したバウンス率に近づくことができます。 このためには、変数{{Custom JS – Scroll isNon-Interactive}}を設定する必要があります。 この関数の変数{{ScrollDepth Threshold}}は、ボックスにチェックマークを付けることで有効にして選択できる組み込み変数です。

ステップ3:すべてをまとめる
最後のステップは、スクロールデータをGoogleAnalyticsに送信するGoogleAnalyticsイベントタグを設定することです。 ステップバイステップの手順については、これを詳細に説明している以前のブログ投稿にアクセスしてください。 この設定で重要なのは、右側のフィールドに変数{{Scroll DepthThreshold}}と{{CustomJS – Scroll isNon-Interactive}}を追加することです。 構成の詳細については、以下を参照してください。


タグを設定したら、手順1のトリガーをスクロールトラッキングタグに接続すると、テストの準備が整います。
これが私たちのテスト結果です
さまざまな非相互作用ヒット設定(ステップ2で説明)と、それらがバウンス率にどのように影響するかをテストしました。

上のグラフが示すように、非相互作用パラメーターがfalseに設定されている場合(2019年8月から9月)、バウンス率はかなり低かった。 この設定は、迅速で偶発的なスクロールを含む、発生したすべてのスクロールイベントが相互作用と見なされることを意味しました。 したがって、Google Analyticsは、これを対話型ユーザーとして解釈しました。 したがって、ユーザーが他のクリックなしですぐにバウンスしたとしても、バウンスとは見なされませんでした。 その結果、バウンス率は約10%と非常に低くなりました。 あなたはおそらくこれが少し「真実であるには良すぎる」ように見えることを知っているでしょう。
10月に、反対の設定に切り替えて、非相互作用パラメーターをtrueに設定しました。 ここでは、ユーザーがどこまでスクロールしても、トリガーされたスクロールイベントはAnalyticsのインタラクションとは見なされませんでした。 パラメータをtrueに設定すると、基本的に相互作用の検出が無効になります。 これは保存と見なすことができますが、完全なオプションではありません。 結果ははるかに高く、おそらくより現実的で、バウンス率は約70%でした。 この場合、実際にページのコンテンツをクリックまたは操作したユーザーのみを測定しました。 ただし、このアプローチは極端すぎると考えました。 当サイトのコンテンツは継続的に更新されており、特にブログは多くの読者を魅了しています。 ユーザーが実際にスクロールしてコンテンツの多いセクションを読む距離を測定したいと思います。
そのため、11月に、推奨設定であるカスタマイズされたソリューションに切り替えました。 特定のしきい値を超えたユーザーのみが対話済みとしてカウントされます。 数行または1段落下にスクロールし、その直後に離れる訪問者は、バウンスと見なされます。 私たちにとって、エンゲージメントのあるユーザーとは、ページの深さの75%を超えてスクロールするユーザーです。 スクロール深度%は、要件を満たす任意の値に設定できます。
