この記事は freeeデータに関わる人たち Advent Calendar 2020 の 24日目 です。
こんにちは、freee で Google Marketing Platform の管理をしている onda です。
普段は、GMPに関連する GA / GTM / Optimize などのプロダクトの管理や実装/収集/ Bigquery による集計をおこなったり、ダッシュボードをつくったりしています。
昨年は、ITPによるGAへの影響を簡単に調べるという記事を書いています。
今回は、freee で利用している特定の GTM コンテナのコンテナサイズをスリム化した話を書きたいと思います。
施策をおこなっている当時は GTM をスリム化させる話は記事としてあまりなかったような気がするので、今後同じ状況になった方のお役に立てると嬉しいです。
背景
freee で運用している GTM のコンテナは複数あるのですが、その中の１つのコンテナは私が入社した数年前にはすでに 50% を超えていました。
誰が実装したのかわからない熟成されたタグが複数実装されている状態で、そのタグが生きているのか死んでいるのかさえもわからない深い闇の中にありました。
そっと見ないふりをしていたのですがコンテナサイズはどんどん膨れ上がりついに 94% になり、なんとかしようと決意しました。
50% を越えるとコンテナの Versions でサイズが表示されるようになります。
工程
コンテナサイズのスリム化で実際におこなった工程はこちらです。
大きく分けて、内容の把握 と コンテナの用途別の分離 と 生きていないタグを把握する の3工程になります。
- コンテナ内の タグ/トリガー/変数 の オーナー と 目的 の把握
- コンテナ内の タグ/トリガー/変数 をリストするツールを作る
- リストしたタグを全体へ共有し、タグの利用状況を把握する
- コンテナを 利用目的別に分離
- コンテナ内の タグ/トリガー/変数/フォルダ を削除するツールの作成
- 利用状況把握時に不要と判断されたものをツールで削除
- コンテナの タグ/トリガー/変数/フォルダ を広告用とそれ以外で分ける
- 広告用コンテナを作成しスニペットを実装、広告用の タグ/トリガー/変数/フォルダ の流し込みをおこなう
- コンテナの 発火状況の把握
- GTM monitoring API を利用したタグの発火状況を把握するツールの作成し稼働
- 生きていないタグを事業部同意のもと削除
コンテナ内の タグ/トリガー/変数 のオーナーと目的の把握
ここの工程では下記の２つのタスクをおこなっています。
- コンテナ内の タグ/トリガー/変数/フォルダ をリストするツールを作る
- リストしたタグを全体へ共有し、タグの利用状況を把握する
まず、コンテナの内容を把握するために、GTM API と Google apps script を使って タグ/トリガー/変数/フォルダ を Spread Sheet へリストするツールを作りました。
その Sheet にリストしたタグをもとに、オーナーの事業部や用途、広告目的であるか、タグが発火する領域などをヒヤリングしました。
よくわからないタグが多くある中、多くの事業部のメンバーに快く協力いただけて本当に助かりました。
コンテナを利用目的別に分離
続いて、GTM API と Google apps script を使って Spread Sheet へリストした タグ/トリガー/変数/フォルダ を削除するツールを作りました。
前の項目でヒヤリングし不要と判断されたものをこのツールを使って一気に削除します。
なお、今は bulk actions (November 5, 2020) という指定したものを一括で処理できる機能が追加されたのでツールを作る必要はありません。
続いて、ヒヤリングをしていて圧倒的に多いのが、広告タグだということがわかったので、タグ/トリガー/変数 を広告用とそれ以外に分け、コンテナ自体を分離し、Multiple Containers で運用することにしました。
広告用とそれ以外との分類の後は、もとのコンテナの内容を広告用のコンテナへインポートしそこから広告以外のタグを、ツールを利用して削除するということをおこないました。
なお、今は 更新されたコンポーネントのみをエクスポートする機能（September 16, 2020） が追加されているので最後にタグを削除する工程は不要です。
Googleの製品は常にアップデートしていて素晴らしいですね。
コンテナの 発火状況の把握
続いて、複数実装されているタグがどの領域で発火しているのか、また稼働していないタグはあるか発火状況がわかるようにします。
当初は、下記のブログをカスタマイズして GCP 上で発火状況をモニターできる仕組みを構築しましたが、実際に稼働させてみると、リクエストされる量が多く GCP の費用が思ったより高くつくことがわかったため、別の方法をとることにしました。
How To Build A Google Tag Manager Monitor | Simo Ahava's blog
実際には、下記の GTM のカスタムテンプレートを導入し一部をカスタマイズして利用しました。
内容は GTM の Monitoring API を利用し発火状況を GA の analytics サーバーへ送信するというものです。今回はヒット数を費用内でおさめることができました。
GTM Monitoring in Google Analytics
その後、３ ヶ月ほど実運用をしてデータをため Bigquery へエクスポートしました。
そして、下記の ３ 種類のタグリストを Spread Sheet の Data Connector などを利用しながら処理をして、直近の３ヶ月で発火しておらず、かつ、消さないで欲しいタグを除外したものをリストしました。
- 溜め込んだ GTM Monitoring in Google Analytics のタグリスト
- 事前に事業部から削除しないで欲しいと言われているタグリスト （除外リスト）
- ドラフトにある最新のタグリスト
最後に、生きていないと思われるタグを事業部同意のもと削除しました。
結果
コンテナ内のオーナーと目的の把握 のタイミングで -28pt 削減し、
94% → 66%まで減少！(-28pt)
続いて、コンテナの発火状況の把握では -21pt 削減し、
70% → 49%まで減少！(-21pt)
合計 -49pt 削減することに成功しました。 🎉🎉🎉
まとめ
基本的に GTM は無料のため利用者が多く、いろんな人が Tips を書いていたり、個人でカスタムテンプレートを作ってくれていたり、API が用意されているので処理が楽におこなえたり、いい世界ですね。