System Activityエクスプローラを使ってLooker活用のPDCAを回す

※ 本投稿はLooker Advent Caledar 2021 初日の記事となります。

みなさんは、社内で、あるいは社外のダッシュボードを提供している先で、どれくらいのユーザーがLookerを使っているか正しく把握できていますでしょうか?

Lookerを活用してデータの民主化を進めていく上で、「多くのユーザーがきちんとLookerを使えている状態にあること」というのは気にするべき一つの重要な指標になります。せっかく頑張って作成したエクスプローラやダッシュボードも、ユーザーに使われなければ意味がありません(悲しい)。

Lookerのシステムアクティビティを使うと、みなさんが作成したダッシュボード/エクスプローラが果たしてどれだけ実際に使われているのか、ライセンスを付与したユーザーがどれだけアクティブにLookerの機能を使っているのかを確認することができます。

デフォルトで用意されているSystem Activity ダッシュボードでは大まかな活用状況を知ることができますが、System Activity エクスプローラを使用すると更に一歩踏み込んだ活用状況の探索が可能になります。

3cd8d948-4cb3-45be-9684-15110e0ee896.png

以下にSystem Activityエクスプローラを使った実際の探索例と、そこから見える課題、更にはそれをどう改善していくべきか、というサンプルをいくつか示したいと思います。

ケース1: Viewerの人たち、ちゃんとLooker使ってる?


利用するエクスプローラ:User
利用するフィールド例:

12ca7748-bb21-41e6-8908-fa31eec60c68.png

フィルター例:

88dabc6b-144f-4ece-8f32-3a4a5e34cb92.png

Viewer権限を持つユーザー数のうち、直近7日間 or 30日間にクエリを実行した人の数を取得します。部署やチーム毎にグループを設定している場合、グループ (Group.Name)のディメンションを追加することで部署・チーム毎での利用実態を確認することも可能です。

[ここから見えること]

例えば以下の結果だと、Viewer相当のユーザーは128名いますが、直近7日間にクエリ実行した人は4名、30日間でも8名しかいません。これは由々しき自体です。より多くのユーザーにもっとLookerにログインし、ダッシュボードをみてもらうようにする必要があります。
6XlLA2oEBbOGADl4nF043_kepLZJsIUfdCroZZ5M1GO2PgfuLZTn5ISOOCzoQMluymEZnFE59o9md03KV21DD2guUQ0hX8LhliO-17VQp0ROROV-gkDVHNtFMewVCW4IBNQf_T5WEg

[取るべきアクション]

ユーザーに対して、なぜダッシュボードをみないかの理由をヒアリングしてみましょう。よくあるパターンと改善の方向性を以下に記します。

  • フィルタが多くてわかりにくい・使いづらい → コンテンツ自体を改善
  • 見たいデータがない・足りない → 必要に応じてデータパイプライン・LookML改善
  • いちいちLookerにログインするのがめんどくさい → Slack連携, Salesforceへの埋め込み等で普段使うツール上で自然とデータに触れられるようにする
  • データの見方がわからない → それぞれのデータからどういった示唆が得られるのかを示す (配信にコメントを添える)


ケース2: あのダッシュボード、うちのチームメンバーみんなちゃんと見てる?
 

利用するエクスプローラ:History
利用するフィールド例:

347cbfbf-d4c7-4974-b2aa-653af9a98b3c.png

フィルター例:

c60bf064-6ad3-470b-9d7b-ab5fa8a3bed0.png

ダッシュボード毎のRun Count (実行回数) を取得します。上記サンプルでは過去1月としていますが、必要に応じて調整してください。また、ダッシュボードが大量にある、もしくは利用状況を確認したいダッシュボードが明確になっている場合は ダッシュボード ID (Dashboard.ID) で絞りましょう。特定のチームが特定のダッシュボードをみていることを確認したい場合はグループ (Group.Name) のディメンションを追加してみましょう。
 

[ここから見えること]

ダッシュボードによって、見て欲しい人・チームというのは異なってくると思います。全体の実行数で見ると悪くないが、実は見るべき人があまり見ていなかった、という事態は改善する必要があります。

[取るべきアクション]

基本は先と同じで、ユーザーに対してなぜ見ないかの理由をヒアリングしてみましょう。先のよくあるパターンに加えて、以下のようなコメントもあるかもしれません。


 

ケース3. Standard Userの人たち、ちゃんとエクスプローラ使ってる?

利用するエクスプローラ:History
利用するフィールド例:

f5073f04-2f34-4996-9ffe-4ce2240fd2ee.png

フィルター例:

968f9738-9a77-4624-bcf2-8dde2bf01a4e.png

Standard User権限を持つユーザーについて、エクスプローラ毎のクエリ実行回数と利用ユーザー数を取得します。上記サンプルではクエリの実行タイミングを過去7日としていますが、必要に応じて調整してください。また、これもチーム毎で見たい場合はグループ (Group.Name) のディメンションを追加してみましょう。

[ここから見えること]

データの民主化を進めていく上で、各個人がエクスプローラを使ってデータ探索できるようになることは極めて大きな意味を持ちますが、一方で誰しもが初めからエクスプローラを簡単に使いこなせるものではありません。構築したエクスプローラがきちんと使われているかどうかを確認し、使われていないのであれば改善しましょう。
 

[取るべきアクション]

Standard Userに対してエクスプローラの改善ポイントをヒアリングしてみましょう。

  • 各フィールドの定義が分からない → Descriptionを記載する
  • フィールドが多すぎてどれを使って良いか分からない → Henryを活用して使ってないフィールドを洗い出しHiddenにする
  • 探索のとっかかりが分からない・難しい → Quick Startでよくある探索の型をテンプレ化
  • すぐに行き詰まる → 定期的なオフィスアワー・勉強会を実施

ケース4. Developerの人たち、本当にLookML触ってる?

利用するエクスプローラ:Event Attribute
利用するフィールド例:

4cae0339-c1da-46e6-96c8-5901ed348937.png

フィルター例:

ecd92fee-43c0-4f7e-b5a7-2d157db8e604.png

Developer権限を持つユーザーについて、開発モードに入ったユーザー数及び回数を取得します。上記サンプルでは直近3ヶ月を月毎に取得していますが、必要に応じて調整してください。チーム毎にDeveloperを配置している場合は、グループ (Group.Name) のディメンションを追加することで各チームのDeveloperがワークしているかどうかを確認することができます。

[ここから見えること]

Developer権限を付与したユーザーが実際に開発活動を行っているか (開発モードに入っているかどうか) を確認することができます。実際のユーザー数に対して開発モードに入っている回数が少なければ、積極的なLookML関連の作業はしていないとみなすことができます。
 

[取るべきアクション]

まずDeveloper権限の付与自体が適切であるか否かを検討し、必要がなければ権限を落とすなどしましょう。その上で、LookMLの運用体制を改めて見直しましょう。完全な中央集権型にするのかハブアンドスポーク型にするのか。後者であれば、各チームにDeveloperが配置され、各チーム内での個別要望にスムーズに対応できる状態になっていることが理想です。

  • セルフラーニングによる知識の習得・底上げ
  • Slack等での社内Developerチャネルの解説
  • 定期的なオフィスアワー・勉強会の実施
  • 社内FAQの構築

 

まとめ

いかがでしたでしょうか。上記の各ケースはあくまで一例となりますが、System Activityを使いこなすと現状の社内外でのLooker利用状況、ひいては組織として目指している姿とのギャップが明確になり、データ活用が進まない要因が見えてくるのではないかと思います。

逆にしっかりと活用できているユーザー (隠れData-Savvy (データに精通した人) かつData-thirsty (データに飢えた人)) を見つけ出したときは、社内のLookerアンバサダーとして活躍してもらうことも検討してみてください:spy_tone1:

私が所属するカスタマーサクセスチームでは、お客様内でのLooker定着化・活用支援を行っております。活用推進について課題やお悩みごとがございましたらお気軽にご相談ください!

System Activityの Historyや Event Attribute は一定量のレコード保持数を超えると古いものからレコードを削除する仕様になっております。イベント数が多い場合は短期間のログしか取れない可能性がございますのでご留意ください。長期間のレコードを保持されたい場合は別途営業担当またはCSMへご相談ください。

2 0 562