タグマネージャーから見るJavaScriptタグのあり方

タグマネージャーから見るJavaScriptタグのあり方

弊社サービスの多くは「タグ納品」でお客様企業にご案内させていただいております。
そこでよく感じるのは、多くの企業がタグマネージャーを利用していること。

以前、本bitWaveにて「SPAサービスにおけるタグマネージャーとのコンフリクト」を記事を公開したのですが、今回はさらに掘り下げて、“少しばかりの技術詳細とタグマネージャー対応を念頭においたサービス構築” をテーマに記事を書いてみようと思います。

<bitWave関連記事『サービスが混浴する事のボク的悲劇|SPAのタグ事情』>

どのようなタグマネージャーが普及しているのか

まずは国内でよく見かける主要タグマネージャーを一覧化しました。
みなさんはどれだけ知っていますか?


Google タグマネージャ
提供元:Alphabet (Google)


Yahoo! タグマネージャー
提供元:ヤフー株式会社


TagKnight(タグナイト)
提供元:Fringe81株式会社


UNITAG(ユニタグ)
提供元:デジタル・アドバタイジング・コンソーシアム株式会社


エコタグ
提供元:株式会社サイバー・コミュニケーションズ


CA Tag Solution
提供元:株式会社サイバーエージェント


CAMP
提供元:株式会社サイバーエージェント


ADPLAN OT
提供元:株式会社オプト


dynamic tag management
提供元:アドビ システムズ株式会社


TAGエビス
提供元:株式会社ロックオン


ScaleOut タグマネージメント
提供元:Supership株式会社

タグマネージャーでの失敗談

これだけの種類のタグマネージャーが普及しているのも、やはり “便利” だから。
このツール業界はもはやレッドオーシャン化して久しいわけですが、それでも新参ツールが誕生しているのですから、その利便性は誰もが認めるところでしょう。

ただ、便利なものには必ずウラがあります。つまり「リスク」です。
これまで僕が試したタグマネージャーの失敗談がいくつかありますので、ここでご紹介させていただきます。

■<script>タグの要素が引き継がれない件

某タグマネージャーに “普通” にタグを登録し、“普通” にタグ稼働させてみたものの、サービスが正常起動しないということがありました。
ブラウザのコンソール画面にて「element」を確認してみたところ、そのタグマネージャーはタグの要素を自動解析して、ご丁寧にも再構築された状態で実行されていました。具体的に言えば、<script>タグの「src」と「type」要素以外はすべて削除されている状態だったのです。

つまり「charset」や「class」、「id」などが削除されていたというワケですが、本来であれば「class」や「id」などは<script>タグとしては利用しない方が良い属性であることは確かです。
しかし、「charset」まで削除させてしまうことに関しては、少し疑問が残ります。

<参照:W3C Recommendation『18 Scripts』>
上記のW3C勧告のページを見ても、しっかりと定義されているので、ここは準拠してもらいたいところですが……。
思いましたが、どのタグマネージャーの話かは明記を差し控えますが、すでに大勢の顧客を持つタグマネージャーが改修してくれるはずもなく……。ただただ泣き寝入りでした。。。

■document.writeが非推奨になってしまった件

少し前までのGoogleタグマネージャでは「document.write関数」を禁止扱いとしていました。
しかし、「document.write関数」を有効化させることを許容したオプション機能が付与されることになり、これによって「document.write関数」を使用する場合のある弊社サービスにおいても、無事に起動させることができるようになりました。

しかし、その後Chromeブラウザのアップデートに併せて、Google社は “「document.write関数」を使用することを推奨しない” という声明を発表してしまいました。ほどなくブラウザコンソール上でも警告文が表示されるように。。。

もはやタグマネージャーだけの問題ではなくなっていますが、オプション機能を付けてまで対応可とした関数に対し、急遽非推奨と手のひらを返した理由は一体なんだったのでしょうか? そんなに危険な関数なんでしょうか?
現在でも多くの企業サイトでは、コンソール上で「warning」の文字が表示されており、それを目にする度に疑問に思ってしまいます。

下記のGoogle開発者サイトでも少しだけ解説(弁明?)しているようですが、どうやらGoogle社は今後も許容する気はなさそうです。
<参照:Google Developers『Intervening against document.write()』>
Google社ほどの大手がこう言っているのですから、どうやらこの関数を使い続けるメリットはなさそうですね。

おい、タグマネよ。お前は便利なのか不便なのか、どっちなんだい?

様々なサイトでタグマネージャーを利用する場合のメリット・デメリットが紹介されています。
しかし異口同音、ほとんどのサイトで挙げられるメリット・デメリットは以下のような内容です。

■メリット
・タグ管理がラクになる
・複数ページで設定の共有化が行える
・プレビュー機能を持っているタグマネージャーであれば、登録したタグの公開前確認ができる
・WEBページの読み込み速度がアップする
・学習コストが下がる
・変更履歴の管理ができる

■デメリット
・特定のライブラリなどが利用できない
・管理画面の設定が難しい場合がある
・リスクが一極化する
・一度導入すると辞められなくなる可能性が高い

これらのデメリットをしっかり把握しているのであれば、導入メリットの方が確実に多いことも事実。サイト管理をされている方はタグマネージャーを使わない手はないのではないでしょうか。

エンジニアとしてのJavaScriptタグの考え方

サービスを提供する側としては、各タグマネージャーの実態を理解・研究した上で、サービスではどのような<script>タグを導入すべきかを考えなければいけません。
これだけ普及したタグマネージャーですから、これを意識せずにサービス設計を行うなんて言語道断なのです。
しかし、自身がタグマネージャーの提供者ではない以上、すべての特性を把握することは不可能ですので、少なくとも以下のような点だけでも気を付けるべきでしょう。

■トリッキーな属性などは使用しない
基本的に「src」と「type」の記載をするレベルでいいかと思われます。
間違っても「data-***」のようなプログラム活用する属性は、仮にW3Cが許しても取り入れない方が良いでしょう。

■<body>タグ、<head>タグのどちらに貼り付けてもOKな状態が望ましい
提供サービスの仕様にもよるので、結論は一つとは限りませんが、<body>タグでも<head>タグでも、タグを貼り付けさえすればサービスが正常に使えるというのがサービスとして理想的です。いかにこの理想の状態に近づけるかを意識しながら設計を行う方が良いでしょう。
会社やWEBサイトのポリシーとして、どちらかしか貼り付けられません……という場合もありますからね。

■内部構成にも細心の注意を払う
前記のとおり、document.writeは使用しない。グローバル変数や関数などは使用せず、無名関数内で処理完結させることが望ましいでしょう。
ブラウザはいつ何時、どの変数や関数に対して “非推奨” のレッテルを貼るかは分かりません。備えあれば憂いなし。十分に意識して設計を行うべきでしょう。

タグマネージャーを使う方は、利用しようとしているサービスがそのタグマネージャーの設計に即しているかを確認すべきです。そしてタグマネージャーを使われる方(つまりサービス設計者)は、自分が設計したサービスがタグマネージャー設計思想に準拠しているかを考慮する必要があるということです。

とにかく便利なタグマネージャーを “使う側” も “使われる側” も、タグマネージャーの特性を把握することが重要なんですね。

本記事作成にあたって参照させていただいたサイト

<参照サイト:UIDEAL『今さら聞けない、タグマネジメント入門基礎の基礎』>
<参照サイト:Digital Marketing Blog『タグマネジメントツールの比較』>

コメント