トレジャーデータ（Treasure Data）ブログ

トレジャーデータ（Treasure Data）ブログです。

本サイトは移転しました。新サイトにリダイレクトします。

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

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 の特筆すべき機能を，実際にデータを入れながら紹介していきたいと思います！

「データに秘められた可能性」を最大限に引き出す，そのために Wave Analytics が求めたのは究極の「インタラクティビティ」②

EC Salesforce アクセスログ

はじめに

様々な BIツール，可視化ツールがひしめく近年において，2014年10月に Salesforce が満を持して「Wave」を基盤とするアナリティクスプラットフォームをローンチしました。その中の可視化ツール：Wave Analytics は可視化ツールとしては後発組ですが，まさにその名の通りこの世界に「Big Wave」を巻き起こす牽引役として台頭していく事は明らかです。

f:id:doryokujin:20160623153522j:plain

EC 分析事例

トレジャーデータでは，過去に多くの EC分析に関する記事を紹介してきましたが、EC分析でWaveを体感してみましょう！

f:id:doryokujin:20160623134348j:plain

ECデータセットはこれまでと同じ物を使用します。100万人の会員テーブル，1000万件の購買履歴テーブル，1億件のアクセスログテーブル，これらローデータをそのまま Wave Analytics に置いておく事はできません。

売上分析，RFM分析，バスケット分析など，各々の分析軸で集計された集計済データを Wave Analytics にエクスポートしておきます。

1. 基本ダッシュボード

売上に関するダッシュボード，ユーザーのプロファイルの内訳を見るダッシュボードを以下の動画で紹介しています。

Wave Analytics EC ダッシュボード編 1 from Takahiro Inoue on Vimeo.

2. 応用ダッシュボード

RFM 分析 は，

  • R（Recency：直近購買日）=　いつ買ったか
  • F（Frequency：一定期間内の購買回数）=　どのくらいの頻度で
  • M（Monetary：一定期間内の購買金額）=　いくら使っているか

の３つの切り口から２つを選び、その２軸に基づいて顧客をグループに分け、そのグループ毎に目立った特徴を見ていく手法です。

f:id:doryokujin:20150521115117j:plain

↑ 「RF Matrix」：R（y軸）とF（x軸）のクロステーブルは、これらの値の組み合わせにおいて何人がそこに該当するかが、各々のセルの値となって一覧で見ることができるようになっています。

Wave Analytics では，この RF Matrix の一つのセルを選択することによって残りの "M" の内訳を見ることができます。Wave Analytics のインタラクティビティはこういったところで画面の遷移無く RFM の3次元を捉えることができます。以下のムービーをご覧下さい。

Wave Analytics EC ダッシュボード編２ from Takahiro Inoue on Vimeo.

いかがでしょうか？

Wave Analytics はこちらのブログでも機会を見て引き続き紹介していく予定ですのでお楽しみに！