読者です 読者をやめる 読者になる 読者になる

トレジャーデータ(Treasure Data)公式ブログ

トレジャーデータ(Treasure Data)公式ブログです。

Data Connector for Google Analytics Reporting 徹底解説 その2

Data Connector Web アクセスログ データ収集

2. Google APIs 上での設定

2-1. ログイン

f:id:doryokujin:20160912151147p:plain

↑ 適切な Google アカウントで Google APIs にログインします。「適切なアカウント」とは,取得したい Google Analytics に API を通じてアクセスすることが許されているアカウントを意味します。

2-2. プロジェクトの作成

2-2-1. Project 新規作成

f:id:doryokujin:20160912151211p:plain

↑ Projects ボタンから「Create project」を選択し,Data Connector で利用するためのプロジェクトを作成します。

f:id:doryokujin:20160912151225p:plain

↑ 今回は「GA to TD」というプロジェクト名を与えています。

2-2-2. Service Account の新規作成

以下,「GA to TD」プロジェクト下で設定を進めて行きます。

f:id:doryokujin:20160912151252p:plain

↑ まずは「Service Account」を新規作成します。このアカウントは後ほど GA への API によるアクセスを許可するアカウントとして利用されます。この「Service」アカウントは,特定のプロジェクト内で作成されるアカウントであり,Google APIs にログインした一般の Google アカウントとは異なる概念のものです。

f:id:doryokujin:20160912151318p:plain

↑ 今回は「treasure-data」というサービスアカウントを作成します。オプションの選択肢はどちらも指定しておきます。「Create」ボタンを押すと,本サービスアカウントにおける認証情報が JSON ファイル(今回の例では GA to TD-18f4c65b19b3.json という名前)としてダウンロードされます。

↑ このJSONファイルの private key 情報は後の Embulk の設定ファイル内でごそっと利用するので大切に保管するようにしてください。

f:id:doryokujin:20160912151654p:plain

↑ また,同時に「treasure-data@ga-to-td.iam.gserviceaccount.com」というサービスアカウントIDが作成されます。後の GA の管理画面で,この ID に API アクセス許可の権限を与えることになります。

2-3. 使用する Analytics API を有効にする

2-3-1. API の検索

f:id:doryokujin:20160912151718p:plain

↑ 次にこのプロジェクトで使用する API を有効にしていきます。今回は GA に関係する2つのAPIを登録します。

「Library」の検索バーから

  • Analytics API
  • Analytics Reporting API V4

を検索し,この2つを有効にします。

2-3-2. API の有効化

f:id:doryokujin:20160912151745p:plain

↑ それぞれの API リンクに入ってこの API を「Enable」にします。

f:id:doryokujin:20160912151833p:plain

↑ API を有効にすると,「Dashboard」メニューから,登録された APIを一覧で参照することができ,かつ API のモニタリングがその時点から開始されます。

2-4. 終わりに

Google APIs で設定する項目について紹介しました。次にこの作成したサービスアカウントIDで,取得対象のGoogle Analytics のデータにアクセスできるように,権限を追加していきます。

 

Data Connector for Google Analytics Reporting 徹底解説 その1

Web アクセスログ データ収集 Data Connector

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 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 」の紹介から導入方法,さらにはどういった分析ができるかまで,徹底的に解説していきます。

APIレスであらゆるデータの統合を可能にする Datorama は新時代のマーケティングダッシュボード 〜①イントロ編〜

Datorama Visualization アドテク

はじめに

本記事ではトレジャーデータともパートナーシップを持つダッシュボード「Datorama」を紹介していきます。

 

f:id:doryokujin:20160707151125p:plain

主に広告業界のマーケティングダッシュボードとして不動の地位を確立しつつある Datoramaは独自の技術によってあらゆるマーケティングデータを統合することを可能にした,唯一無二のツールです。本記事では Datorama の主要な機能・概念を紹介するとともに,トレジャーデータと連携することによるシナジーについて解説していきます。

Datorama が持つ独自の機能とは?

Datorama は他のダッシュボードに無い独自の機能・概念をもっています。

  • 「Data Streams」であらゆる Web/広告サービス,テキストファイル,データベースベンダーからのデータ収集を一元化
  • 「Total Connect」で API 不要で Twitter や Facebook, Google Analytics などのサービスのデータを収集
  • 統合分析を念頭に置いた「Data Mapping」機能により,データ統合ダッシュボードの作成が容易
  • 様々なチャートや広告配信結果の可視化に特化したグラフなどを含む「Widget」が分析者の意図に沿ったダッシュボード作成を支援

 Data Streams

「Data Streams」は,Datorama から取得可能なデータソースを意味します。取得できるデータソースは大きく分けて3種類:「Marketing Vendors」「Flat Files」「Techincal Vendors」があります。

f:id:doryokujin:20160707153121p:plain

↑ とりわけ「Marketing Vendors」に属する web/広告サービスデータは,データ分析にクリティカルなソースでありながら,他のダッシュボードツールでは実装していなく,分析側が個々の API を使ったスクリプトを作成し取得しなければならない,それなりにコストのかかるデータでした。

Total Connect

「Total Connect」は,従来 API が必要であった Marketing Vendors に属するサービスデータを独自の機能で API 不要で簡単に取り込むことのできる非常に優れた機能です。

f:id:doryokujin:20160707153918p:plain

↑ 例えば facebook とは,IDの連携設定を行うだけで,自動的にデータを取り込んでくれます。その際のカラム名なども Datorama 側で自動決定してくれ,(ここは重要です)かつデフォルトのデータプレビュー機能画面まで自動で作成してくれます。(下図)

f:id:doryokujin:20160707153947p:plain

Data Mapping

複数のデータソースを統合する場合,統合の際にどのカラム名同士を紐付けるかは悩ましい問題です。また,データソースが増えたり複数人でデータを管理していく際には明確な「Data Mapping」ルールが必要となってきます。Datorama はそこに独自の工夫を盛り込んでいます。

f:id:doryokujin:20160707154533p:plain

↑ Datorama では,取り込んだデータソースの「オリジナル」のカラム名は使用しません。オリジナルのカラムは Datorama 上の「グローバル」なカラムに各々マッピングされて管理することになります。ダッシュボード作成の際にはこの「グローバル」なカラムを使用することによって作成者がデータ連携を意識しなくても自然なデータ統合ダッシュボードが作成可能になるのです。

Widget

どれくらいの種類のチャート機能を持っているかは,ダッシュボードツールを選定する際の重要な項目かと思います。Datorama のチャート機能は「Widget」と呼ばれますが,これは一般的な棒グラフなどのチャート群に加えて,広告マーケティングに特化した可視化機能を多数有しています。

f:id:doryokujin:20160707155212p:plain

Datoramaは「Social」や「Web Analytics」「Marketing」など,それぞれの業界に特化した可視化機能を含め,現時点で66種類の widget を備えています。

 

次回からは個々の Datorama の特筆すべき機能を,実際にデータを入れながら紹介していきたいと思います!