はじめに
こんにちは。推薦基盤ブロックの宮本です。
この記事では Looker Studio（旧データポータル）を利用したダッシュボード作成の属人化を解消するための Tips を紹介します。
背景
弊チームでは AB テストレポートや KPI の定常モニタリングとして Looker Studio を採用する機会が多いです。
Looker Studio を採用している理由としては BigQuery との親和性が高く、ビジネスチームへの展開が容易といった点などが挙げられます。
Looker Studio は簡単にダッシュボードを作成できるため、これまで開発のスピードを重視してチーム開発を意識せずに個人でサクッと作ってきました。
しかし、運用するダッシュボードが増えるにつれて自分以外のチームメンバーも開発にジョインするようになり、属人化防止に向けての取り組みが必要になってきました。
やったこと
Looker Studio 用に Google Cloud サービスアカウントを設定し、Looker Studio に代わってデータにアクセスできるようにしました。
具体的には以下を実施しました。
- Looker Studio でサービスアカウントを利用できるように設定
- 実際に Looker Studio でサービスアカウントを利用してデータにアクセス
Looker Studio でサービスアカウントを利用できるように設定
以下のドキュメントに従って設定しました。
実際に Looker Studio でサービスアカウントを利用してデータにアクセス
データソースとして BigQuery を利用例として紹介します。
Looker Studio 内のデータソースの管理の画面の右上にある「データの認証情報」をクリックします。
すると以下の画面が出るので、「サービスアカウント認証情報」を選択 & 作成したサービスアカウントを入力し、更新して完了です。
Tips
ここではサービスアカウント利用するのあたっての Tips を2つ紹介します。
- 基本的にカスタムクエリを使用しない
- サービスアカウントが属しているプロジェクトに Looker Studio で参照するデータセットやテーブルを一元管理しておく
理由は以下です。
- BigQuery と連携するたびにお金がかかるため、クエリが複雑になるとかなりのお金がかかる
- カスタムクエリ内で参照している他プロジェクトのデータセットやテーブルの参照権限をサービスアカウントに都度付与する必要がある
個人的には Looker Studio からアクセスするテーブルは分析用に整形されていることが望ましいと思っています。Looker Studio で必要なデータは整形されたデータだけであるため、不要な権限はできるだけ付与したくありません。また、サービスアカウントにどんどん権限付与していくと権限管理が難しくなるのを避けるためでもあります。
今後
Looker Studio 以外にも BigQuery のスケジュールクエリなど GCP の分析用サービスをにおいて、まだまだ個人のアカウントを利用しているケースが多いため、 サービスアカウントに切り替えて属人化を解消していきたいと思います。