トップ > ビッグデータ > Google Analytics 4 / Google Tag Managerを活用したエンドユーザー行動ログ取得の取り組み

Google Analytics 4 / Google Tag Managerを活用したエンドユーザー行動ログ取得の取り組み

ビッグデータ データ分析

AdventCalendarTitle

はじめに

この記事はDMMグループ Advent Calendar 2024の12日目の記事です。

はじめまして、こんにちは。データ基盤開発部CDPグループの野口(@yuuuuuuuuu_uuuu)と釣井です。
私達はデータ基盤開発組織の中でエンドユーザの行動ログをリアルタイムに取得するためのシステムの 開発、保守、運用導入サポートなどを行っております。

DMMプラットフォーム上にある複数のサービスの行動ログの利活用に向けて、イベントデータモデルの統一化やGoogle Analytics 4(以降、GA4)、Google Tag Manager(以降、GTM)の構成の工夫点などを紹介しようと思います。

CDPグループについて

CDP(Customer Data Platform)とは顧客一人ひとりの属性データや行動データを収集・統合・分析するプラットフォームです。
通常のデータ基盤との違いとして、広告のターゲティングやPushなどの実施策としての活用が主目的となる点です。
顧客データの活用は多くの用途がありますが、現在は、広告等のマーケティングにフォーカスしています。
重要なポイントは、1st-partyならではの顧客の重要な特徴を、経路によらず一貫した形で送信することです。
そこで私達CDPグループでは以下の点で改善を進めています。

  • MOps基本データ整備
    • マーケティング施策するうえで必要不可欠な基本情報を活用できるようにする
  • リードタイム短縮
    • 施策実施と成功体験を高速積み重ねるための運用整備
  • MOps高度化
    • GTMによるリアルタイムなchannel以外でも同様な施策を展開できるようにする。またML成熟度向上による新たな顧客insightをCDPでも活用できるようにする

CDPシステム基盤の全体

まず、どういったシステムなのかのシステムの全体像を記載します。 i3-cdp-system-all

i3とはデータ基盤開発部が提供しているシステムの名称です。
datalakeやdata ware house、datamartなど様々なものがあります。
その中でCDPグループではエンドユーザ行動ログ取得の基盤を提供しており、 GA4 GTMをメインとして使用しております。

なぜ GA4 GTMを選定したのか

全体としての選定理由

現在のシステムに移行する前は、内製のトラッキングシステムとしてGoによるAPIを提供しプラットフォームサービスレベルでETLを行い aws Athenaをベースとした分析基盤の提供しておりました。
既存システムには、以下のような課題点がありました。

  • サービスごとにイベントデータに設定される値が異なる
  • イベントデータの追加の度にテーブル定義、ETLの修正が発生
  • 動的リマーケティング等施策に必要な各種広告媒体へのデータ連携が困難

これを改善するため、GA4, GTMを中心としたシステムに移行しました。

GTM 選定理由

  • 動的リマーケティングの強化

サイト内分析やレコメンドに関しては既存システムでも十分ではありましたが、動的リマーケティングに関しては、各媒体のIFに合わせた実装が必要となり、導入コストが高くなります。
GTMを利用した場合、テンプレートがすでに用意されており、様々な媒体に対しテンプレートを使用して送信することが可能となります。

またServer Container(sGTM)を利用することでデータをenrichすることが可能となり、より精度の高いデータとして送信可能です。

dynamic-remarketing

  • Retail APIの利用

Retail APIも動的リマーケティング同様既存システム(以降、既存システム)の場合IFをあわせて実装が必要となりますが、Google Tag Managerにてタグを設定するだけで送信が可能となります。

cloud-retail-image

Google Analytics4 選定理由

  • Google AnalyticsとGoogle Adsが管理画面上で連携が可能
    • Google Analyticsのデータを自動でGoogle Adsと連携ができる
  • Google Search ConsoleやBigQueryといったGoogleエコシステムとの連携が容易
  • イベント駆動となったことによりユーザ行動の分析を解像度高く行うことが可能
    • GA4からはページの閲覧、動画の視聴、スクロールなどすべてがイベントとして計測される

上記のようにGoogle Tag MangerやGoogle Analytics4を導入により
ノーコードで表現できることが、増える点が各種選定の理由となります。

CDPシステム基盤の詳細

ここからはCDPシステム基盤の詳細について記載します。 CDPグループではGoogle Cloudをメインとして使用しアプリケーションを構築・運用しております。

i3-CDP-Tracking-Tag-API

i3-CDP-Tracking-Tag-API は行動ログを取得するために必要な初期化やDMM内部のデータをイベントの共通変数として扱うためのデータなどを HTML/JavaScriptタグとして配信するAPIです。

アーキテクチャ全体としては下記になります。

i3-cdp-tracking-tag-api

DMM内のほぼ全てのサービスから呼ばれるエンドポイントとなっているため ピーク時には4000 ~ 5000rps程度のリクエストとなっています。 バックエンドAPIはGoで実装し、マネージドサーバレスのソリューションで運用しております。

実際の配信タグ

i3-CDP-Tracking-Tag-APIでは下記の様なタグを配信しております。

  1. GeoLocation取得(Lambda@Edge)
  2. 既存システム → GA4 データモデル変換ライブラリ(CDN) 1
  3. イベント送信時の共通処理(setup/teardown)ライブラリ(CDN)
  4. GTM install script(inline)
    1. gtm.js イベントの変数、タグ、トリガーなどがJavaScriptとしてコンパイルされているもの。イベントの送信なども含まれている
  5. DMM独自共通パラメータ(inline)
    1. DMMにて識別可能なid関連の情報などをgtag.set等で受け渡し

既存システム

サービスが多く全体的にGA4 GTMのdataLayer 構造への完全移管は完了しておりません。 そのため、既存システムのデータモデルからGA4 GTMのデータモデルへのトランスフォーム をするためのデータトランスフォームの詳細までは今回は触れませんが、JavaScriptライブラリを開発し変換をかけております。

Server Container

GA4へのイベントデータの送信はServer Containerが担っています。
アーキテクチャ全体としては下記になります。

i3-server side tag manager

DNSのみAWSで管理しServer ContainerはGoogle Cloud上のCloud runで運用しております。
DNSをAWSで管理しているのは既存システムから複数のサブドメインを委任しているため 移行にかかるコストが高いため、Route53/CloudFrontをはさみGoogle CloudのLoad Balancerへ飛ばしています。

ピーク時には6000 ~ 7000rps程度のリクエストとなっています。 各サービス事に設定されているイベント数が異なり、 またイベントごとにリクエストサイズにも差異があります。 そのため、安定してイベントデータを送信するために、Cloud Runの最大同時リクエスト数を少なめにチューニングしております。

なぜサーバ経由でイベントデータを送信するのか

Server Containerは、データのenrichと中継(プロキシ)としての役割をになっており、サーバ経由でイベントデータが送信されます。
DMMではサーバ経由でイベントデータを送信する場合以下のメリットがあり、採用しました。

  • Server Containerに対し、サブドメインを設定することでサードパーティcookieをファーストパーティcookieとして扱えるようになる
    • session情報などが長くもてるようになり、より正確にユーザのイベントの計測が可能となる
  • 同意しているユーザのみに対して動的リマーケティングの精度がより高くなるようイベントデータのenrichを実施している
    • メールアドレスなど個人を特定可能な情報をkeyに含めることで個人に特化した広告の配信が可能

GA4/GTM

次に、GA4とGTMがどのような運用になっているかを簡単に記載します。
DMMはとにかくサービスが多いため、『各サービスごとの分析』と『全サービスに跨る横断的な分析』の両方を実現できる構成を意識した設計となっています。

GTM

コンテナは階層構造になっており、i3-CDP-Tracking-Tag-APIからルートコンテナが配信されます。
以降は、ルートのコンテナからゾーンを利用し、各用途別のコンテナを配信するように制御をしています。
ゾーンとは、GTMの機能の１つで、コンテナから条件に合致したコンテナを配信する機能です。
ゾーンを利用することで、一部のドメインやディレクトリ配下専用のコンテナを設置できます。
用途別のコンテナ内にタグを集約することで、管理を容易にしています。
DMMでのコンテナの用途は、広告用・プロダクト用・サイト内トラッキング用の大きく分けて3種類となります。

gtm-architecture

ゾーンを利用するメリットは大きく分けて2つです。

  • 各サービス開発者の実装工数削減
    • i3-CDP-Tracking-Tag-APIを実装するだけで、必要なコンテナが配信されるため、サービスの開発者は実装作業を削減される。
  • 障害発生時の迅速な復旧が可能
    • GTMで配信しているタグを起因とした障害が発生した場合、問題のあるゾーンを一時的に停止することで、影響範囲を最小限に抑え、迅速な復旧が可能。

分割したコンテナとそこに存在するタグの管理を容易にするため、GTMの設定内容を可視化するツールを内製しています。
現在、1000以上のタグを運用していますが、このツールによりそれぞれのタグがどんな内容でどこに埋まっているのか？を簡単に確認できます。

gtm-viewer

上記のツールでは、タグ名やタグテキスト、トリガーの条件から検索することが可能となっています。
タグ・トリガー・変数・ゾーンは命名規則に則って作成し、例えばタグ名では「サービス」、「デバイス」、「計測目的」などをデリミタで組み合わせた命名規則を適用し、検索性を高めています。 加えて、複雑なゾーン関係をUMLで描画する機能などもあり、全体の構成を把握しやすくしています。

zone-viewer

これらの機能を利用することで、GTMのコンテナ１つずつ開いて設定を確認せずとも、どんなタグが埋められているか、どんなコンテナ関係になっているかが可視化された状態で運用を行なっています。

GA4

DMMでは多くのサービスが存在しますが、GTMのルートコンテナに設置されているGA4のデータストリームは1つです。
これは、１つのデータストリームで全ての主要サービスを計測することで、全サービスドメインのクロスドメインが可能となるためです。
全サービスのwebのデータは、参照元プロパティで計測され、必要に応じてサブプロパティでも計測を行なっています。

ga4-architecture

さらに、webページの計測以外にも各サービスのアプリの計測もあるため、全サービスのwebとアプリのデータを1つのプロパティで参照できるよう、統合（ロールアップ）プロパティを用意しています。
DMMでの分析は基本的には統合プロパティでの分析を推奨していますが、計測したイベントはBigQueryにもエクスポートしています。
これはGA4のデータ探索だけでは、計測されたデータの反映までにラグがありリアルタイム性に欠けることや多くのデータを扱うことでサンプリングがかかることから、BigQuery、Looker、Looker StudioなどのBIツールも活用できる環境となっています。

イベントデータ構造

CDPグループでは[GA4] 推奨イベントをベースとし 各イベントにDMM独自のカスタムパラメータやカスタムイベントをデータモデルとしGA4を活用しています。

イベントデータモデルを定義するうえで注意している点

イベントデータモデルを定義するうえで下記2点に注意しデータモデルの策定をしております。

  • サービス同士の互換性
  • 横断した分析

DMMではECコンテンツの購入以外にも、DMM英会話の有料プラン入会やバーチャルオフィスの問い合わせなど、重要指標はpurchaseイベントで取得しています。
加えて、全サービスで同時に実施される大型キャンペーン施策やDMMの複数サービスを利用されているユーザーがいるため、サービス単位ではなくサービスを横断した分析を実施を行います。
各サービスでイベント粒度が異なるとサービス単位の分析は可能でも、複数サービスでの分析が難しくなってしまうため、上記のイベントデータモデルが活用されています。

まとめ

イベントデータを取得するための最初のタグ配信からイベントデータモデルの定義、Server Containerの活用そして最終的なアウトプットまでの一連の流れとして記載しましたが いかがでしたでしょうか。
以上が、DMMにおけるエンドユーザの行動ログを取得するための取り組みになります。

GA4 / GTMを活用したデータ取得のための参考になりましたら、幸いです。

  1. GA4データモデルへの移行が済んでいないサービスのイベントを既存システムのインターフェイスのまま送信可能とするための救済措置。本記事では詳細割愛します。↩