Lookerベスト・プラクティス:Lookerユーザーにポジティブな体験を提供する方法 #looker

Lookerではトピック毎のベストプラクティスを個別にドキュメントやナレッジベースとしてまとめています。当エントリではその中から、『Lookerユーザーにポジティブな体験を提供する方法』についてご紹介したいと思います。

目次

 

ユーザーに対して意味のあるフィールド名を付ける

labelパラメータを使って、エンドユーザーに対してディメンションやメジャーの項目に『馴染みやすい』名称を付けることが出来ます。これはモデルにも同様のことが行えます。

例えば以下のような形で、変更を検討出来るでしょう。

  • Count → Number of 〜
  • Sum → Total

より馴染みやすい名称を検討するにあたっては、ビジネスユーザーと協力して幾つかの一般的なレポートを作成し、そこで使われている用語や説明から単語を確認していくと良いでしょう。

  • 同じ名前で、複数のフィールドを公開しないでください。カウント(Count)系のメジャーはLooker内で"Count"という名前で自動的に作成され、結果として同じ(Countという)名前でビューファイルが作成される形となります。 この状況だとユーザーを混乱させる可能性があるので、上述のlabelを使うか項目名を変更して混乱を回避してください。
  • 留意すべきその他のフィールドには「作成日(created dates)」と「更新日(updated dates)」があります。
  • 「yes/no」タイプのフィールドには明確な名前付けを行いましょう。例えば、アイテムが返されたかどうかを示すフィールドに命名する場合、「Returned」ではなく「Is the Item Returned」とするのが良いでしょう。
  • 命名はより説明的に。例えば、「Orders Per Purchasing Customers」(購買顧客毎の注文)は「Orders Percent」(注文の割合)よりも明確です。
  • フィールドの命名には一貫性を持たせてください。value_formatvalue_format_nameを使い、通貨記号やパーセンテージ、10進数の精度等の『書式設定』を数値フィールドに適用させ、読み易さを向上させます。

 

類似したフィールドをグループ化してナビゲーションを分かり易くする

group_labelパラメータを使って、関連する個々の結合ビュー、または複数の結合ビューのディメンションとメジャーを統合出来ます。

例えば、全ての地理情報を「地理グループ(Geography group)」としてまとめることで、

全てがアルファベット順にリストされることなく、フィールドピッカー内で関連する情報をまとめることが出来ます。

  • view_labelパラメータを使って、大きな非正規化テーブルを分割することも出来ます。
  • フィールド内でview_labelパラメータを使ってフィールドを論理的にグループ化し、フィールドピッカー内の見出し単位で情報を整理することが出来ます。フィールド数が多いテーブルだとそのままではナビゲートするのが困難です。このフィールドを活用することでExploreメニューのフィールドピッカーには複数のビューがあるように見え、使いやすくなります。

 

少ないことは良いことだ

  • Lookerでコンテンツを最初に公開する際は、過度に情報を公開しすぎないように気をつけてください。まずは小さく始めてから、徐々に広げていきましょう。全てのテーブル、または全てのディメンション・メジャーを一度に公開する必要もありません。最も重要なフィールドを公開し、ビジネスユーザーがデータ探索に自信を持ってから、徐々に情報を追加し、範囲を広げていくとスムーズです。
  • 使わないフィールドはUI画面上から隠すことが出来ます。hidden parameterをフィールドに指定することで、設定はそのままに、UI画面上から存在を非表示とすることが出来ます。
  • ユーザーが使用出来るフィールドの数を制限するには、エクスプローラ(Explore)及び結合(Join)の内部でfieldsパラメータを使用します。Exploreに関するフィールドのみをここに含める事で、情報の肥大化が軽減され、エンドユーザーのエクスペリエンスが向上します。hiddenパラメータとは異なり、Explore-by-Exploreベースでフィールドを含めたり除外が可能となります。

  • エクスプローラ(Explore)に対しても、hiddenパラメータを使って特定のLook、ダッシュボードタイル、またはフィルタを作成するためだけに存在しているExploreを非表示とすることが出来ます。エンドユーザーが探索に使わないエクスプローラー(Explore)はUI上非表示としましょう。
  • ユーザーが必要とする回答をスムーズに得られるように、エクスプローラの数は出来るだけ少なくしましょう。ユーザーのグループそれぞれに利用可能な選択肢を制限するために、異なるユーザー向けに異なるモデル、エクスプローラを分割することを検討してください。数が多くなるとユーザーの混乱を招く可能性があるので、上述のgroup_labelの活用も合わせて検討してください。

 

説明(description)を追加して、ユーザーが使うエクスプローラ及びフィールドを把握出来るようにする

  • モデル内で使用するロジックや計算に関する追加情報をユーザーに共有するために、ディメンションとメジャーにdescriptionを追加出来ます。(ユーザーがフィールドの背後にある定義を理解出来るようにするために、ここに記載する情報も考慮が必要です。)
  • エクスプローラ(Explore)に対するdescriptionパラメータを使い、ユーザーに対してエクスプローラ用に短い説明を追加し、「目的」と「対象ユーザー」をユーザーに伝えることが出来ます。

 

Lookerへの一般的なワークフローの構築

  • 関連する全てのメジャーをdrill_fieldsに追加することで、ユーザーは集計値をクリックして詳細データにアクセス出来るようになります。setパラメータを使い、ビュー内の任意の数のメジャーに適用可能な、フィールドの再利用可能なセットを作成します。
  • 全ての階層ディメンションにdrill_fieldsすることで、ディメンションの追加・掘り下げが可能になります。例えば、City(都市)のディメンションをState(州)のディメンションに追加すると、ユーザーはState(州)を選択し、その州内の都市を更にドリルダウンすることが可能となります。(※この階層ドリルは、時間ディメンショングループ内では自動的に適用されます。)
  • ユーザーが他のLookerダッシュボード、またはLooker外の外部システムやプラットフォームに簡単にナビゲート出来るリンクを設定しましょう。ドリルにフィルターを渡す例については、linkパラメータに関する以下のドキュメントをご参照ください。

 

まとめ

というわけで、Lookerにおける『Lookerユーザーにポジティブな体験を提供する方法』のご紹介でした。

Lookerでは様々な要素、機能がありとても便利なサービスですが、機能が豊富なゆえにそれらをガイドする作りにしておかないと逆にユーザーの混乱を招いてしまいかねません。当エントリで紹介した内容を踏まえてUi・情報を設定しておくことで、Lookerを使った分析・可視化がスムーズに進められるのでポイントを見極め、活用して行きたいところですね。