Yappli Tech Blog

株式会社ヤプリの開発メンバーによるブログです。最新の技術情報からチーム・働き方に関するテーマまで、日々の熱い想いを持って発信していきます。

Looker Studioでのマルチテナントなダッシュボード構築

このブログでわかること

Looker Studio でユーザーごとにデータを出し分ける方法、および実サービスへの適用例

はじめに

こんにちは、ヤプリのデータサイエンティストの阿部です。今年からデータサイエンスグループが誕生して、私を含めてメンバー4名となりました。2022年12月まで私ひとりだったので、1年4ヶ月で4倍になりました。同業の仲間がいるって素晴らしい。

ちなみに名称はデータサイエンスグループですが、分析用データ基盤を整えるデータエンジニアリングから、顧客向けにデータソリューションの提供までを担う「データ活用全般を担うグループ」です。社内のセールスやマーケティング向けのBI整備も担当しており、今のところ社内で唯一のデータ系組織として、全社横断的に活動しています。

ヤプリで提供しているアナリティクスツールの種類

さて、そんなデータサイエンスグループですが、アプリプラットフォーム「Yappli」の導入顧客向けに、現在3つのアナリティクスサービスの運用に関わっています。下記表の1~3です。

Yappliがプラットフォームであるため、顧客向けのデータソリューションにおいても、私たちは汎用的なサービスを開発する場面が多くなります。その場合、同じテーブルから顧客ごとにデータを出し分ける機構が必要です。つまり「マルチテナント型のデータ分析基盤」を構築しなければなりません。

上記アナリティクスサービスについても、それぞれマルチテナント方式を実現しており、最右列のようになっております。今回はこのうち、Yappli Analyticsのマルチテナント実現方法をご紹介します。

Yappli Analyticsとは

Yappli Analyticsとは、Yappli導入顧客に無償で提供しているアナリティクスツールです。ヤプリでは元々、Google Analytics(ユニバーサル アナリティクス, 以下UA)を顧客へ提供していたのですが、UA終了に伴い、新たなツールを用意することになりました。

新ツールの選択肢としてGoogle Analytics 4(以下GA4)もあり得ましたが、データ分析目線では

  • トラッキングデータのみならず、GA4に送信できないサービス用DBの分析ニーズも高い
  • GA4はウェブとの横断分析がメリットの1つ。そのためには、顧客のGA4プロパティにデータを送信する必要があり、コミュニケーションコストが高い(UAではヤプリでプロパティを用意して、その閲覧権限を顧客に付与していた)
  • GA4は高度なデータ活用が可能だが、要求されるリテラシーも高い

の理由で、ヤプリでツールを開発することにしました。また、

  • できるだけ少ない人数で高速に開発できること
  • ユーザが増えてもコストが線形に増えないこと

を目指したため、アナリティクスの基盤としては、無償のBIツールであるLooker Studioを採択しました。ヤプリがDWHとして採用していたGoogle BigQueryとの相性の良さや、マルチテナントを実現する目処が立っていたことという理由もあります。ちなみにGA4へのデータ送信もオプションとして用意しており、顧客は両方利用できます。

そうして2023年の3月にYappli Analyticsをリリースしました。結果、毎月700名以上が利用するアナリティクスツールとして運用が続いています。BIツールをベースに、この規模のアナリティクスサービスを外部提供した経験は、私の13年間のデータ系キャリアで初めてだったので、1つ成長した気になれました。

Yappli Analyticsのマルチテナント方式

Yappli Analyticsでは基本的に、顧客は自身のアプリのデータのみが表示されます。複数アプリを運用する顧客の場合は、以下のようにトップ画面で任意のアプリを選択できます。

この出し分け機構は、以下の4つの手順で実現しています。

  1. Googleスプレッドシートに[顧客のメールアドレス],[参照可能なアプリID]の2列のデータを用意する
  2. BigQueryのドライブクエリで、上記スプレッドシートを参照する
  3. Looker Studioのデータ接続のカスタムクエリで、集計結果のテーブルに対して、2のスプレッドシートのアプリIDをINNER JOINする
  4. Looker Studioのメールアドレスフィルタで2のうち当該のアプリIDのみ抽出されるようにする

ポイントをいくつか述べます。

まず、ユーザーごとのデータの出しわけのみであれば、Looker Studioのメールアドレスフィルタ機能で可能です。ただ、ここでスプレッドシートを利用しているのは、テーブルの列にメールアドレスの値を付加することが難しいためです。例えば、アプリのスクリーンごとに閲覧ユーザー数を集計したテーブルの場合、レコード数が膨大になるため、直近期間のみUPSERT方式で更新しています。そうなると、メールアドレスに変更や追加があった場合に、過去分のレコードを用意することができません。

3のカスタムクエリは以下のように設定しています。スプレッドシートに記載しているメールアドレスをemail、アプリIDをtarget_idとします。

@DS_USER_EMAILパラメータにはユーザーのメールアドレスが適用されます。スプレッドシート側のメールアドレスは大文字小文字が混在しやすいのでLOWER()で小文字に統一したり、空白文字の混入に備えてREGEXP_REPLACE(email, r'[  ]', '')を設けていたりします。

データソースはすべてBigQueryのテーブルをカスタムクエリで接続しています。課金プロジェクトは専用のBigQueryプロジェクトを用意して、スキャン料を管理しやすいようにしています。また念のため、スキャンバイト数に上限と、アラート閾値を設けています(もし上限に達したら、定額制のBigQueryプロジェクトに接続を切り替える想定です)

全体のシステム構成をまとめた図は下記となります。Looker Studio自体へのアクセス権限は、専用のGoogleグループで管理し、集計データの更新はdbtとtroccoで実施しています。スプレッドシートの管理は重要なポイントとなります。ここはカスタマーサクセス部門が運用を担当していますが、入力制限や登録時の複数人によるチェックはもちろん、各種データとの突合で整合性を担保するなどの仕組みを設けています。

おわりに

以上がヤプリで運用している、Looker Studioを利用したマルチテナントなダッシュボードとなります。ユーザー別に、カジュアルにデータを出し分けたい場合のご参考になれば幸いです。

Looker Studioはアナリティクス機能やUIUXのアップデートが著しいので、積極的にサービスに反映していけたらと考えています。また最近、Lookerを契約している企業は、(本来であれば有償の)Looker Studio Proを利用できるようになりました。Looker Studio Proでは、レポート配信機能や権限管理機能が強化されているので、活用できたらいいなと思っています。

お読みいただきありがとうございました!プラットフォーマーという立場で、データソリューションをつくってみたい方、ぜひお話ししましょう。カジュアル面談はこちらから!