Looker Blocksを使ってFirebaseのデータを5分で可視化してみた

行き着く先はUNNEST
2020.07.15

奈良県でリモートワーク中の玉井です。

今回は、何かとややこしい構造をしている(BigQueryにエクスポートした)Firebaseデータを、Lookerで楽に可視化します。

Firebase(のデータ)を分析するのは大変?

昨今、スマホアプリ等のデータを分析してマーケティング等に役立てる…ということは当たり前になってきています。そして、そこに出てくるものとして、メジャーなサービスの一つがFirebaseでしょう。Firebaseを使って開発しているスマホアプリやWebアプリは多いと思います。

FirebaseのデータはGoogle BigQueryにエクスポートし、SQLを使って分析をがんばっている方はたくさんいるかと思います。…が、BigQueryにエクスポートしたFirebaseデータの構造は結構クセがあり、正直扱いづらいですよね(日単位でテーブルが生成される、めっちゃ入れ子になっている等)。

そこでLookerです。実は、Firebase用のBlocksが用意されています。Firebaseのややこしいデータをキレイに構造化してくれるLookMLが既に定義されているため、これを利用すると、すごい簡単にFirebaseのデータを可視化(及び分析)することができます。

というわけで、実際にやってみたいと思います。

やってみる前の準備や環境などについて

使用データ

Firebaseは「モバイル・Webアプリケーション開発プラットフォーム」…データを用意するにしても、何かアプリを開発しないとダメなのでは…そんなふうに考えていた時期が俺にもありました。

Google様をなめてはいけません。簡単にBigQuery上に用意できるFirebaseのサンプルデータがあります!

上記のリンクからポチポチするだけで、すぐにサンプルデータをBigQuery上に用意することができました。

確かにこれは(分析するには)ちょっと厄介な構造ですね。

事前準備

LookerにBigQueryをConnectionとして登録しておく

下記を参考に準備しておきます。

API

Looker APIも使うので、使用できるようにしておきます。

その他操作環境

  • Looker 7.10.19
  • firebase_block_v3

やってみた

Projectを新規作成する

Starting PointでClone Public Git Repositoryを選ぶのがポイントです。これを選ぶと、既にLookMLが展開されているリポジトリをインポートしてProjectを作ることができるのですが、今回は冒頭に記載したFirebaseのBlocks(のリポジトリ)を指定してインポートします。

LookMLをちょっとだけ修正する

Blocksですので、もうほとんどLookMLが完成しています。ただし、初期のままだと動かない部分があるので、自分の環境に合わせて修正する必要があります。

ModelファイルのConnectionの部分

firebase.modelの1行目は下記のようになっています。Connectionの名前を修正しましょう。

connection: "firebase-sample"

Modelファイルのincludeのコメントアウト部分

firebase.modelのincludeの一部は下記のようにコメントアウトされています。

# include: "my_dashboard.dashboard.lookml"

このままでは、既に用意されているダッシュボードが見れないので、下記のように修正します。「ダッシュボードは自分でゼロから作る」という場合は、この作業は不要です。

include: "firebase.dashboard"

付属のNotebookを使ってイベントとユーザープロパティのViewを生成する

何のスマホアプリだろうがWebアプリだろうが、Firebaseを使っている以上、データの構造は同じです(だからBlocksを構築して配布することができる)。

しかし、イベントの種類やユーザープロパティは、そのアプリケーション毎に異なるはずです。それらも合わせて分析したい場合、これら独自のデータもLookMLに定義する必要があります。

これらは手動で書く必要があるのか…と思うところですが、そんなことはありません。Blocksには、ipynbファイル…要するにPythonコードも入っており、こちらを実行するだけで、ユーザープロパティ等を定義したViewファイルを生成することができます。

実行場所はどこでもいいのですが、私はGoogle Colabを使いました。下記は実際に実行した結果です。ちなみに、実行する過程でLooker APIのクライアントID等を入力する必要があるので、準備しておきましょう(下記画像にうつっているID等はサンプルのものです)。

見ればわかるように、Viewファイル自体が出力されるので、それを同Viewに貼り付ければOKです(events_generated.viewuser_properties_generated.view)。今回はサンプルデータなので新しいdimension等は一切でてきませんでしたが…。

ダッシュボードを見てみる

ダッシュボードを見るまでの作業はここで終了ですので、ダッシュボードを見てみましょう。

いい感じに可視化できていますね!

タイルの中をちょっと見てみる

右下のプラットフォーム別リテンションというグラフをExploreで見てみます。

Lookerが生成しているクエリはこちら。とても手で書こうとは思いません。

Blocksの構造について

どういうLookMLでこれらのクエリが生成されているのか…。コード自体は冒頭のGithubページから見ることができます(UNNESTが駆使されていることがわかります)。

ここでは、全体の構造だけちょこっと見ておきます。

まず、Project全体は下記の通り。実はファイルはそんなに多くありません。

付属のPythonコードから生成するView

まず、2つのViewがあります。

  • events_generated.view
  • user_properties_generated.view

これは、先程のPythonコードで生成するViewファイルです。独自のイベントやユーザープロパティを定義するViewですね。

event.view

そして、これをextendsしているevents.viewがあります。上記のユーザープロパティ等を継承しつつ、Firebase共通のデータについて一通り定義してあります。コメントやgroup_labelで項目がグルーピングされていたり、descriptionがしっかり書かれていたり、何かとわかりやすくしてくれてあります。

session.view

セッションの定義や計算が行われているViewです。

永続派生テーブルが使用されています。この中のクエリについては、下記が参考にされているようです。

firebase.model

定義されているExploreは1つだけ。ベースはevent.viewとなっており、それに対して、項目をUNNESTでバラしたものをいくつかJOINしている形になります。最後にsession.viewもJOINされています。

基本的に、このExploreで大体の分析はできるかと思いました。

おわりに

Firebaseの分析に四苦八苦されている方は、ぜひLookerとこのBlocksを試していただきたいですね。