皆さん、こんにちは。エンジニア・技術広報の平木です。

プライバシー保護の文脈で3rd Party Cookieが廃止の方向になったりしている昨今ですが、そんな状況で注目を集めているのがサーバーサイドGTM(Google Tag Manager)だと思います。今日はジョブメドレーでサーバーサイドGTMを導入したと聞いたので、どのように導入していったのかを聞いてみました！

登場人物

サーバーサイド GTM とは？

ーそもそもサーバーサイドGTMとはなんでしょうか？今まであったGoogle Tag ManagerとサーバーサイドGTMは並列な存在なのかとか、いまいちよくわからずなんです。

伊藤：
そうですよね、最初はそこが僕もイメージつきにくかったです。

橋爪：
サーバーサイドGTMの説明自体は過去に色々な記事が出ているので、そちらを見ていただくとその意義みたいなところはよくわかると思います。日本ではアユダンテさんが詳しそうなので、私はこちらの記事をよく参考にしています。

ちょっとややこしいんですが、これまでのGTMの中にサーバーサイドGTMを呼び出すタグが入っているようなイメージです。初回はフロントでGTMのタグを読み込んで、分岐みたいな感じでサーバーサイドGTMにつながります。

伊藤：
WEB GTMの代替ではなくて、セットで使うものなんですよね。でも、この関係性はネットにあがってる記事や図をみても最初はよくわからなかったポイントでした。

橋爪：
実はサーバーサイドGTMという言葉をGoogleは使ってないんですよね。サーバーサイドタグ設定とか、サーバーサイドコンテナとか言っているはずです。サーバーサイドGTMの呼び方がいま一般的になっていたり、Googleのドキュメントだとゴリっと多言語に変換していたりするので、少しイメージをつかみにくくなってしまっているのかなと思います。あくまでも機能が増えたイメージがよいかと。

ーなるほど…！確かに既存のGTMとは別のサービスなイメージでした。ジョブメドレーで全般的に使っている仕組みにアドオンして、サーバーサイドの対応をやるようになったということですね。

なぜはじまったか

ーでは何故サーバーサイドGTMを導入したのか教えてください！

橋爪：
Googleの公式ブログでは導入するメリットを3つあげています。

これはもちろんのこと、ジョブメドレーのサーバーを介して通信できるようになるので、3rd Party Cookieを使わずともセキュリティと精度の高いやりとりが実現できます。それによって精度の高いマーケティング施策を実行できると考えたからです。

ー今までCookieを使って送っていた情報なんかも、ジョブメドレー側でさらに選別してセキュアに送れるようになるんですね。しかもフロントエンドのリソースを使わないから高速だと良いことづくめですね。

橋爪：
Cookieの制御が簡単にできるようになるのはありがたいですし、一番のメリットですね。ただ、まだまだ対応しているツールや広告媒体が少ないのは事実です。
入社面接の時に「ずっと（サーバーサイドGTMを）やりたいと思っていたんだけど、できる？」と聞かれていたこともあり、実際入社後に着手することになりました。

ーお二人とも前職で広告業界に携わっていたと思うのですが、今回はその経験が活きてるんでしょうか？

伊藤：
前職では広告配信や素材管理のシステム開発をしていました。広告業界のエンジニアでも、サーバーサイドGTMを知ってる人はまだ少ないニッチな領域だと思いますね。GTMをがっつり触っていたわけではないのですが、組み込まれる広告タグの開発などをやっていたので、なんとなく何ができるかイメージがついていたことが、今回のプロジェクトの役に立ったように思います。

橋爪：
新卒で入った会社で、GTMやデータフィードといった領域をディレクターとして携わっていました。いわゆるWebディレクターとは違って、ニッチな領域担当です。前職の間ではあまり触ってなかったので、思い出しながらやっていました。

どうやったのか

ーここからは具体的な導入のプロセスを聞いていきたいと思います。

伊藤：
2021年の10月頃にはじまり、ざっくり年内には終わらせようというスケジュールでしたね。プロジェクトメンバーはこの二人がメインで、あとは上長のエンジニアに適宜報告して、というスモールな体制です。まず手始めに、FacebookのコンバージョンAPIをやりきるところからスタートしています。

橋爪：
サーバーサイドのコンテナを導入するにしても、わかりやすいゴール設定が必要だと思ったんです。FacebookはコンバージョンAPIというサーバーサイドの通信に対応しているので、最初にはじめるものとしてはちょうどよいと考えました。

ーたしかにゴール設定は大事ですよね。どういう作業からはじまったのでしょう？

橋爪：
最初はとにかく調査ばかりでした。そもそもタグがどこにあるか、全体を整理しなおすところから始めています。

伊藤：
橋爪さんの入社がきっかけでスタートしたプロジェクトだったのもあって、GTMの管理状況が若干カオスだったので、まずはタグの整理が必要でした。ジョブメドレーで使っているタグを一からピックアップしていって、どこから呼び出されているのかを調べて整理して…

ージョブメドレーはもう10年以上経ちますもんね

橋爪：
GTMに入っているタグと、直にコードに入っているタグと。他にもGTMに入っていても検証環境にしかないものがあったりとか。そういうのを整理しないとプロジェクトが進んでいった時に想定外の変な影響が出てしまうかもしれませんから、まずは下地を整えました。ここに最初の一ヶ月くらいはかかりましたね。

伊藤：
ソースコードに埋め込まれているものはエンジニアのほうがわかるので、僕が確認して。GTMに入っているものは橋爪さんが担当していました。

橋爪：
まだ残っているものもあるといえばあるのですが、かなり整理された状態になりましたね。

ー大変な作業でしたが、今後のベースになる重要な部分ですよね。次はどんな工程になるのですか？

橋爪：
次はインフラの設計ですね。

伊藤：
やってみた系の記事があまりなくて、全体像がわかりませんでした。最初はGoogleの公式ドキュメントに沿ってはじめてみました。結構簡単に構築できるんですが、もちろんGCPに構築する仕様になっていました。
ジョブメドレーのインフラは主にAWSを利用しているので、管理するサーバーやドメインが散らばっていると管理が複雑になる懸念がありました。

橋爪：
ひとつサーバーを立てて、その中にGTMを入れるイメージなんです。そこに普通のGTMでリクエストを送って処理します。計測ツールや広告のCookieなどの付与も発生しますし、1st Party Cookie を付与できるドメインにしないといけないなどもあります。ジョブメドレーはQA環境と本番環境でドメインが違うので、どちらでも動くようにする必要もありました。

ーサーバーはGCPに立てているんですか？

伊藤：
調べた限りGCPでは、エンドポイントごとにサーバーを構築する必要がありそうでした。ジョブメドレーでは開発者ごとにSandBox環境の用意があったり、全環境にサーバーサイドGTMを導入するとサーバー管理だけでも複雑になるので、他になにかよい方法はないかなと思ってました。GoogleからDockerイメージが提供されていて、今はそれをベースにタグ設定サーバーがAWSに構築されています。

ー開発がスタートしてからはスムーズに進みましたか？実際適用するフェーズになるとまた大変なこともあるイメージですが…

橋爪：
実装のスコープもあると思っています。単純にサーバーサイドで動くコンテナを作る話と、そこにタグいれて動くようになる話と。前者は伊藤さんにやってもらっていました。後者の設定は僕がするのですが、サーバー間の通信なので、タグが正しく動いているかの確認をしてもらう必要はありました。普通のタグはブラウザで確認できるのですが、それができないので、ちゃんとサーバーに飛んでいるのか伊藤さんに確認してもらっていました。

伊藤：
サーバーでログをみたり、サーバーコンテナにプレビューモードがあるので、それを使って確認していました。

橋爪：
ブラウザ⇔普通のGTM⇔サーバーサイドGTM⇔媒体と通信するので、どこまで飛んでて詰まっているのか一個一個確認する必要がありました。

ーQAやデバッグはいかがでしょう？

伊藤：
正直ソースコードを実装するフェーズはほとんどなくて、動作検証がほぼほぼでした。検証のポイントとして、サーバーを新設したのでリクエストに対する負荷には注意しました。直近のアクセスログから算出した最大リクエスト数でも余裕でさばけるよう、インフラチームの方に構築してもらいました。

ーなるほど。これは一度実装できれば違う媒体にも転用できるものなんですか？

橋爪：
GTMとサーバーサイドの通信ができるようになれば、媒体はマーケティング担当者で増やせるので問題なく転用できます。

伊藤：
リリースはイベント数が全体数に対して少ないものから始めました。例えば、求職者の方が会員登録をした時や求人に応募した時にイベントを飛ばすものです。全体のPVからみると少ないイベントから始め、徐々にイベント種別を増やしていきました。今では秒間100リクエスト以上のPVもさばけるようなサーバー構成となっているため、以降の媒体追加時の対応は必要ないです。

橋爪：
ネットに載っている情報をそのまま試したら動かないこともありました。Googleの広告の変数の設定が間違っていた記事があったりもしましたね（笑）。公式ドキュメントには載っていない部分だったので、結構手探りなんです。
そういえば、公式ドキュメントでもちょっと困ったこともありました。「顧客」って書いてある部分があって、顧客ってどういうことだろう…誰のことだろう…悩んでいたのですが「Client」の誤訳だったことがあったりしました（笑）。「Client側のサーバーで」と書きたいところが「顧客側のサーバーで」みたいになっていたんです。※すでに修正されています

ーちなみにこれらの工程はGTMに詳しければ応用できるものです？それともまるっと違う概念でしょうか？

橋爪：
個人でやっているWEBサイトといった小規模なものなら同じような知識でいけると思います。ただ、ジョブメドレーのような大規模なサイズになってくると、QAと本番のドメインの違いなどもあって、根本を理解していないと応用を効かせることが難しいかもしれません。ちなみにFacebook側もドキュメントがあんまりなかったですね…。

伊藤：
今振り返ると作業量はそんなに多くないけど、手探りでやった期間が長かったですね。
ジョブメドレーではFacebookのピクセルタグが導入済みだったのですが、既存で送信しているイベントの種類やパラメータを確認するところから始まり、コンバージョンAPIへの移行を進めていました。

ーリリース前後はスムーズにいきましたか？

伊藤：
そうですね、結構スムーズでした。GTMはQA環境で同じ行動をとってタグが発火するのかどうかをプレビューで確認できたので、本番で計測できなかったという事故は起きていなかったです。

ー導入後のプラス要素はいかがでしょうか？

橋爪：
マーケティング施策の精度は確実にあがりました。今までちゃんとCookieを付与できていなかったユーザーへアプローチできるようになったんですね。AppleがCookie規制を進めていますが、サーバーサイドから1st Party Cookieを付与できるようになったことで数字への影響がありました。
例えばFacebookの後にGoogle Analyticsもサーバーサイドに移行したんですが、導入前後でユーザー数の計測に影響がありました。Cookieが残るようになって同一ユーザーのカウント精度があがっています。そのおかげで、狙い通りのマーケティング施策を実施できるようになったのは大きいと思いますね。AppleのCookie規制の影響を受けていたのかとびっくりしました。

ーこれからはどんなことに取り組んでいきたいですか？

伊藤：
橋爪さんからあったように数字での影響は出てきているので、パフォーマンス面での影響も出していきたいです。
サーバーサイドGTM導入のメリットとしてフロントエンドのパフォーマンス改善に繋がることが挙げられますが、残念ながら今回は改善に至りませんでした。
これにはGTMだけではなく、サイト全体で動いているJavaScriptも改善対象になってくると思うので難しい話だとは思いますが、これができると求職者の方により快適に使ってもらえますし、 SEO向上にも繋げられるのでぜひチャレンジ出来たら良いなと思います。

橋爪：
媒体側が対応したら順次設定していきたいですね。広告業界的には対応したメニューがある代理店が増えてきている印象です。
難しいのは、Cookieの関係で広告媒体が自社プラットフォームを持っていないとあんまりサーバーサイドGTMを有効活用できないんです。GoogleやFacebookはプラットフォーム固有のIDを持っており、Cookie以外の手段でもターゲティングできるので。今年の後半から来年末にかけてGoogle Chromeも3rd Party Cookieのサポートを段階的に廃止しますから、ますますサーバーサイドでの処理の重要性があがってきます。
ユニバーサルアナリティクス（従来のGoogle Analytics）の廃止と Google Analytics4 (GA4) への移行が正式に発表されましたし、時代にあった3rd Party Cookieに頼らないマーケ環境を実現していきたいです！

ー自分もふんわりとしか理解していなかったサーバサイドGTMですが、お二人のお話聞いて勉強になりました！！今日はありがとうございました！