まずはLookerの紹介

日本法人立ち上げが2018年9月と日本ではまだ馴染みが少ないかなというBIツールです。

後述しますが非常な強力なBIツールのため、海外のスタートアップでの利用が広がっているなど、日本でも認知され活用されていくと考えています。

去年抱えていた弊社の課題

1.TreasureDataを利用しているが、分析しにくいテーブル構造

依然としてTreasureDataを利用しています。
LookerではPrimaryKeyを利用することで不要なgroup byなどを行わずに済みクエリの最適化を行うことができます。
ところがTreasureDataを利用されてる方はご存知かと思いますが、主キーは存在せずレコードの時間(timeカラム)を絞り込むことによってクエリのパフォーマンスを上げるような仕組みになっています。
ですのでLookerで運用するためにPrimaryKeyをよしなに定義、妥協が必要になりました。

  dimension: primary_key {
    primary_key: yes
    hidden: yes
    sql: CONCAT(cast(user_id AS varchar),cast(time AS varchar),cast(id AS varchar)) ;;
  }

上記などで複数のカラム(user_id、time、id)を組み合わせ一意となるキーを各テーブルで作成したり、PrimaryKeyをうまく定義できないテーブルは集計のブレを妥協するなどしました。

2.集計はスプレッドシート運用

こちらは徐々にLookerで数字を見るようにしていきました。
最近だと施策後のリテンションレポートなどはLookerを使って数字を出したりしています。

3.分析基盤もベースはスプレッドシート運用

こちらのスプレッドシート運用はあまり変わりがない状態です。

4.Kibana/Redashも利用はあるが、一部プロダクトで頑張って用意して放置

Redashに関しては触れることがありませんでした。
Kibanaで確認していた数字は全てLookerで置き換えを行いました。

5.クエリを叩けるのがエンジニアだけで、エンジニアに毎回依頼が来る

ディレクター陣がLookerを若干使うようになり、これってどうやったら出せますか？の依頼が来るに変わりました。
ちゃんと使っててエライ！！

6.クエリを叩けるのがエンジニア以外いないので、KPIを追うための数値を用意するまでにリソースが必要

KPIを追うまでの数字を用意する時間はあまりかわらないかもしれません。
ただ「こんなパラメータもあるんだ」の発見はあったようで、
・この施策ではこういった数字をこれとこれを組み合わせれば出せませんか？
・こういったパラメータをこのイベントで追加すれば効果測定しやすいですか？
などの適切なKPIを考えるための素材としてLookerが役に立ったのではないかと思います。

7.クエリと叩く人が属人化するため、数値の根拠がその人に依存した数値となる

基本的に誰が叩いても同じ数字がでるので数値の属人化はしません。
ただLookerを使えば使うほど、DerivedTable(派生テーブル)や一部集計だけで使うdimensionやmeasureといった項目が増えてしまうという難点があります。
適切にコメントを残し、常に使わない項目に関してはhiddenにして表示しないなどの細やかな運用が必要だなと感じています。

まとめ

去年に比べると牛歩ながらもBIツールの定着化は進んでいるのではないかと思います。
現在はマーケティングツールとしてのLooker活用を考えており着手中です。
スプレッドシートに取って代わるツールではなく、興味を持った数字を探索できるような環境を整えて行きたいです！

BIツールが定着していない会社でLookerを導入して1年後の世界