Zenn
Open10

サーバサイドGoogle Tag Manager学習メモ

Yusuke KawabataYusuke Kawabata

そもそもサーバサイドGTMとは？

従来のGTMを置き換えるものではなく、併用するもの。エンジニア的に言えば設定を柔軟に変えれるプロキシ。ややこしいのでコンテナ・トリガー・イベントっていう同じ名前空間を使わないでほしかった・・・

自分の理解の範囲で名づけるとこういう命名になる

  • サーバサイドGTM・・・GTM向け独自ドメインプロキシ
    • コンテナ・・・プロキシインスタンス
    • トリガー・・・入力値
    • イベント・・・変換成形された入力値
Yusuke KawabataYusuke Kawabata

サーバサイドGTMと従来のGTM（ウェブコンテナ）の関係

サーバサイドGTMからは、ウェブコンテナを設定する画面がある。これが何のためにあるのかはまだわからないが、どうも必須設定のようだ。

当初、このウェブコンテナを設定することにより、ウェブコンテナ側に設定された従来のタグたちが勝手にサーバサイドGTM対応に代わる魔法のソリューションかとおもったが、全くそんなことはなかった。

ウェブコンテナにたとえば３０個のタグがセットされていた場合、以下の３つの選択肢があるはず

  • そのままクライアントで発火し続ける（サーバGTMを使わない）もの
  • タグ単位で、送出先を解析ベンダーではなくサーバサイドGTMに変更できるもの（GA4など）
  • ウェブ側のタグ側は送出先の変更に対応できないが、GA4などのサーバに送出されたイベントを形式変換すれば計測ベンダーのサーバ側で受け取れる（サーバtoサーバ）ため、これを機にクライアント側のタグを除去するもの

なので、基本は既設のタグごとに移行計画を立てないといけないっぽい

Yusuke KawabataYusuke Kawabata

導入はちょっとづつやること

サーバサイドGTMの導入を行うにあたり、Googleでは並行稼働を推奨している。なので、以下の２つをサーバサイドGTM用に別途用意することにした。

  • GA4 プロパティ
  • あたらしいウェブコンテナ（従来のGTM）

もちろん、タグ単位であるため、ウェブコンテナは用意しなくてもいけるっぽいのだがgtm.jsも独自ドメインから配信したりとネットワーク系の作業が伴うので、うっかり既存のタグぜんぶ発火しなくなりましたという事故を防ぐために分けた方がいいと思った。

Yusuke KawabataYusuke Kawabata

というわけで実装手順としては

  • サーバコンテナを立ち上げて独自ドメインを設定する
  • サイトにサーバGTMからjsが配信されるウェブコンテナを設置する（既存のGTMと併存）
  • まずGA4をなんとかうごかす
    • クライアントの設定
    • 新設するGA4プロパティの設定
    • pageviewの設定
    • その他イベントの設定
  • GA4以外の設定
    • Google系
    • それ以外
Yusuke KawabataYusuke Kawabata

あれ、タグ少なくね？

設定を開始しようといろいろみていると、タグの種類が極端に少ないことが分かった。サーバ側にJS書いたらいい感じにブラウザ側で実行されていい感じにファーストパーティから配信されるJSとして動いてくれると誤解していたのでまずここで混乱した。

最初の命名で書いた通りクライアントが入力側なら、タグは出力側のようだ。だからカスタムHTMLとかカスタムJSみたいなクライアント側の概念は存在せず、あくまでどうHTTP POST（あるいは）GETとして相手先サーバに投げるか　というものを定義する。

後述するが、ここで各ベンダーの処理を詳しく動かすには「テンプレート」が必要なようだ。

Yusuke KawabataYusuke Kawabata

ここで、「俺たちは3rd Party Cookie問題をなぜ回避したいのか？」という点に立ち返る。基本的には、アクセス解析などのブラウザセッションをまたいだユニークユーザを取得したい。ひいては、広告効果の測定でそれらの情報を利用したい。

サーバサイドGTMはこれらのうち、CookieをJSではなくファーストパーティ（サブドメインの）httpレスポンスを使ってセットすることにより実現しているものの、では、このCookieはだれが利用できるのか。

GA4クライアントの挙動に関してはいまいちわからないので、この分野で便利ツールをたくさん出しているstape.ioのドキュメントを見ることにした。

たとえばstape.ioではMixpanelがいい感じに使えるように「テンプレート」と呼ばれるものを提供している。

タグのギャラリーと、タグのテンプレートのギャラリーの違いが分かっていない。よくみるとウェブコンテナ側のGTMにもある。

ウェブコンテナ（ブラウザ側）のテンプレートはこんな感じで、GASみたいにGTMのサンドボックス内で動作するスクリプトっぽい。いちいちカスタムスクリプトを張らなくても、非エンジニアがAPIKEYとかそういうのを入れるだけでタグが導入できる機能みたい。
https://ayudante.jp/column/2019-05-24/18-04/

これが、サーバ側ではたぶんだけどマストになるみたい。このテンプレートを使うことでサーバ側GTMにおいてもCookieの読み書きや各種変数の取得が可能になる模様。

ここらへんは自身がないので認識合わせしたいところ

Yusuke KawabataYusuke Kawabata

というかテンプレートってコード見えるんだ。めちゃくちゃありがたいね。サードパーティベンダーの皆さんはここに公式テンプレートを提出することもできるし、「このコードをコピペして、入力項目はこのようにセットしてください」ってやってもいいわけですね。ありがたい

こんな感じでCookieの読み書きを行うことがわかる。なおリファレンスはこちら
https://developers.google.com/tag-platform/tag-manager/server-side/api?hl=ja#setcookie

Yusuke KawabataYusuke Kawabata

次にパラメータをクライアント→サーバGTMに渡す方法

基本的に、カスタムディメンションなど、GA4で使っているパラメータ類は、dataLayerにセットしていようが別の方法だろうがサーバGTMコンテナに飛んでくるので、GA4クライアントで受け取って利用することができる。

問題は、dataLayerにセットはしているがGA4では使っていないパラメータをどうサーバサイドGTMに渡すかだが、２つある

  • GA4でダミーイベントを作成し、そのカスタムイベントのValueなどで渡す
  • GA4は使わず、stape.ioのデータタグ／データクライアントなどの汎用ツールを使う

個人的には後者が好みだけど前者の方が最小限のいじり方でできるので、非エンジニアは前者の方がいいかもしれない。

Yusuke KawabataYusuke Kawabata

その他メモ：

  • GA4はプロパティを新たに作ればよい
  • Google Adsのコンバージョンはアカウント単位で分けることができるがキャンペーン単位ではできない、並行稼働どうするか調整
  • Facebook Adsは本件とは別件でCAPIを推進しており、Meta Pixelと重複で送る場合event_idが一緒なら重複除外を行ってくれる

GTMにおける「クライアント」は優先度があり、１つのクライアントがリクエストを受諾すると他が受諾しない、というのはどのように実装されているのかわからなかったが

  • 優先度順にとりあえず実行される
  • クライアント側からのパスをみて受諾するか判断する
  • 受諾する場合はclaimRequest関数を呼ぶ
    というながれのようだ。stape-ioのdata client実装がわかりやすい

https://github.com/stape-io/data-client/blob/main/template.js#L47