[Looker User Meetup in Tokyo #4] DeNAゲームタイトルの共通分析におけるLooker活用事例

Looker User Meetup in Tokyo #4 にて「DeNAゲームタイトルの共通分析におけるLooker活用事例」としてLTをさせて頂きました鈴木と出口です。

当日のLTは、Lookerを使いこなしている各社ならではのディープな話が多く、非常に参考になりました！

本記事では、LTには盛り込めなかった技術ネタや、我々の発表時に頂いた質問について返答する、フォローアップの記事を書かせて頂きます。

当日の資料

発表資料はこちらとなっております

また、クラスメソッド様が当日の様子をまとめた記事を執筆されています。我々の登壇以外も記事になっているため、興味のある方はぜひご覧になって下さい。

『 Looker User Meetup in Tokyo #4 』の発表内容まとめ #lookermeetup

当日のLTには盛り込めなかった技術ネタ

MeetupではProjectインポートによる方法をご紹介致しましたが、ここではProjectインポートの方針になる前にボツになった方法についてご紹介させて頂きます。

ボツになった案は、ダッシュボードは共通のものを一つ用意してUserAttributesによって利用者毎に閲覧出来る範囲を制限する方法です。

Meetupでもご紹介しました通り、共通集計では全タイトル分のKPIをまとめて集計しています。

集計したテーブルは、Projectインポート案のように各タイトルProjectに配布はせず、そのままLookerのダッシュボードの方で利用するようにします。

利用者がそのダッシュボードを閲覧する際に、利用者の権限としてUserAttributesによって閲覧できるタイトルを制限する事で実現します。

UserAttributesにはGroup ValuesかUser Valuesの2種類設定があります。

Group Valuesの方では、利用者が複数グループに所属してる場合優先度の高いvalue値しか扱えません。

今回の方針としては、ゲームタイトルを複数兼務している人だと兼務してる分のタイトルの数値を確認できるようにする必要がある為、Groupによる出し分けは出来ませんでした。

User Values の方は、利用者単位で権限を管理するように出来ます。

しかし、弊社の権限管理は今まで各タイトルで用意されたGoogle Groupによって権限を一元管理していました。

LookerのUserAttributesについても同じように権限管理するのは煩雑になるので、こちらの方法も不採用と致しました。

また、Projectインポート案の方では、viewやexploreを共通利用出来るようになる点でもProjectインポートの方が活用の幅も広がるので、それも決め手の一部でした。

当日頂いた質問への回答

Projectインポートした際にインポート先Projectの方で設定したい固有項目の扱いをどのようにしている？

Project毎にmanifestファイルを持ってインポート設定をしますが、その設定の中でconstantという設定値を用意する事ができます。
設定値はviewファイルやexploreのほうでそのまま利用する事が可能です。
constantにはインポートしたProjectでこの値をどう扱うかを指定するオプションとしてexportが存在します。

exportにはnone, override_required, override_optionalという3種類が存在しており、それぞれ挙動が変わりますので変数に応じて変える必要があります。

インポート先Project側で値を上書き設定するには、manifestファイルに override_constant を記載することで継承元のconstantの値を上書きすることができます。

このようにして固有項目をProject毎に分けて扱うようにしています。

KPI別のviewを作成する際、どのレベルのKPIからviewを作成するかについて、チーム内でどのようにコンセンサスをとっておりますでしょう？

例えば「休眠している課金ユーザ数」のようなKPIを新しく作成する場合、新たにviewを作成するのか、あるいはdau.viewに追加するか、など。（それとも一律にviewを作成しているのでしょうか？）

今回は、事業部に都度確認することなく、Looker開発メンバーのみでコンセンサスを取って進めました。既存で定点観測しているKPI群があったため、それらをどのようにLookMLに落とし込むかを開発時点で相談しています。

運用があまり固定化されていないKPIの扱いが気になります！

(※筆者補足：上記「定点観測しているKPI群を移した」という回答を受けての質問です)

こちらに関しては、まだ発生していないため今後の挑戦となります。

まずは個別のゲームタイトルである程度独自の実装を行い、複数タイトルで共通指標として扱いたくなったタイミングで、共通KPI開発メンバーで相談をしてLookMLに落とし込んでいく流れになるかと思います。

LookML は何名で開発していますか？

最大5名で開発をしております。今後は、共通KPI部分以外の開発も進捗させるべく、Dev権限の保持者を拡充していく予定です。

おわりに

弊社のLooker導入の取組については他にも、データエンジニアの岩尾がLooker Beaconに登壇発表しております。そちらのフォローアップ記事も、是非御覧ください。

引き続き、Lookerの知見について幅広く共有していこうと思います！