サーバーサイドGTMの「トランスフォーメーション」でPIIを保護する方法｜未経験から100日後にGTMのプロになる話【Day 69】

サーバーサイドGTMの環境構築はDay29で、内部を流れるリクエストを最初に受け取る「クライアント」の役割はDay68で扱いました。今日はその続き、クライアントが解釈したデータをタグに渡す前に加工できる「トランスフォーメーション」という機能を紹介します。

処理の流れをおさらいする

サーバーサイドGTMの処理は、「クライアントがリクエストを解釈する」→「トランスフォーメーションでデータを加工する」→「各タグに配信する」という順番で進みます。Day68で説明したクライアントの次の工程がトランスフォーメーションです。

トランスフォーメーションでできること

トランスフォーメーションは、特定のタグ・タグタイプ・あるいはすべてのタグに向けて、イベントパラメータを加工するための仕組みです。代表的な使い道は2つあります。

• 不要な情報を除外する：特定のパラメータだけをタグに渡すことを許可し、それ以外は破棄する設定にできます。例えば、社内向けの管理用パラメータが誤って広告タグにまで渡ってしまうのを防げます。
• 個人情報を加工してから渡す：メールアドレスのようなセンシティブな値を、そのままタグに渡すのではなく、ハッシュ化・マスキングしてから渡す、といった加工ができます。Day44で扱ったConsent Mode/プライバシー対応の延長として、「サーバー側で最後の砦としてPIIを取り除く」役割を持たせられます。

クライアントサイドでの対策との役割分担

個人情報の除去自体は、本来クライアントサイド（ブラウザ側）のdataLayer設計の時点で気をつけるべきことです。ただし、複数の担当者やツールが関わる大きな組織では、意図せずセンシティブな値がdataLayerに紛れ込んでしまうことも起こり得ます。トランスフォーメーションは、そうした「クライアントサイドでの対策をすり抜けてしまった場合の最後の防波堤」として使うのが現実的な位置づけです。「トランスフォーメーションがあるから、クライアントサイドの設計はいい加減でよい」という話ではありません。

今日のまとめ

サーバーサイドGTMは、クライアントで受け取り、トランスフォーメーションで加工し、タグで配信するという3段構えです。特にプライバシー配慮が必要なデータについては、クライアントサイドの設計を基本としつつ、トランスフォーメーションを保険として組み合わせる考え方が実務的です。次回は、GTMの応用テクニックをさらに扱います。