広告を含めたコンテンツ運用系ぽい人たちから聞こえるだけは聞こえてたけどこれまで関わってこなかった Google Tag Manager を触る機会を得たのでその実例と感想など。
まとめ
Google Tag Manager を使うと
- プログラムコードで何もせずに Google Analytics の Property ID の切り替えを行うことができて便利
- つまり静的サイトでも切り替え可能
- タグの設定を publish してしまう前に関係者だけで preview できて便利
- publish したあとに rollback もできて便利
やりたいこと
Google Analytics に staging 環境が欲しい。そんでいい具合に切り替わってほしい。
これ。
なぜstaging環境が欲しいのか
Google Analytics のトラッキングコードだけの話ではないんだけど、development や staging へのアクセス、検証作業によって本番用のデータにノイズが乗ってしまうのは望ましくない。DB の登録内容は本番とテストで分けるのに Google Analytics のデータは混ざったままにしてしまうのはいかがなものか。
PV しか採っていない場合はまぁそれでも影響は軽微かもしれないけどね。変わったイベントを捕捉したい、みたいな場合は開発時にたんまりイベントを Fire してしまうのでかなりタチが悪くなってしまう。
もちろん、コードの作り方や Google Analytics 上のフィルタ設定などでノイズを後から取り除くことができる場合もある。しかしその場合はフィルタ設定できる人やフィルタを適用したビューを正しく選ぶことのできる人でないと正しいデータを手に入れることはできない。変なところで属人化してしまう可能性が高い。
これまでのやり方
ということで、こういった欲しくないデータが混入してしまわないように、これまではプログラムコードのちょっとした工夫で property を切り替えていた。
AnalyticsHelper のようなものを用意して
def ga_property_id
if ENV['GA_PROPERTY_ID']
ENV['GA_PROPERTY_ID']
elsif Rails.env.production?
'UA-xxxx'
elsif Rails.env.staging?
'UA-xxxx'
end
end
こんなコードを書いて HTML の中に埋め込んでおいて、Google Analytics の初期化処理の中で DOM の中の Property ID をセットする。
ga('create', 動的に作る)
ちゃんと環境を判別できるように作ってあって deploy が自動化されていれば特にあれこれ気にすることなく以下の状態を再現できていた。
- 通常の開発ではわざわざ Google Analytics にリクエストを飛ばさないように
- staging で確認する際も余計なアクセスが記録される心配がない
- Analytics 関係のコード（イベントトラッキングとか）を開発する時は必要に応じて Property ID をセット
これはこれでなかなかよかった。
少なくとも本番用の Google Analytics トラッキングコード埋めっぱなしよりははるかに。
Google Tag Managerを使ったやり方
Google Tag Manager の基本的な設定方法などは省略。特別難しいことはないので、ちょっと Web に詳しい人なら画面の指示に従ってそのまま作業するだけでよいはず。概略などもぐぐればぞろぞろ紹介記事が出てくるのでそちらに譲ります。
今回の設定に関係してくるものは大きく2つ。
- Tag
- Trigger
Tag は今回の例で言えば Universal Analytics Tag になる。これに Property ID をセットしてやれば Google Analytics のトラッキングコードをペタッと貼ったのと同じ状態を再現できる。
ここにおもむろに staging 用の ID でもう一つ Universal Analytics Tag を追加する。このままでは両方に記録されてしまうが、それぞれに Trigger を設定することで片方ずつ適用されるようにできる。
production 用の property の方は Page View を All Pages ではなく Page Hostname に production のホスト名が入っている場合に Fire することにしておく。逆に staging 用の property の方は Exception で production のホスト名を含む場合を設定しておく。
これで Google Tag Manager を使って Google Analytics の production 用の property と staging 用の property の切り替えを、一切コードを書かずに実現できる。
この方法を使えばサーバサイドのコードは必要ないので、静的サイトでも切り替えを実現できる。
感想
今回、この設定を試すに当たり、意外にワークフローが考えられていて優秀だなと思った。（失礼）
というのも、従来のコードで切り替える方法では、コードの deploy と property の切り替えは同時に起きてしまうので、少なくとも切り替えのコードを初めて適用するときは deploy したらすぐに「リアルタイム」で確認を行うようにしていた。これが Google Tag Manager では publish の前に preview を行い、その状態で「リアルタイム」で確認することができる。
preview というのは Google Tag Manager にログインしているブラウザでのみ、これから適用しようとしている Tag Manager の設定が反映されるものだ。おまけに該当するブラウザでは特に何もすることなくどんな Tag が設定されているのか、その Trigger は何か、みたいな情報を確認できる。例えばこれで Tag Manager へログインしている複数の人でどのような Tag が反映されるのかをリリース前にチェックすることができる。これはかなり安心だ。
さらに publish は名前を付けて保存され、その履歴をたどることも rollback することもできる。1プログラムコードでやっているようなバージョン管理と rollback を Tag Manager 上で再現できるので、Google Analytics 単体で設定を頑張るよりもよほど安心だと思った。
他にもイベントトラッキングも Tag Manager から設定できる2し、もちろん広告など他のタグも利用できる。こうしたタグの追加も、プログラムコード上は最初のコードスニペットから何ら変更する必要はないし、例えば広告は development や staging では表示しないといったことも、上の GA の property 切り替えと同様に可能だ。
今回は時間の都合で自分が Tag Manager を触ることになったが、確かにこれは非エンジニアがエンジニアを頼らずにいろいろなことができる、非常に優れたツールだなと感じた。これまでは「いやいや、うちみたいに Property ID の切り替えとかちょっと変わったことやってるところは逆に困らない？」って思ってたけど、あっさり上回ってくれることが分かったし、何より面白いと思ったのは
非エンジニアの方が多く触るであろうツールに、エンジニアの世界では当たり前のバージョン管理とロールバックの概念を持ち込んでくれていること
である。これ、ガンガン積極的に布教していったら、ディレクター、運用方面とエンジニアの文化のギャップが少しは減るんじゃないかなぁ。
おまけ
「広告のコンバージョンタグ」って何かと思ってたけど、こういうのも Tag Manager 上から管理するようにすると Google Analytics の設定と AdWords の設定と…ってバラつかずに便利っぽい。やることは結局 URL にマッチするパターンを作ることだけなので。