Pairsでの活用例から学ぶre:dash導入のすゝめ

Published in

Eureka Engineering

11 min readNov 30, 2016

初めまして。Pairs事業部Analyzeチームで分析業務を担当している鈴木と申します。

みなさん、分析ツールは何を導入されてますか？ Pairs事業部では、社内のセルフBIツールとしてre:dashを導入しています。弊社のように、手軽な分析ツールとしてre:dashを導入している、もしくは導入を検討している企業やチームは多いのではないでしょうか。

今回は、実際にre:dashを運用してみて感じた「導入前にすべきこと」、Pairs事業部でのre:dash活用例を題材に「ダッシュボードの構成とDrillDownの工夫」をいくつか紹介します。導入を検討している方、またすでに導入している方の運用時の参考になればと考えています。

はじめに

本題の前に、re:dashについて簡単にまとめます。

re:dashの公式サイトに”Connect to any data source, easily visualize and share your data”とあるように、re:dashはあらゆるデータソースに接続し、簡単にデータをビジュアル化・共有できる分析ツールです。

接続できるデータソースの一例としては、MySQL・BigQuery・Redshift・HiveさらにGoogleSpreadSheetなど、非常に多岐に渡っています。また、社内の異なるデータソースをre:dash上で一元的に可視化できるのも魅力です。

詳細は、re:dashの公式サイトをご参照ください。demoページも用意されているので実際にre:dashをいじってみることも可能です。

導入前に決めておくべきこと

まず、re:dashの運用を通して導入前に考えたほうが良いと感じたことについて。

命名規則

Pairs事業部では、re:dashでクエリを検索した際にタイトルだけで「自分の必要としているデータ」かどうか判断できるように、タイトルの命名規則を設けています。

命名規則の運用前は、皆が思い思いの命名を行い、タイトルから分析内容の判断が難しいクエリが散見されました。タイトルは、クエリ検索時に非常に重要な要素であるため、事前に命名規則を決めてしまいましょう。

実際使用している命名規則

サービス名 + 国 + :(コロン) + データの内容 + (分類)

また、クエリの数が増えてくると、どのクエリが実際に信頼できるものなのか判断がつきにくい状況になります。都度、そのクエリが「データとして信頼できるか」詳しい人に確認していてはコミュニケーションコストが上がり、分析自体のハードルも上がってしまいます。

こうした事情から、分析担当者が「これは信用できるデータである」と判断したクエリには、タイトルの接頭辞に[公式]の文字を入れるようにしています。

実際の命名規則に従ったクエリ名

[公式]Pairs台湾: 新規獲得数/リテンション(日別/登録デバイス別/性別)

命名規則を設けないと、このような闇が生まれます。

クエリが乱立する前提で運用方法を考える

Pairs事業部ではre:dashを「手軽にクエリを実行できる場所」として、一部のプロダクトメンバーに開放しています。

使用ハードルをあまり上げたくなかったので特にクエリ作成の制限やルールを設けずに運用していたのですが、結果、約半年で新しいクエリが600個以上増えていました（驚愕）。

それ自体は活発に分析が行われている証拠なので良いことだと思っています。

ただし、運用ルールを設けず放置するとクエリが乱立し、一瞬で（本当に一瞬です）無法地帯になるため、不要なクエリの乱立を防ぐ最低限の運用ルールは予め決めておいたほうが良いでしょう。

現在Pairs事業部では、クエリ乱立防止のために下記2点を主に実践しています。

・分析担当者が承認したメンバーしかクエリの保存をできないようする。

・長期間使用されていないクエリを定期的に棚卸し＆アーカイブ。

定期的なクエリの棚卸しについてですが、長期間実行されていないクエリを抽出するPostgreクエリを定期的にre:dash上で実行し、不要だと判断したクエリに関してはどんどんアーカイブするようにしています。

また命名規則の部分で紹介していませんでしたが、予め後で削除予定とわかっているクエリに関してはタイトルに[TMP]を入れ、使用しなくなったタイミングでアーカイブするようにしています。

▼長期間実行されていないクエリを抽出する

SELECT
q.id
,　q.name
, MAX(e.created_at) AS executed_at
, u.name AS user_name
, 'https://hoge_fuga/queries/' || q.id || '/source' AS url
FROM queries AS q
INNER JOIN users AS u
ON u.id = q.user_id
INNER JOIN events AS e
ON CAST(e.object_id as integer) = q.id
WHERE q.updated_at <= '2016-09-01'
AND q.name NOT LIKE '%[公式]%' -- 公式クエリではない
AND q.is_archived = false -- アーカイブされていない
AND q.schedule IS NULL -- 定期実行が設定されていない
AND u.id NOT IN (※admin権限ユーザのid) -- admin権限者のクエリは除外
AND e.object_type = 'query' AND e.action IN ('view', 'view_source', 'execute')
GROUP BY q.id, q.name, u.name, url
HAVING MAX(e.created_at) <= '2016-09-01' ORDER BY executed_at DESC
;

グラフの配色

グラフを作成する際に、使用する分類ごとのカラーを事前に決めてしまうことをオススメします。例えば、性別なら男性=青/女性=赤。デバイス別ならiOS=青/Android=緑/SP=赤/PC=オレンジといった具合にそれぞれ使用する色を固定します。

目的は、分類ごとに色を統一し、グラフ上の分類をすぐに把握できるようにすることです。また、色を統一せず、ランダムなカラーでグラフを作成しダッシュボードに組み込むと、全体的に規則性のない配色になってしまい混乱を招きます（そして色が統一されていたほうがかっこいい！笑）。

後で統一する作業を行うと、とんでもない労力を消費することになるので（体験談）、事前に決めてしまった方が後々楽になります。

以上がPairs事業部でのre:dash運用を通して感じた、導入前に決めておくべきことになります。

Pairs事業部でのダッシュボード導入事例

続いて、Pairs事業部でのre:dash活用事例として、現在分析に活用しているダッシュボードの構成とDrillDownのために行っている工夫を2つご紹介します。

ダッシュボードの構成はDrillDownを意識

Pairs事業部では、「定常的に監視すべきサービスの基礎となる数字（クエリ）」を予め定義し、国（日本/台湾）ごとに「売上関連」と「サービス（サービス上の特定の機能に関する数字やDAU/MAU等）」で分類。ダッシュボード上にまとめてすぐにアクセスできるようにしています。

▼ダッシュボードの分類

日本
売り上げ関連
Daily売上
課金UU数
有料会員メニュー購入UU/売上 etc…
サービス
DAU/MAU
各アクション数/UU数
定着数/率 etc…
台湾
基本的に日本と同じ構成

ダッシュボード内の構成はデータのDrillDownを意識した情報配置にしています。

定常的なサービス上の数値監視を行う際、すぐに特定の数値を確認するケースは少ないと考えています。仮に「売上が下がっている原因を特定したい」などの具体的な目的を持ってデータの分析を始める際にも、まず確認するのは細かい数字ではなく、基礎となる大まかな数字ではないでしょうか。

こうした理由から、ダッシュボードの構成は大きい数字から順を追って細かい数値まで深掘りできるようにしています。

DrillDownを助ける工夫：ダッシュボード内にはフッターを設置

他のダッシュボードにスムーズに移動できるように、ダッシュボード内には同じ分類のダッシュボードのURLを記載したフッターを設置しています。

このフッターですが、SELECT文にただダッシュボードのリンクを記載しただけのクエリを作成し、ダッシュボードに表示する方法で運用をしています。この構成はメンテナンス性がとても高く、フッターの内容を変更したいときにはクエリを修正すれば使用しているダッシュボードの全フッターが更新されるため重宝しています。

▼フッター作成サンプルSQL

SELECT
'ダッシュボード１' AS Label
, 'https://hoge_fuga/dashboard/dashboard-1' AS URL
UNION SELECT
'ダッシュボード2'
, 'https://hoge_fuga/dashboard/dashboard-2'
UNION SELECT
'ダッシュボード3'
, 'https://hoge_fuga/dashboard/dashboard-3'
UNION SELECT
'ダッシュボード4'
, 'https://hoge_fuga/dashboard/dashboard-4'
UNION SELECT
'ダッシュボード5'
, 'https://hoge_fuga/dashboard/dashboard-5'
UNION SELECT
'ダッシュボード6'
, 'https://hoge_fuga/dashboard/dashboard-6'
ORDER BY url ASC
;