Looker Studioの魅力と便利な使い方を紹介します

初めて使ったBIツールはLooker Studioのid:syou6162です。これまでTableau / Looker(≠ Looker Studio) / Metabase / Redash / Connected Sheetsなど色々なBIツールを触ってきましたが、不満は色々ありつつも個人的に一番しっくりきて愛着があるのはLooker Studioです。このエントリでは、その魅力と便利な使い方や注意点について書きます。例によって、社内勉強会向けの内容を外向けに公開しているため、内容の網羅性などは特に担保していないことにご注意ください。

Looker Studioの魅力

利用のハードルが限りなく低い & Google Workspaceとの連携が便利

Looker Studioの一番の魅力は「Google Workspaceを利用していれば無料で使えること」が一番大きいと思います。LookerやTableauは便利だったり高度な機能が使えますが、ユーザー単位の課金体系になっており、組織に所属する全員にアカウントを配布ことが難しい場合があります。

また、Google Workspaceが前提になっているため、Google Workspaceでアカウントを持っている人であれば共有が簡単なこと、Google Groupでの共有なども自然とできることから全社のガバナンス体系と合わせやすい、といったメリットもあります。

複雑過ぎることができないので、諦めが付けやすい

「これは魅力なのか?」という気もしますが、案外メリットになり得るものかなと思います。Looker StudioはTableauと比べると可視化が充実しているとは言い難く、APIのサポートもかなり薄いです。

そのため、複雑過ぎることはできないことが多いですが、それによってかえって諦めが付くことも多いです。例えば、スプレッドシートはGASによって色々足りない箇所を改造していくことができますが、できるがゆえに魔境になってしまったスプレッドシートを自分は数多く見てきました...。魔境になって誰もメンテナンスできなくなるくらいなら、 多少できないことがあってもメンテナンスできるダッシュボードのほうが数倍マシだと思っているので、複雑なことができないのはよい点でもあるかなと思っています。

諦めが付けにくいガバナンス観点は悩ましい点でしたが、最近ではこの辺はLooker Studio Proの登場などもありサポートがされてきているので、良いバランスのBIになってきていると思います。

ちゃんとBIツールになっている

「無料で使えてGoogle Workspaceとの連携が便利」となると、対抗馬はConnected Sheets(スプレッドシート)でしょう。Connected Sheetsはおそらく最もハードルが低いBI系のツールですが、メンテナンスするには一番辛いツールでもあります。何が一番辛いのかを考えると、個人的にはデータの加工と可視化が一緒にされているところが辛いポイントかなと思います。どこを触ると何が壊れるかの把握が非常に難しいため、触るのも億劫になってしまうことが多いです*1。「データの取得」「データの加工」「データの可視化」などのステップを意識できる人が作ったスプレッドシートはまだ何とかなりますが、スプレッドシートの作り自体がそれを意識 / サポートさせる形にはなっていないため、辛くなりがちです。

こういった文脈でLooker StudioはConnected Sheetsよりは大分BIツールになっています。データの加工が行われるにしても「カスタムクエリ」「calculated fields」などいくつかポイントがあるため、Connected Sheetsよりは魔境が生まれにくい構造にはなっており*2、ちゃんとしたBIツールであるというのはメリットの一つだと思います。

Looker Studioの便利な使い方

多様なデータソースと簡単に接続できる

Looker Studioは多様なデータソースと簡単に接続して可視化できるのが便利です。接続先への権限があれば、数クリックでLooker Studioで可視化できます。特にSearch ConsoleやGoogle Adsとの接続が便利に使われることが多いようです。意外とGCSもサポートされています。スプレッドシートに接続することももちろんできるので「生データは広く見せたくないが、集計結果だけは社内で広く見せたい」といったケースにもLooker Studioは向いています(例: 組織のエンゲージメントサーベイ)。

• GA4×サチコ×Looker Studioで可視化！ 現場で使われる“ダッシュボード”の作り方 | 【レポート】Web担当者Forumミーティング 2023 秋 | Web担当者Forum
• Looker Studio × Search Console ダッシュボード徹底解説｜GAラボ
• 組織の分散しているデータをBigQueryにまとめてLooker Studioで可視化する方法

可視化や集計がある程度複雑化してきた場合、これらのデータソースをBigQuery Data Transfer ServiceなどでBigQueryに取り込んだ上でSQLで集計をかけるのが常套手段です。しかし「データエンジニアのリソースが足りないけど、ひとまず大雑把にダッシュボードで可視化したい!」という場合には、多様なデータソースと簡単に接続できるというこのメリットは大きいと思います。

また、Looker Studio上でJOINも可能なため、複数のデータソースと突き合わせて見たい、といった場合も可能です(Looker Studio上のJOINは重かったり、バグの温床になりがちではあるので、推奨はしません)。

基礎的な可視化ができる

Tableauと比べると可視化が充実しているとは言い難いLooker Studioですが、それでも基本的な可視化の能力は備わっています。個人的には複雑な可視化方法は初見の人にとっては理解が難しかったり説明が必要なことが多いので、Looker Studioくらいの可視化方法がちょうどいいと感じることも多いです。Looker Studioで可視化をする際、私は以下の方法をよく使います。

• 時系列推移(棒グラフ)
  • 週単位や月単位などはLooker Studio上で切り替えられるので、必要な単位で可視化します
    • 
  • 時系列の変化だけでなく「プロジェクト毎」「人毎」「部門毎」など見たい軸があると思うので、積み上げ棒グラフの形で表現します
  • 見たい軸を「内訳ディメンション」に設定します
  • 積み上げは最大でも20個までしか表示できないので、注意が必要です(累計が全体と一致するとは限らない)
    • 2024/06にアップデートがあり、この制限はなくなりました
    • 「その他」にグルーピングすることができるので、基本的に「その他」へのグルーピングを設定しておくのがよいでしょう
  • データがどれくらいバラ付くかをグラフで表現したい場合、グラフに区間を設定するのがオススメです
    • 予測をしたい場合は信頼区間、過去のデータについては標準偏差を表示して、どれくらいの不確実性があるものなのか分かるようになっていると安心して議論できますね
    • ビジネスユーザーには統計的検定をきちんと理解してもらうのは難しいことが多く、信頼区間や標準偏差などを可視化して議論するほうがやりやすいことも多いなと個人的には思います
• 円グラフ
  • 円グラフ自体は好きではないのですが、全体に占める割合を見たい場合に使うことが多いです
  • 
• スコアカード
  • 「傾向などではなく、全体でとにかくいくつ」などが知りたいコスト系などではよく使います
  • 
• 表
  • これも結構使います
  • ほぼ生データを見せるようのビューとして使うことが多く、フィルタしながら使う想定でいます
  • 
  • 「列のサイズを変更」から「データに合わせる」でいい感じの幅になることが多いので、よく使っています
    • 
• クロス表(ピボットテーブル)
  • 軸を2つ持ってきて、その2軸の間である統計量を見たいというようなケースでよく使われます
  • 例: 時間帯(例: AM9時)と曜日を軸に取って、CVRの傾向の違いを見てみたい場合
  • 
• 散布図
  • 2つの変数の相関を見たい場合に使います
  • データ分析では頻出ですが、ダッシュボードではそれほど使いたい場面は多くないかもしれません
  • 後述するLooker Studio Explorerでよりアドホックな分析を行いたい場合は使う場面が多いかもしれません
  • 
• 箱ヒゲ図
  • 少しadvancedな可視化方法になりますが、データのバラ付き度合いを見たい場合にはよく使われる可視化方法です
  • しかし、Looker Studioで使う場合には25パーセンタイル値などをcalculated fieldsで自分で作らないといけないため、正直ちょっとまだイケてない感はあるなと思います
  • 
• タイムライングラフ
  • 数値の増減を見る際に「この指標が上がってるのってなぜだっけ」は知りたいことが多いと思います
  • プロダクト側のリリースやマーケティング側のクーポン配布など色々な文脈があると思いますが、この辺の定性的な情報を知るにはドメイン知識が必要なことが多いです
  • タイムライングラフはそういった「いつからいつまで何が起こった」といった情報を時系列で表示することができます
  • 参考: Looker Studioで新しいグラフ『タイムライン』が利用できるようになりました。 | DevelopersIO
  • 

---

人間は数値だけ見ても「この数値がいいのかどうか分からない」「この数値からアクションが必要か分からない」ということが多いと思います。そういった場合は基準となる数値や帯域がどういったものかをグラフ上に出してあげるとよいでしょう。Looker Studioだと基準線や基準帯域がそれに対応しています。

定期的にダッシュボードを通知する

Looker Studioのダッシュボードを定期的に通知させるのは、Email経由が便利です。隔週のようなスケジュール設定をしたり、複数の宛先の設定をしたり、件名とメッセージのカスタマイズすることができます。

以前はLooker StudioのダッシュボードをSlackに通知するのはGASを使う方法がよく使われていました。しかし、最近ではSlackのチャンネルに対応したメールアドレスを簡単に作ることができるようになっており、Looker Studioのダッシュボードの通知先のEmailにこのSlackのメールアドレスを設定しておくと簡単にSlackへの通知が可能です。

通知する見た目の設定や送信時のテンプレートの高度なカスタイズはできませんが、この簡単さはLooker Studioのいいところだと思います*3。

データソースをLooker Studio内で統合(JOIN)する

Looker Studio内でデータソースを統合(JOIN)することができます。例えば、BigQuery上にあるテーブルとスプレッドシート上にあるデータを突き合わせて可視化する、などです。基本的にはBigQueryのようなデータウェアハウス上に集めてからJOINするのがオススメですが、Search ConsoleやGoogle Adsなどまだデータがデータウェアハウスにきていないけどダッシュボードで一緒に可視化したい...!という場合に取れる手段の一つです。

基本的にはJOINの対象になるデータソースを選択し、JOINのキーとなるディメンション(結合キー)を選択する流れになります。ただし、Looker Studio上でJOINする場合は注意が必要です。結合キーがうまく設定できていなくてJOINがうまくいかなかったり、うまくいったように見えてキーの設定が甘くレコードが重複してしまったり*4、動作が重くて試行錯誤もしにくい、といったことが起きやすいです。

簡単に見えて罠が多いため、Looker Studio上で複雑な操作を行うくらいならデータエンジニアに相談するのが良いでしょう*5。

Looker Studio上のJOINは、要約して簡潔になったデータ同士をJOINするケースに適しています。例えば、以下のようなケースです。

• 売上の予算と実績をLooker Studioで可視化したい場合
  • 要約された実績値なので、それぞれ高々数百〜数千行程度のデータ量
• 売上の実績値はデータエンジニアがBigQuery上に集計したものが存在する
• 売上の予算はアドホックに手入力で管理されており、スプレッドシート上に存在する
• 両方合わせて可視化したいが、売上の予算は手動で管理するため、BigQuery上に乗せにくい
  • 例: 予算の運用はスプレッドシートを頻繁にいじって構造が変わる関係で、いじる度にエンジニアにBigQueryの設定変更の依頼をするのは面倒
  • 例: 権限上、BigQueryに乗せたくない

こういった要約されて小さくなった & BigQueryで固く作るよりはもうちょっとアドホックにデータを見たい、という場合はLooker StudioでJOINをやるのが向いている状況かもしれません。以下のページに詳しいやり方が書かれているので、そちらを参照してください。

レポートの中のデータをダウンロード

他人が作ったLooker Studioのレポートを見ていて「この可視化の結果と自分が持ってるデータ(例: 独自のカテゴリの分類)を突き合せて分析したいな」ということがたまにあると思います。レポートのオーナーにデータを出してもらうように依頼することもできますが、自分でエクスポートして分析に持ち込むことも可能です。やり方は簡単で、レポート内のグラフの右上に出る「その他」のボタンをクリックして「エクスポート」を押すと形式を選ぶダイアログが出てきます(詳細 / 解説)。CSVなりスプレッドシートなり、好きな形式でエクスポートして、煮るなり焼くなりできます。

---

---

これは便利な一方でレポートのオーナーからすると「いや、ちょっと待って。この結果をダウンロードしてあまりに自由な形で使って欲しくないんだ...!」という場合もあると思います。ディフォルトではダウンロードできるようになっていますが、禁止する設定も可能なので場合によって設定するといいでしょう。

フィルタとコントロールをうまく活用する

フィルタやコントロールは、条件を指定してデータを絞り込んだり、除外するための機能です。

フィルタについて

フィルタは特定の条件による絞り込みや除外を後から使い回せるように永続化したい場合に利用します。例えば以下のような場合です。

• 特定の条件でpriceの値に0が入ったり100万のような異常に大きい値が入ることがあり、データ分析で平均値を歪めることになるため、事前に除外しておきたい
• データソースは全社に関するデータを使っているが、このレポートでは自分の所属する部署のデータのみに絞り込みたい

フィルタの適用は様々な粒度で設定可能で、「レポート」「ページ」「グラフ」の粒度で設定できます。複数のフィルタを設定して、それらのANDやORを組み合わせることもできるので、柔軟な設定ができます。より詳細については公式のヘルプを参照してください。

フィルタはSQLなどが書けないデータソース(例: Search ConsoleやGoogle Ads)で特に役に立ちます。一方で、BigQueryなどSQLが書けるようなデータソースでは個人的には利用を推奨しません。なぜならば、データの加工や絞り込みは基本的にSQLで担保すべき責務であり、SQLでも絞り込みをやっているが、Looker Studioのフィルタでも絞り込みをやっていて、となった場合にデータがどこで抜け落ちてしまっているかの判断が難しくなるためです。フィルタの設定はレポートの編集者以上の権限がないと分からないため、判断するにもそもそも権限がなくて判断しようがない、ということも起こり得ます。そのため、フィルタの設定はSQLが書けないデータソースに対してのみ行うなど、最小限に抑えるのがLooker Studioでメンテナンスしやすいダッシュボードを作る際のポイントです。

calculated fields(計算フィールド)についても同様で、calculated fieldsが多数登場するようなダッシュボードはSQL側で担保すべきロジックが染み出しており、メンテナンスしにくい作りになってしまっている、ということを頭の片隅に置いておくと良いでしょう。Looker StudioのようなBIツールでは基本的にロジックを書くべきではなく(ロジックを書くとしてもカスタムクエリのような一箇所に押し込める)、可視化など表示に関する部分のみを担保するのが、メンテナンスしやすくするコツになります。

コントロールについて

フィルタは絞り込みや除外の条件を後から使い回せるようにする設定(ダッシュボードを見ている人に対して一律に設定される)でしたが、コントロールはダッシュボードを見ているユーザー自身が条件を操作しながら探索的に分析するためのパーツになります。例えば、以下のようなダッシュボードに表示する期間を調整するものや、特定のユーザーに関するデータだけを出したい場合のモーダルがコントロールの例になります。

---

コントロールは基本的に分析の軸となるディメンションに対して設定することが多いですが、指標(メジャー)に対してスライダーで絞り込みを設定することもできます。

---

コントロールを操作して得られたインサイトを同僚に共有したいことはよくあると思います。スクリーンショットを撮ってそれを共有しても良いですが、共有された側はその条件を再現するために再度コントロールを操作する必要があります。Looker Studioはコントロールなどの条件を保持したリンクを発行してくれるので、スクショを取る必要がなく、このリンクを共有すれば同僚の手元でも条件を簡単に再現することができます(「 レポートの現在のビューにリンクする」というオプションがONになっていればよいです)。

コントロールの条件を保持したまま、同僚にレポートを共有

---

コントロールは複数のグラフに対して有効化できますが、同じ種類のコネクタを使っており、コントロールで指定するフィールドが同名で定義されている必要がある点は注意が必要です。コントロールは便利な機能ですが、それを有効に機能させるためには命名規則にも気を配る必要がある点を覚えておきましょう。詳細は公式のヘルプを参照してください。

---

余談ですが、コントロールは私がLooker Studioの中で好きな機能Best3に入る機能です。BIによっては、DWHからデータを取得後、BI上でデータをフィルタの計算をするものがあります。これは取得するデータが大きいとBIにかなり負荷をかけるものになりますし、ダッシュボードを閲覧するユーザーにとっても待ち時間が長くなってしまい、体験としてよくありません。これを避けようとすると、DWHからのデータ取得時点でフィルタするようなクエリを書く必要があり、BI側ではフィルタ済みのデータしか見えないため、探索的なデータ分析が制限されてしまいます。

一方、Looker StudioはBI上のフィルタの条件を考慮した上でDWHからデータを取得するようにクエリをwrapします。巨大なデータを扱うのが得意なDWHにその責務を渡すので、BI自体に負荷をかけることなくダッシュボードを閲覧するユーザーにとっても素早くデータを閲覧できます。ダッシュボードを見るユーザーに不要な制限を課さず、探索的にデータを見れるようにサポートしてくれる地味ですが大好きな機能です。

クロスフィルタリングで複数のグラフを連動させる

クロスフィルタリングはコントロールと同じく自分がLooker Studioの機能の中で好きな機能の一つです。クロスフィルタリングは「グラフ内で 1 つ以上のディメンション値をクリックする」「期間グラフ、折れ線グラフ、面グラフの上でマウスをクリックしてドラッグし、領域を選択する」などに連動して他のグラフも絞り込みを行えるというものです。具体例を見たほうが分かりやすいと思うので、下記の動画や参考ページなどを見てもらうと便利さが分かると思います。

クロスフィルタリングはほとんどのコネクタで有効になっているため、あまり意識しなくても勝手に使える状況になっていることが多いと思います。一部のグラフでのみクロスフィルタリングを無効にしたかったり、コントロールと同じく命名規則などが合っていないとクロスフィルタリングがうまく動かない場合は以下を参照するとよいでしょう。

• グラフのクロスフィルタリング - Looker Studioのヘルプ
• Looker Studio(旧データポータル)のクロスフィルタが効かない時に確認する３つのポイント | DevelopersIO

Looker Studio Explorerでよりアドホックな分析をする

Looker Studio自体はBIツールであり、後から見返す用のダッシュボードを作る想定で触ることが多いでしょう。とはいえ「ダッシュボードにしたいわけじゃないんだけど、これから分析したいテーブルを軽く可視化したり、クエリ結果を可視化したいんだよね」という場合もあると思います。そういった場合にはConnected Sheetsを使う人も多いと思いますが、アドホックな分析をする度にConnected SheetsがGoogle Driveにどんどん溜まっていくのはあまり気持ちのいいものではありません。「気持ちのいいものではない」をもう少しきちんと言語化すると

• 個人情報*6が入ることがありえるデータがBigQueryの外側の世界に簡単に行ってしまう
  • BigQueryの中の世界で権限管理をいくらきちんとやっていても、Google Driveの中の管理がきちんとできていないと台無しになってしまう恐れがある
• アドホックな分析をした後に気を付けて削除を忘れないようにしないといけない
• アドホックな分析用に作ったConnected Sheetsが溜まってGoogle Driveが散らかってしまう

などが挙げられると思います。アドホックな分析はアドホックな分析が終わった後にさっと消えてしまって欲しいものです。

Looker Studio Explorerはそんなアドホックな分析にまさに向いているものです。Looker Studio Explorerはデータカタログ(Dataplex)の検索結果やBigQueryのクエリ結果からボタン一つでめちゃくちゃ簡単に呼び出すことができます。

データカタログの画面からも簡単にLooker Studio Exploreを呼び出せる

BigQueryのクエリ結果からも簡単にLooker Studio Exploreを呼び出せる

使い勝手はLooker Studioとほぼ同じで、アドホックなデータの傾向が分かったらタブを閉じればその結果も綺麗さっぱり消えてくれます。Connected SheetsのようにGoogle Driveに溜まっていくこともありません。

Looker Studio Explorerで作ったものをレポートに昇格させる、といったこともできます。詳しくは公式のヘルプを参照してください。

相対比較で過去の値と比較する

プロダクトやサービスを運用していれば「前年同月の値と比較したい」といった過去の値と比較してどうかを見たいことは多いと思います。SQLで書くのであれば、Window関数であるLAG関数を使って書けますが、Looker Studioではグラフの設定をぽちぽちやるだけで比較できます。

やり方は簡単で、「期間のディメンション」を設定した上で、見たい指標をグラフで描画させます。その上で「比較期間」を選択し、「前の期間」や「前年」を指定すれば過去の値との比較を簡単にできます。

---

30日だと曜日の影響を受けることが多いので、過去28日で比較することが多かったりしますね。詳しい設定の仕方は以下を参照してください。

• 比較指標と累積合計を追加する - Looker Studioのヘルプ
• Googleデータポータルで前年や前月と比較したデータを表示する | DevelopersIO

継続的に運用するための権限の設定

Looker Studioを便利に使いこなせるようになってきた頃に問題になるのが権限の設定です。特にLooker Studioのレポートを作っていたオーナーが退職してしまうと、レポートが見れなくなってしまう問題はあるあるです。レポートが見れなくなる原因は複数ありますが、そのためにはLooker Studioの以下の3つの要素を抑えておくのが重要です。

• レポート
• データソース
• 認証情報

レポートはダッシュボードなどグラフなど全体のリソースのことを指します。レポートのオーナーが退職すると、レポート自体が見れなくなるので、退職前に移譲の準備が必要です*7。

データソースはダッシュボードに表示する元データの設定になります。カスタムクエリを書くのはデータソースの例ですね。

認証情報はデータソースへの接続を誰の認証情報を使って行うか、というものになります。ディフォルトだとデータソースのオーナーの認証情報が使われますが、閲覧者の認証情報を使ったり、サービスアカウント経由にすることもできます。

「このダッシュボードは誰が見ているか」という情報が欲しい場合は閲覧者の認証情報を使うのが一見便利にも思えますが、人によって閲覧できる/できないが異なってくるため、管理の手間がかかるなどもあるため、レポートによって最適な設定は異なってくると思います。

権限の設定やガバナンスを効かせるための管理方法については、以下のエントリなどを参考にするとよいでしょう。

• 担当者の退職で Looker Studio のレポートが壊れてしまう問題への対処法 - 風音屋TechBlog
• Looker Studio: Looker Studio からサービスアカウントを使用して BigQuery と接続する #GoogleCloud - Qiita
• 後回しにするとどうしようもなくなる（かもしれない）Looker Studioの権限を理解する #BI - Qiita
• Looker Studioで組織内に魔境を作らないための裏技的Tips集 #BigQuery - Qiita
• Looker Studio Pro で料金を抑えながらレポートを管理する方法 - 風音屋TechBlog

データソースの設定: 埋め込みと再利用可能

細かいですが、データソースには埋め込みと再利用可能という2つの種類が存在します。

埋め込みはレポートにデータソースの設定が埋め込まれるものであり、再利用可能は複数のレポートで利用できるデータソースとなります。込み入った設定を色々なレポートで行う場合、再利用可能の設定にしておくと一箇所で設定が済んで楽ですが、設定を変更すると様々なレポートに影響し得るため注意が必要です。個人的にはLooker Studioでは基本的には埋め込みの設定にしておくのがオススメかなと個人的には思っています。この理由としては

• 込み入った設定の例としてはカスタムクエリなどがありえますが、こういった設定はdbtなどクエリ側でやっておくのがよい
  • 設定変更がgitなどで履歴管理できる
• Looker Studioはどのデータソースがどのレポートで使われているといったリネージが分かりやすくはないため、再利用可能にした場合管理が難しくなりがち
• また、再利用可能から埋め込みに変更することはできない

といった背景があるためです。

監査ログでどのダッシュボードがBigQueryのどのテーブルを参照しているか把握する

Looker Studioが組織内で広く使われるようになると、元データを提供するデータエンジニアや管理者はデータリネージを把握したくなることが多いと思います。どのテーブルがどのLooker Studioのダッシュボードから参照されているかが分かれば、テーブルの撤退や修正などがやりやすくなるためです。Looker StudioからBigQueryに向けて発行されたクエリはINFORMATION_SCHEMAでラベルの情報として取得可能なため、そういったメタデータを活用するとよいでしょう。dbtを使っている場合にはexposureとして取り込むのも有用です。

自分はまだ試したことがないですが、Looker Studio Proを利用している場合はDataplexのリネージにLooker Studioのレポートも含まれるようになるそうで、よりマネージドな形でサポートを望む人は使ってみてもいいかもしれません。

参考: 私がLooker Studio上でダッシュボードを作っていく過程

ベストプラックティスかは分からないですが、ここ数年は「こうやってLooker Studio上のダッシュボードを作り込んでいくと、うまく作れたり、作ったダッシュボードがちゃんと使われているなぁ」というフローが固まってきたので、参考までに書き残しておきます。Looker Studioを例に書いていますが、概ね他のBIでも通用するやり方にもなっているんじゃないかなと思います。

なお「データソースがめちゃくちゃ巨大であるケース」や「他社に提供するダッシュボードであるため、仕様が最初からカッチリしたものを提供する必要がある場合」などはこの過程は適さない可能性が高いかもしれません。ダッシュボードを作る目的や要件の整理などについては、以下を参考にするとよいでしょう。

ステップ0: データがあまりにも汚ない場合は下準備をしておく

BIで料理をするにはあまりに整備されていなさ過ぎる場合は下準備を行ったほうがよい場合もあります。

• 例: 元データが会社毎や月別でバラバラに置いてあり、UNION ALLを30個くらい繋げる必要がある場合
• 例: SaaSから取り込んだデータで、STRUCTが入り組んでいたり、JSONを溶き解す必要がある場合
• 例: データがクエリで集計しにくい横持ちになっており、Pythonのスクリプトなどで縦持ちに変換したほうがよい場合
• 例: ダッシュボードで登場するEntityがあまりにも整備されていない場合
  • JOINの条件があまりにも複雑になり過ぎる場合、登場人物の整理をして、簡単にクエリが書けるように整備しましょう
  • 例: 簡単に分析できるようにディメンショナルモデリングでfact / dimのテーブルを準備する
  • 例: data vaultでhubやlinkを整備する

ステップ1: BigQuery上で柔らかい簡単なクエリを書く

初手はLooker Stuidoではなく、BigQueryでraw dataを加工するクエリを書くことが多いです。この場面では以下を念頭に置きながらクエリを書きます。

• 型合わせ: STRINGで入っているデータをparseしてDATE型にする
  • Looker StudioのようなBIで扱いやすいようにするため
  • Looker Studioでもcalculated fieldsのような変換はできるが、粒度を変えない変換についてはクエリでやっておくと責務として適切になることが多く、後々メンテナンスしやすい
• 複数のデータソースをまとめる必要がある場合はJOINしておく
  • 途中でも書いたが、Looker Studio上でのJOINは遅かったり、ミスに気付きにくいため、この段階でJOINは済ませておく
• BI上でフィルタできるようにフラグのカラムを追加する
  • クエリ上でフィルタしてしまうと、色々な見せ方に対応できないことも多い
  • クエリ上ではフィルタせず、フラグを付けてBI上でフィルタのありなしを制御できるようにしておくと便利
    • 例: コストを調べたいときにユーザーアカウントかシステムアカウントかのフラグ用のカラムを付与する
  • あらゆるものに対応できるようにするのは大変なので、ここは要件にもよる
• user_typeのようなenumで入っているデータをhuman readableな値に変換する
  • BIを見る人に「user_type = 1(例: レガシーシステムからの移行ユーザー)」はどういうケースだっけ...のような調べる手間を省けるようにする
  • ダッシュボード上は表示しないけど、元のカラムの値も持っておくと初期のデバッグはしやすい
• 丸め過ぎたりサマり過ぎた集計にしすぎない
  • date_trunc(..., month)のような丸めは後段のBI上でもできる
    • 見たい粒度はBI上でグリグリ変えたい場面も多いので、TIMESTAMP型や丸めずにDATE型で持っておくと便利なことが多い
  • BI上でドリルダウンしたいことも多いので、この段階ではあまりに気合を入れ過ぎてサマった値に加工しないようにする
    • データ量がそれほど多くない場合、最小粒度でデータを保持しておくことも多い
    • 最小粒度に近い形式のクエリにしておいたとしても、可視化する段階ではLooker Studioがいい感じのGROUP BYのクエリで包んでくれることも多い
    • BIによってはBI上で集計が走ったり、クライアント側で集計が走ることもあるので、BIによってはこの方法は避けたほうがよいが、Looker Studioの場合は裏側でBigQueryにいい感じに投げてくれるので、安心してこのやり方をやることが自分は多い
• データ量が多い場合、対象の期間を絞ったり、サンプリングをしておく
  • 例: 一年ではなく直近3日に絞る
  • 例: サンプリングはTABLESAMPLE SYSTEM (10 PERCENT)のようなやつ
  • 後段でアドホックに触るときもコストに怯える必要がなくなりますし、インタラクティブにBIの設定を変えるときに試行錯誤がしやすくなります
  • この辺の条件は後段の後からちゃんとするフェイズでやれば十分

ステップ2: BigQueryでクエリ結果を可視化 or Looker Studio Expoloreで可視化

まだLooker Studioで可視化はしません。ステップ1で割と細かい粒度のデータを出力できるようになったら、大雑把な件数や傾向が合っていそうか確認するステップがここになります。BigQueryでクエリを実行した結果はBigQuery上で簡単な可視化ができたり、ボタン一つでデータを探索することができます。私は前述したLooker Studio Expoloreを使ってデータを探索することが多いです。

このステップでは以下のことをインタラクティブに確認することが多いです。より後段のステップでもいいですが、明示的にステップ2を挟むことにより、ダッシュボードのバグが生まれる可能性を下げることに繋がりやすいです。

• 生データの行数の確認
  • ステップ1で複数データをまとめた場合、JOINが間違っていると行数が膨れ上がってしまったり(fan-out)、減り過ぎてしまっている場合がある
  • 例: 月毎に軽く集計して、件数が間違っていないか
    • そもそものraw dataの件数と比較したり、ドメインエキスパートに聞いたり
• 簡単な統計量の確認
  • 例: user_type_strで集計(GROUP BY)させてみて、データやクエリが間違っていないか
    • 統計量を確認してみると、クエリが間違えていて特定の会社のデータしか対象にできていなかったり、合計5種類ありえるtypeが3種類しか登場していなかったり、そもそも元データから間違っていた、などもあり得るため
  • 例: GMVなどドメイン知識がある場合、それと照らし合わせて前提を満たせていそうか確認
    • この段階で前提を満たせていない状況の場合、後段のダッシュボードを作り込んでも仕方ない
• 傾向の確認
  • 例: 月毎に件数をplotしてみて、異常に件数の少ない月などがないか確認
  • 例: 散布図を書いて、相関関係の確認
  • 例: ヒストグラムを書いて、データの分布を確認

ステップ3: カスタムクエリとしてLooer Studioのデータソースを作成する

ようやくこの段階になってLooker Studioの画面を開きます。レポートのデータソースとしてステップ1~2で作成 & 簡単に検証したクエリをカスタムクエリとして作成します。クエリを書くといってもLooker Studioのカスタムクエリのエディタは特に書きやすいわけではないため、ステップ1&2で書いたクエリをコピペするだけのステップです。

ステップ4: Looker Studioで可視化

ステップ3で作成したデータソースを元に、ようやくLooker Stuidoで可視化します。ステップ1で細かい粒度でデータを持たせたままにしていることが、ここで生きてきます。生データを表形式で表示して、違和感があったらすぐデバッグできるようにしつつ、全体の傾向が分かる時系列グラフなどをまず配置していきます。その後、ディメンションで積み上げたグラフなどを追加し、深掘り分析できるようにしていきます。見た目や配置など細かいところはこの段階では拘らず、ダッシュボードを通じて見たいものを作っていきます。

可視化を行ってみた結果、「この軸が足りないな」と思うことも多々あるので、その場合はステップ1に戻りつつ、カスタムクエリを修正することも多いです。

ステップ5: フィルタ(コントロール)の設定

Looker Studioでダッシュボードを作る場合、集計期間を変更したり、あるディメンションで特定の値のみに絞ってダッシュボードを再描画させたい、ということはよくあります。例えば「Xさんの利用コストが増えていそうだから、Xさんに絞って描画したい」とか「企業Yがあまり機能を活用できていなさそうだから、企業Yのみを対象にして調べたい」などです。

ステップ6: 見た目の調整や説明書きを追加

見せ方が決まってきたら、見た目を整えましょう。グラフの置き場所や配色などを調整します。これ以降のステップでは他の人にも見せることになるため、数値の定義やダッシュボードの見方などをテキストとして配置していきます。

レポートの見た目をいじっていると、いじる度にレポートの更新がされてしまい、BigQueryなどに都度クエリが発行されてしまいます。レポートの背後に巨大なデータがある場合、見た目をいじりたいだけなのに都度クエリが発行されるのは辛いものです。そういった場合、レポートの更新を一時停止する機能があるので、それを活用すれば安心しながら見た目を改善することができるでしょう。

ステップ7: 関係者にダッシュボードの閲覧権限を付与し、フィードバックをもらう

アウトプットが他者にとっても理解可能なものになっているか、目的を達成できそうか、などの観点で関係者からフィードバックをもらいましょう。あまりに広く権限付与するともらいたいスコープ外のフィードバックがきて収集が付かなくなることもあるので、この段階では関係者のみの権限付与がよいことが多いです。

ステップ8: カスタムクエリをメンテナンス可能な状態にしていく

ステップ7までが完了していると、Looker Studioのダッシュボードは最初のころよりかっちりしたものになってきると思います。かっちりというのは

• 必要な期間
• 必要な粒度
• 必要な軸やmetrics

などの仕様が固まってきたことを指しています。ステップ0で事前に整理したとしても、このステップにくる頃にはカスタムクエリは50~200行くらいになっていることも珍しくはないでしょう。このステップではこのカスタムクエリをメンテナンス可能な状態にしていきます。howは何でもよいですが

• Gitでスケジュールクエリにしてレビューしてもらえる状態にする
• dbtやdataformで管理し、クエリを分割したり、テストを書いたり、descriptionを書いたりする

などが挙げられるでしょう。ステップ2で目視で確認していた内容がCIなどでテストできるようになっていると大分安心感が出てきますね。

最初はダッシュボードをこねくり回したり、関係者からフィードバックをもらってサイクルを早く回したい場合も多いので、最初はカスタムクエリのような柔らかい形で作って、このステップ8でようやく固く作る、というような流れにしています。逆に言うと「ステップ8を挟まないダッシュボードはかなり信頼性という意味では低いもの」という意識を持っておくのがよいでしょう。

ステップ9: 権限管理の適正化

関係者以外にもダッシュボードを広く展開していく場合、権限管理を再度見直しておくと安心です。

• 完全にサマった値しか出ないので、全社員に展開しても問題ない
• 企業別の統計量が出ているので、ガバナンス上必要な人のみに展開する
• オペレーション的な用途を想定しており、raw dataと同じ粒度の情報を保持しているため、権限は限りなく狭くする

など、ダッシュボードの目的や出している粒度や値などを元に権限を管理していきましょう*8。

ステップ10: 必要であれば通知の設定などを組み込む

関係者に定期的に見て欲しい指標やダッシュボードであれば、前述したようにEmailやSlackに通知の設定を組み込むとよいでしょう。単純に通知しているだけだと人間は徐々に見なくなっていくものなので、定例のミーティングでそれらを参照するように仕組み化など工夫するとよいでしょう。

感想

Looker Studioのいいところや便利な使い方をこれでもかとまとめてみました。多分、Looker Studioのイケてないところも同じくらいの分量で書けると思いますが、そもそもこの分量で語れるということはやっぱり自分にとってはLooker Studioは好きなBIツールなんだろうなと思います(笑)。

*1:列単位の加工だけでなく、特定のセル単位のみの加工などがされていると最早諦めてしまう

*2:それでも魔境が生まれないとは言えないけど...

*3:色々できてしまうと、人間は色々カスタマイズ要望を挙げてしまいがち

*4:SQL上でJOINする場合はdebugがまだしやすいですが、Looker Studio上でJOINするとdebugの難易度がかなり上がる印象があります

*5:データエンジニア目線からしても、Looker Studioで激重ダッシュボードの改修依頼になる前に早めに相談して欲しいです

*6:氏名やメールアドレスが入っていなくても、容易照合性を満たす状況であればuser_idも個人情報になります

*7:退職後でも移譲できますが、Google Workspace管理者による作業が必要になります

*8:全社の権限付与の方針などがある場合はそれにも従いましょう