「データに秘められた可能性」を最大限に引き出す，そのために Wave Analytics が求めたのは究極の「インタラクティビティ」①
はじめに
様々な BIツール，可視化ツールがひしめく近年において，2014年10月に Salesforce が満を持して「Wave」を基盤とするアナリティクスプラットフォームをローンチしました。その中の可視化ツール：Wave Analytics は可視化ツールとしては後発組ですが，まさにその名の通りこの世界に「Big Wave」を巻き起こす牽引役として台頭していく事は明らかです。
Wave Analytics とは？
Wave Analytics のインパクトはダッシュボードを見れば明らかですが，以下のような SFDC ならではのメリットを提供してくれます。
Salesforce とのネイティブな統合
Salesforce とシームレスに連携するクラウドサービスを通じて，あらゆるソースのデータをすべて安全に提供します。 導入後はすぐに稼働でき，管理も容易です。
また，Wave Analytics は Salesforce 上のオブジェクトを参照することはもちろん，Informatica Rev や SkyOnDemand といったデータ連携サービスとも容易に連携が可能です。
Treasure Data Service と Wave Analytics の関係
Wave Analytics は自身のクラウドストレージ上に可視化のための集計済データを保持する事はできますが，大量の生データを保持する事はできません。Treasure Data Service は Wave Analytics の表現する全てのデータのオリジナルを保持するためのバックエンドの役割を担います。
そして（現在検証中のフェーズですが），前述の Informatica Rev や SkyOnDemand を通じてTreasure Data Service と Wave Analytics がお互いの役割を最大限発揮する形で接続されます。
↑ SkyOnDemand では，Web UI から作成するデータフローによって前処理や他の外部データと結合処理を挟みながら，Wave Analytics に必要なデータセットが送られます。
↑ Infomatics REV 上では，Treasure Data Serviceから読み込んだデータをテーブルとして編集・集計といった処理を挟むことができ，エクスポートボタン一発で Wave Analytics に送信可能です。
クラウドの導入
Wave Analytics は自身のクラウド上に可視化のためのデータセットを保持する事が可能です。そこにデータセットが準備されれば，Wave Analytics 上のダッシュボードは非常に軽快に動きます。
デモ：チャート作成編
Wave Analytics のインパクトを伝えるのには，静止画だけではとても及びません。まずはダッシュボードを作成する人が，いかに簡単に，いかに楽しく，いかに気持ちよく作業を進める事ができるか，以下の動画をご覧下さい。
Wave Analytics EC チャート作成編 from Takahiro Inoue on Vimeo.
次回は，EC 業界向けに作成されたダッシュボードを紹介していきます。
お楽しみに！
アクセスログ分析最前線：Treasure Data JavaScript SDK で始めるパス分析 その３
はじめに
トレジャーデータが提供する Treasure Data JavaScript SDK は，他のアクセスログ収集ツールと同様に，HTML 内にタグを埋め込む事でアクセスに関する情報を収集することが可能です。
本記事のイントロダクションはその１をご参照下さい。
分析フロー
今回は 分析フローでいうところの7と8のNYSOL, Graphviz パッケージを紹介し，9の可視化までに必要なコマンド群を解説します。
フローの1から6は以下をご覧ください。
7. NYSOLパッケージをインストール
NYSOL
NYSOL は，UNIX（Mac）環境で動作するデータ分析コマンドラインツールです。NYSOL は分析のテーマごとに「松」や「竹」など，パッケージが分かれていますが，そのどれもがもれなく非常に有用なパッケージです。今回は NYSOL 内の「眺（view）」パッケージのコマンドを使用しますが，機会があれば他のパッケージでの分析事例も紹介したいと思っています。
眺（view）パッケージ
VIEW: mgv.rb Graphviz用グラフデータ(.dot)の作成
view パッケージの中に，「mgv」という，csv ファイルを Graphviz 用（後述）のための dot ファイルに変換するコマンドがあります。
この 1 行の mgb コマンドを実行することで，簡単に csv → dot ファイル変換ができます。
遷移ダイアグラム
遷移回数は，前回のコンバージョンパステーブルを用いなくても Raw Data テーブルより生成が可能な指標で，比較的簡単にダイアグラムを作ることができます。
遷移回数を求めるクエリ：
このクエリの中の「ORDER BY cnt DESC LIMIT 50」 の部分は重要で，遷移回数上位50件のみを取得しています。遷移回数やコンバージョン回数・率でダイアグラムを用いる際には，ソート順に上位 50〜100 レコードの csv ファイルを用います。試してみれば明白ですが，これ以上のレコード数に対してダイアグラムを作成すると，とても複雑なダイアグラムができあがってしまいます。
このクエリによって取得したファイルを transition.csv とすると，以下の mgv コマンドで dot ファイルに変換します：
↑ transition.csv の内容，これが dot ファイルに変換されたものが以下になります（一部省略しています）。
8. Graphvizをインストール
Graphviz
Graphviz は dot 言語をインプットとして，ダイアグラムを生成する可視化ツールです。NYSOL と同様に UNIX（Mac）環境でインストール可能なコマンドラインツールです。
9. ダイアグラム作成
遷移ダイアグラム（続）
先ほど生成した遷移回数の dot ファイルと Graphviz に読み込みましょう。
このコマンドによってついに遷移ダイアグラムが生成されました。
さて，この遷移ダイアグラムですがいくつかの工夫の余地があります：
- td_title （ノードラベル）が長いノードは横に広い楕円になってしまう
- 全体的に横長のダイアグラムになりやすい
1. については，dot 言語内で各ノードラベルの適切な箇所に改行文字： \n を挿入することで，ダイアグラムの中でもノードラベルが改行され，見やすくなります。
2. については rankdir=LR; というレコードを挿入することで，グラフを矢印の向きを横向きから縦向きに変換します。
実際に上2つの工夫を施した dot ファイル（さらに ）を用いて再度ダイアグラムを生成してみます。
コンバージョンダイアグラム（遷移回数）
前回でこのダイアグラムのためのクエリを紹介しましたが，遷移回数上位50件を抽出する形のクエリを再掲載します：
ここでコンバージョンノードの形を菱形に，色を赤色に変えて目立つようにします。また，適切に改行しました。
コンバージョン率ダイアグラム
こちらの方はコンバージョン率上位50件の遷移を取得します。
こちらの方は dot ファイルを改良することでだいぶ視認性の良いものになりましたね。
以上、Treasure Data JavaScript SDKで始めるパス分析シリーズでした。
アクセスログ分析最前線：Treasure Data JavaScript SDK で始めるパス分析 その２
はじめに
トレジャーデータが提供する Treasure Data JavaScript SDK は，他のアクセスログ収集ツールと同様に，HTML 内にタグを埋め込む事でアクセスに関する情報を収集することができます。
前回はまず先にパス分析のアウトプットが何なのかを明示するため，いくつかのダイアグラムを紹介しました。
今回からはそのダイアグラムを得るための手順を紹介していきます。
分析フロー
実際にアクセスログからパス分析を経てダイアグラムを得るためには，上図のフローをとります。今回はトレジャーデータ内での処理（2.〜6.）をクエリを交えて説明します。次回では NYSOL, Graphviz パッケージを紹介し，可視化までに必要なコマンド群を解説します。
パス分析を行うための必要条件
本記事においては基本的にはTreasure Data Serviceのユーザーであること，つまり
- Treasure Data Javascript SDK でログが収集されている
- Treasure Data Serviceを利用できる（Presto/Hive クエリが実行できる，中間テーブルが作成できるなど）
を前提としています。もう少し前提を緩めたとすると，本質的な必要条件は以下になります：
- アクセスログが収集できている
- データベースに自由にアクセスできる（= データの読み書き，中間テーブルの生成など）
- SQL が実行できる（= TDクエリテンプレートが適用できる）
- 強力な分散処理エンジンを持っている（= Presto / Hive などの SQL エンジンが利用できる）
1. のアクセスログの収集に関しては他のツールでも可能でありますが，2.〜4. を満たすためには，そのアクセスログを csv ファイルにダンプして，Treasure Data Serviceに（カラム名をTreasure Data SDK に準拠するように変更して）インポートし直すのが現実的です。
また，外部アクセスログデータのダンプ→インポートはそれなりのハードルがありますので，新しく Treasure Data Javascript SDK をサイトに埋め込んで並行運用しながら試してもらう事をお薦めします。
※Treasure Data Serviceの利用検討や，パス分析を試してみたい方は お問い合わせ からご連絡下さい！
では、やってみましょう。
1. Raw Data（アクセスログ）テーブル
Javascript SDK によって収集されるテーブルは，あらかじめ項目名が定まっています。td_title（ページタイトル），td_url（URL）, td_client_id（uuid）など，メジャーな項目は全ておさえてあります。このテーブルを Raw Data テーブルと呼ぶことにします。そしてパス分析は，この Raw Data テーブルさえあればできてしまいます。
2. Conversion Master テーブル
規定テーブル名：master_conversion
コンバージョンマスタ テーブルは，Raw Data テーブルの中の td_title（ページタイトル）の中で，サイト内のコンバージョンと見なせるページの値をリストアップした，非常にシンプルなものです。以下に例を挙げます：
トレジャーデータのサイトのコンバージョンを「資料ダウンロード」および「お問い合わせ」とします。このページに到達したユーザーをコンバージョンしたユーザーとします。ここに記述する td_title 値は，後で Raw Data テーブルと文字列マッチングをしますので，Raw Data 内に存在する値を入れて下さい。また，time カラムは使いませんので自動で付与される時間で問題ありません。
3. Conversion History テーブル
規定テーブル名：itmd_conversion_history ※ itmd_ は 中間（intermediate）テーブルの意味
ここからは，1. Raw Data テーブルと，2. Conversion Master テーブルを使って中間テーブルを作っていきます。Conversion History テーブルは，コンバージョンしたユーザーの td_client_id と，コンバージョンした時間: time を保存しただけのものです。また，一人のユーザーが複数回コンバージョンする可能性もあるので，cv_id にて何回目のコンバージョンかを記録しておきます。
4. Conversion Path テーブル
規定テーブル名：itmd_conversion_path
このコンバージョンパステーブルこそが，あらゆるパス分析のインプットソースとなる貴重ななテーブルとなります。1. Raw Data テーブルと 3. Conversion History テーブルを用いて作成します。巨大な JOIN を伴う処理となりますので，Presto でメモリ不足によりうまくいかない場合は Hive の方で実行して下さい。
↑ 今回作成したコンバージョンパステーブルです。ここで重要なポイントは，コンバージョンパステーブルは Raw Data テーブルを「集計」したテーブルではなく，
- ユーザーごとに「グルーピング」，
- 時系列に「ソート」，
- コンバージョンしたユーザーのみの「抽出」，
- コンバージョンポイントに達した時点で「切り出し」
を行った「部分」テーブルであることです。そしてこのコンバージョンパステーブルは，今回紹介するダイアグラムの作成以外にも様々な使い道があります。そこも追ってご説明していく予定です。
↑ 今回は td_title をノードのラベルと限定していましたが，上図のように page_id (URL) やカテゴリといった任意のカラムをノードラベルとして据えることができます。ただし，URL をノードラベルに採用する場合は，パラメータの消去などしっかりと正規化しておかないと大変なことになります。
5. Non Conversion Path テーブル
規定テーブル名：itmd_non_conversion_path
コンバージョンしなかったユーザーに関しても，同様の概念でテーブルを作成しておきます。
コンバージョンしなかったユーザーは cv_id は意味を持ちませんので省略しています。ユーザーごとに見て node_id が 最大のレコードを見れば，そのユーザーが最後に見た離脱ページとなっています。
基本的にコンバージョンしないユーザーの方が10倍以上多いものですから，このテーブルもまた思いな集計処理が行われることに注意してください。そして，
Raw Data Table = Converion Path Table + Non Conversion Path Table
となっていることも明らかですね。
6. ダイアグラム作成用クエリ
Conversion Path テーブルに対して，ダイアグラム作成用のクエリを適用します。
↑この出力をcsvファイルとしてエクスポートしておきます。この度紹介するダイアグラムでは 6 列目以降は用いません。
- コンバージョンダイアグラム（遷移回数）→ 3 列目の値
- コンバージョン率ダイアグラム → 5列目の値
を活用していきます。
その３に続く・・・・・
