Google Tag Manager APIの導入では権限、版、確認、公開を分けて管理する

Google Tag Manager APIを使う目的は、公開操作を無人にすることではありません。複数の利用者やコンテナを繰り返し管理するときに、作業をそろえ、変更の経路を記録することです。

Google Tag Manager APIの発表では、利用者の作成と管理、コンテナやタグの確認と公開などを、APIから扱えると案内されています。自動化する前に、コンテナ、タグ、利用者権限、版、確認用表示、公開を別の対象として設計してください。

コンテナは設定をまとめ、タグは個別の計測処理を持つ

コンテナは、サイトや用途に必要なタグをまとめて管理する単位です。タグは、Google Analyticsなどへ計測データを送る個別の設定です。コンテナの識別子を間違えると、正しいタグ設定でも別のサイトへ変更を入れてしまいます。

APIへ渡す情報は、対象アカウント、対象コンテナ、変更するタグの順で確認します。タグ名だけで対象を決めず、コンテナの識別子とサイトの対応表を管理側に残します。

複数サイトへ同じタグを追加するときも、一つのコンテナをそのまま複製すればよいとは限りません。計測先のProperty、URL条件、イベント名など、サイトごとに異なる値を分離します。共通部分と個別部分を分けてからAPIで処理します。

利用者権限は作業範囲と公開責任に合わせる

APIでは利用者管理も自動化できます。しかし、作業する人すべてへ公開できる権限を渡す必要はありません。設定を作る役割、内容を確認する役割、公開を承認する役割を先に決めます。

制作会社がタグを追加する場合でも、アカウントの所有、利用者の追加と削除、最終公開の判断は、発注側で把握できる状態にします。担当者の退職や委託先の変更が起きても、コンテナへ入れなくならないよう、管理者と復旧手段を確認してください。

権限を一括設定する処理には、対象者、対象アカウント、対象コンテナ、付与する権限、失効日を入力として持たせます。メールアドレスだけを一覧にして実行すると、別のコンテナへ過大な権限を渡す危険があります。

版、確認用表示、公開を一つの処理にしない

APIでタグを変更した直後に公開まで進めると、間違いを確認する時間がなくなります。変更内容を識別できる版として残し、確認用表示で動作を確かめ、承認後に公開します。

三つの役割は別です。

APIの処理単位を分ければ、設定を作る処理が成功しても、確認に失敗した時点で公開を止められます。版の識別子を記録しておけば、確認した内容と公開した内容が同じかも照合できます。

APIの処理には停止条件と実行記録を持たせる

大量のコンテナへ同じ変更を加える場合は、成功件数を増やすことより、誤った対象で止まれることを優先します。処理前に対象コンテナと現在の設定を取得し、期待した状態と違えば変更しません。

一件の処理は、次の順で組み立てます。

1. 対象アカウントとコンテナを特定する
2. 現在のタグと権限を取得する
3. 変更内容との差を作る
4. 変更理由を付けて版を残す
5. 確認用表示で発火条件と送信内容を確かめる
6. 承認された版だけを公開する
7. 公開後の状態を取得して記録する

途中で取得や確認に失敗したら、そのコンテナの公開を止めます。ほかのコンテナまで止めるか、失敗した対象だけを除くかも、実行前に決めておきます。

APIの認証情報と変更記録は自社側で保管する

APIを制作会社の道具としてだけ管理すると、委託先を替えたときに処理内容や権限が分からなくなります。認証に使うGoogleアカウント、対象コンテナの一覧、処理を実行するプログラム、変更記録の保管場所を自社側でも把握してください。

最初から全コンテナの公開を自動化する必要はありません。まず一つの検証用コンテナで、設定作成、版の保存、確認用表示、承認、公開の境界を確かめます。APIは作業を速くしますが、所有者と公開責任を決める仕事までは代行しません。