前回の記事の中で、「タグ・トリガーの数に比べて変数の数が少ないGTMコンテナはメンテナンス性が悪い」ということを記載しました。今回の記事では、「変数をどのように活用するべきか」を考えるために、まずは全てのGoogleタグマネージャーコンテナにおいて、自身が必ず作成している「変数」が1つあり、その変数については一般にはあまり知られていないようなので、紹介したいと思います。
よく陥りがちなGTMの状況
自身が他の人が設定を行っていたGoogleタグマネージャを新しくチェックすることになった時に、見ているポイントは基本的に2つです。
それは、
- 「コンテナのバージョン履歴を元に、どのくらいの頻度で更新が行われているか(また、その更新を行っているユーザーの人数)」
- 「タグ・トリガー・変数のそれぞれの数とその割合」
です。
それぞれ、詳しく説明します。
バージョンの更新頻度と更新するユーザーの人数
これは、そのコンテナをキレイな状態で維持する必要性が高いか否かを見極めるためにチェックしています。例え、Googleタグマネージャーのコンテナの中が汚い状態であったとしても、その更新頻度が1年に1回程度であれば、それをキレイに整えるために大きなコストを使う必要性は低いと言えます。また、特定の1人の担当者のみが更新を担当しているケースにおいても、その担当者自身がコンテナの中身をきちんと理解して設定を行っている分には、緊急性は低いと言えます(特定の個人に依存している、という点は課題なため、重要度は高いが緊急性は低い、という位置付け)。
一方で、バージョンの更新頻度が高く、また複数の担当者がその設定に関わっているようなケースでは、Googleタグマネージャーの設定上の問題がより露呈しやすい状況と言えます。そのため、このようなケースにおいては、「そのコンテナをキレイな状態で維持する必要性が高い」と言えます(ただし、この時点では、既にコンテナがキレイな状態になっているかどうか、は不問)。
タグ・トリガー・変数の数とその比率
これは、そのコンテナの状態が健全であるか否かを見極めるためのチェックとなります。コンテナの規模が小さい場合(これらの設定数が少ない場合)は、特に気にしません。しかし、それぞれの数の合計が100個を超える状況になってくると、その比率がどのような形になっているかを重要視する必要があります。
一番メンテナンス性が悪いと思われるコンテナの状態は、タグとトリガーの数がほぼ同程度で数10個存在している一方で、変数についてはほとんど設定されていない状態です。このケースは、タグとトリガーがほぼ1対1の関係で作られていることと、変数を活用し切れていない状況を意味します。
逆に、変数がたくさん設定されているコンテナは、(その変数の内容にも依る部分はありますが)基本的にキレイな状態になっている(もしくは、メンテナンスしやすいGoogleタグマネージャーを目指して設定している)と思われます。
以前のブログ記事「Googleタグマネージャの利用状況 44ヶ月間の推移のまとめ」で、下記の図を紹介しました。この散布図において、大雑把に捉えると右下に位置するコンテナがメンテナンス性が低く、左上に位置するコンテナがメンテナンス性が高いと考えられます。。
私が、必ず作成するたった1つの変数「Page Type」
Page Type変数とは
以前は作らなかったこともありますが、この1年くらいの間に私が実装したGoogleタグマネージャーには、基本的に「Page Type」という変数を作成するようにしています。この変数は、最近では「正規表現の表」で作成し、多くの場合はPage Pathをベースにして、そのページの論理的役割を取得できるようにしています。例えば、とあるブログサイトでは、下記のような内容で設定を行っています。
正規表現の表の機能がローンチする前は、類似の機能で「ルックアップテーブル」が存在しましたが、こちらは条件付けが完全一致で作成する必要があり、このようなことはできませんでした。そのため、この頃はカスタムJavaScript変数を使って実装していましたが、今では「正規表現の表」により、実装しやすくなりました。
Page Type変数の利用シーン
この変数の利用シーンは様々なところにあります。重要なことは、「タグで利用するために利用する」や「トリガーで利用するために利用する」ような類の変数ではなく、タグであってもトリガーであっても、さらには他の変数を作成するときにでも再利用できるように、変数を設計している点です。
コンテンツグループへの活用
1つ目は、Googleアナリティクスの「コンテンツグループ」の設定にこの値をこのまま利用することです。コンテンツグループ機能は有用な機能でありながら、あまり使われていません。しかし「Page Type」の変数を作成してしまえば、コンテンツグループを利用することは簡単なので、ぜひ利用してみることをお勧めします。
トリガーの条件付けに利用
2つ目は、トリガーの条件付けにこの「Page Type」の値を利用します。例えば、「ブログの記事ページ」にのみ配信したいタグのトリガーを、「Page Path」を条件に直接指定するのではなく、「Page Type」の変数を利用して、「Page Typeがブログの記事ページである」という条件を指定するようにします。このように指定することで、「ブログ記事ページのURL条件が追加された」時に、変更すべきコンポーネントが「Page Type」変数1つのみになります。1つ変更すれば済むため、変更漏れを危惧する必要はありません。
動的リマーケティングのページタイプに利用
3つ目は、1つ目の例と近いですが、広告の動的リマーケティング・タグにおけるページタイプの設定に利用します。動的リマーケティング・タグは、Google広告・Yahoo広告・Facebook広告・Criteoなど様々な広告媒体で必要となってきています。これらの実装を行うときのタグで登場するページタイプの設定値は広告媒体によって異なっているのが現状です。この動的リマーケティング・タグで用いるページタイプの値にも「Page Type」の値を活用します。ただ、「Page Type」変数自体は、動的リマーケティング・タグの実装に最適化させる必要はなく、できるだけ意味のある単位で分類するようにします。その上で、もう1つ別の変数として「ルックアップ・テーブル」を使って「Page Type - Google広告・動的リマーケティング用」や「Page Type - Yahoo広告・動的リマーケティング用」などを個別に作成します。
まとめ
Googleタグマネージャーは、単純に特定のタグを配信するためだけの設定を行うのであれば、ほとんどのケースにおいて設定が複雑になることはありません。特定のURLでのみタグを発火したい時も、トリガーで条件を柔軟に設定することができます。また、クリックイベントを計測したい時であっても、「どの要素がクリックされたか」を特定する方法にさえ気をつければ簡単にできます。
しかしながら、様々なWebマーケティング・ツールを活用し、より多くの情報を計測できるようにするステップにくると、「シンプルに保ち、メンテナンスしやすい状態」でコンテナを改修していくことが途端に困難になります。
ぜひ、本記事などを参考にして、メンテナンス性の高いGoogleタグマネージャーを目指してみてください。
