Google Tag Manager をチームで運用する場合、
標準化のためのフローの整備や、ガイドラインの作成を行うとタグ構成や、カスタム JavaScript の実装がバラつかず幸せになれそうに思います。

先日、Github で Google Tag Manager 関連の Repository を検索していたのですが、ガイドラインを見つけました。
justusbluemer/gtm-guidelines: A collection of best practices for your daily Google Tag Manager routine
記載内容がためになりそうだったので、日本語の翻訳を作成してみました。
翻訳の内容と、翻訳時に思ったことを記載します。

翻訳ファイル

以下にあります。

感想

翻訳時の感想を記載します。

カスタム JavaScript変数 に関数を設定し、コードを再利用する は 確かに使えそう

この使い方をしたことがありませんでした。単純な値の返却で対応できないケースもコードの共通化が行えるので、使用可能な場合で使っていこうかと思います。

Sentry というサービス

知りませんでした。Google Analytics にJS エラーを送付する方法だと、エラーが発生した文脈はわからないので、文脈がわかるのはメリットかなと思います。
getsentry/sentry: Sentry is cross-platform application monitoring, with a focus on error reporting.

タグの命名規約

タグ名称の命名規約の記載がなかったので、どう付けるべきかですが、Qiita にまとまった記事がありました。

Qiita以外だと以下の記事が参考になりました。

大きな<wbr>力が<wbr>あれば<wbr>大きな<wbr>責任が<wbr>生まれる<wbr> のくだり

With great power comes great responsibility

正しい訳は、大いなる<wbr>力には<wbr>大いなる<wbr>責任が<wbr>伴う かもです。
ここが個人的に一番響きました。
大いなる<wbr>力には<wbr>大いなる<wbr>責任が<wbr>伴うの理解が(自分なり)に出来ている人であれば、JavaScript のスキルは置いておいて、Google Tag Manager 権限 公開者でいいと個人的には思います。

補足

ガイドラインの補足となりそうな Tips を記載します。

タグ、トリガー等の説明には、メモ機能を使う

カスタム JavaScriptには JSDOC が記載できますが、タグ、トリガー等の場合は、メモ機能でコメントが付与できるのでメモ機能を活用して説明を記載するのが良いかと思います。

Google Tag Manager の コンテナの分割単位は、コンテナで発生する開発規模をイメージして決める

明確に記載されていないですが、Google Tag Manager は タグ、トリガー等の容量制限があります。
導入前に、できればコンテナに実装されるタグ、トリガー数を予測して適切な単位でコンテナを分割すべきかと思います。

複数コンテナで使用する共通設定のコンテナを作成しておいて、そこから 設定のインポート、エクスポートで共通設定を読み込むようにすれば複数コンテナでも共通設定を管理できるかなと思います。

Google Tag Manager に関する公式ガイドライン

参考

以下、参考にした記事になります。

以上です。

コメント

カテゴリー

最近の投稿