Data Connector for Google Analytics Reporting 徹底解説（1）

2022年7月21日

1. アクセスログに対するトレジャーデータの試み

様々な業界で活用されているトレジャーデータですが，元祖 The ログと言えば「アクセスログ」に他なりません。トレジャーデータではこの歴史も古く，ライバルも多いこのアクセスログ分析の分野において，以下のようなユニークなアプローチを持っています。

1-1. Treasure Data JavaScript SDK

Treasure Data JavaScript SDK（以下 Treasure JS SDK）は，Google Analytics（以下 GA）のユニバーサルアナリティクス（Googleタグマネージャ）と同じように，ページ内の Java Script 領域にトラッキングコードを埋め込むことで，リアルタイムのデータ収集を可能にするものです。Treasure JS SDK が GA をはじめとした他のトラッキングツールと決定的に異なる点は，「収集した生データにアクセスできる」事にあります。（※この記事においては「生」データを，ユーザー識別IDとタイムスタンプが取得できているレコードセットと定義します。）

一般的なアクセス分析ツールは，トラッキングで取得したアクセスログそのものには触れる事ができず，レポートと呼ばれる Web UI を通じて集計済アクセスデータを眺めることになります。レポートで集計済のデータしか見れないとはいえ、担当者の多くがやりたい集計はすでに集計済レポートとして用意されていたので，このことに言及されるシーンは少なかったと思います。

しかしながら，TREASURE DMPのようにアクセスログのみの分析に留まらず，統合的なデータ収集・分析を行いたい場合には，アクセスログを，他の生データと同様に扱う必要があります。
また，巨大なデータ収集プラットフォームと強力な集計処理エンジンの恩恵によって初めて実現できる，「パス分析」や「バスケット分析」と呼ばれる応用的な分析も，トレジャーデータを使えば誰でもそれが実現できるようになりました。このような応用的な分析は，既存の Web UI 上のレポートには存在せず，また様々な切り口があるという分析の抽象性より，一意に表現することができません。これらの応用分析を実現するためには，生データにアクセスできること，それを自由に加工して自由なエクスポート先に流せることが肝要です。

ここで，Treasure JS SDK を用いたパス分析の事例を以下のリンクでご紹介します。

アクセスログ分析最前線：Treasure Data JavaScript SDK で始めるパス分析その１
 アクセスログ分析最前線：Treasure Data JavaScript SDK で始めるパス分析その２
 アクセスログ分析最前線：Treasure Data JavaScript SDK で始めるパス分析その３
これに関心を持たれた方は，是非 Treasure JS SDK をお試し下さい。

1-2. Data Connector for Google Analytics Reporting

トレジャーデータのアクセスログに対するアプローチのもう一つに，先ほどの Treasure JS SDK とは異なるデータ収集ツールを利用する方法があげられます。それが「Data Connector for Google Analytics Reporting」です。

こちらのアプローチでは，GA によって収集・集計されたレポートデータを取得することによって，Treasure JS SDK のような新しい収集ツールを仕込むインテグレーションが必要ありません。さらに，GA はすでに多くのユーザーが導入しているので，ユーザーであれば誰でもすぐにその恩恵が受けられます。

とはいえ，Data Connector が取得するデータは生データではなく，GA の様々な View で利用されている集計済のデータに制限される（それでも非常に多くのデータ項目を取得できますし，既存のGAレポートに現れないより踏み込んだ分析も実行できる余地は十分にあります。）ので，Treasure JS SDK とは明確に区別される手法となっています。

1-3. GAで生データに近いものを取るには？

GA には Custom Dimension，Custom Metric と呼ばれる項目があり，この項目にはユーザーが任意の変数を設定することが可能です。この Custom Dimension 機能を使えば，標準では取得できない GA の以下の項目ごとにデータを取得することができ，かなり生データに近いものがとれます：

Client ID (≒ Cookie ID)：GA 内で利用されているユーザー識別ID
User ID：ユーザー側で保持している，自社の他サービスと紐付け可能な User ID
Unix Timestamp：イベントが発生した正確な時間（GA では標準で分単位でサマられたデータまではとれます）

Timestamp を取得すると大変なデータ量を取得する事になり，また活用方法もそれほど広く無いため現実的では無いかもしれません。一方でユーザーを識別するための ID 系（Client ID, User ID）は分析において非常にクリティカルな項目になっていますので，かならず設定するようにしましょう。以上の Custom Dimension の取得方法は後述します。

1-4. Data Connector for GA の制限

Data Connector の利用制限は，Google Reporting API v4 の仕様に準じます

制限1. 一度に取得できる Dimension 数は7まで

8個以上のディメンジョンを設定すると，次のようなエラーが返ってきます
“(ClientError) badRequest: Requested 8 dimensions; only 7 are allowed.”
Data Connector では設定ファイル内の time_series 項目に dateまたは dateHour Dimension を設定する必要があります。自由に使える Dimension は 6 つまでとお考え下さい。

制限2. 一度に取得できる Metric 数は10まで

11個以上のディメンジョンを設定すると，次のようなエラーが返ってきます
“(ClientError) badRequest: Requested 11 metrics; only 10 are allowed.”

制限3. 組合せて取得できない Dimension, Metrics がある

User Metrics の “ga:1dayUsers” などは，同時に使用する他の Dimension, Metrics を制限します
“(ClientError) badRequest: Selected dimensions and metrics cannot be queried together.”

制限4. 1つのプロジェクトで 50000リクエスト/日，10000件/リクエスト

2-2. でプロジェクトを作成しますが，GA のリクエスト回数はプロジェクトごとに 50,000リクエスト/日となります。また，1リクエスト当たりで取得可能なレコード件数上限は 10,000件です。理論上の最大取得レコード件数は 50000*10000=5億レコードとなりますが，取得する Dimension 数や Metrics 数にも依存するのでこれよりは少ないはずです。

制限はそれほど厳しくありません，まずは積極的に活用しましょう！

上述の制限の中で唯一気になるのは制限4. ですが，これらの制限は他のAPI群に比べればはるかに緩いものとなっています。自社サイトがそれほどの規模でなければ，これらの制限はまずは気にせずに運用・分析を開始して良いと思います。そうすればどれくらいのデータ取得量・取得範囲・取得インターバルであれば問題なく運用できるのかが経験的に見えてくると思います。また，後述するユーザーID単位や Timestamp 単位での生データに近い数のレコードも取得も，実は十分に現実的である事も見えてくるはずです。

1-5. 終わりに

ではどちらのデータ収集手段をを使えば良いのかについては，最適解は「両方の手法を利用する」ことですが，以下のケースで使い分けていただければと思います

既に GA のタグが埋め込まれているか否か（否なら，Treasure JS SDK を導入する余地は十分にある）
サイトに埋め込んでいる js トラッキングコードを自由に書き換えることができるか否か（否なら，GA のリソースを最大限活用するしかない）
実践したいアクセス分析が，従来の枠組みを超えた分析（自社サービスに特化した分析，可視化やレポート化が難しい分析）をしたいか否か（否なら，GAのリソースを、もとより GA のレポートをしっかりと活用する）
分析がアクセスログのみにとどまらず，広告やECデータ等の、他の様々なデータを統合的に扱っていきたいか否か（否なら，GA で十分かもしれない）

さて，本記事では「Data Connector for Google Analytics Reporting 」の紹介から導入方法，さらにはどういった分析ができるかまで，徹底的に解説していきます。