Lookerでアクセスフィルターを設定して、見る人によって違うデータが表示されるようにする #looker

Lookerでアクセスフィルターを設定して、見る人によって違うデータが表示されるようにする #looker

爆熱アクセスフィルター
Clock Icon2019.12.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

どうも。大阪オフィスの玉井です。

BIツールに対してよくある要望として「見る人によって、表示するデータを出し分けたい」というものがあります。営業部の人間が見たときは営業部に関連するデータだけ表示して、マーケティング部の人間が見たときはマーケティング部関連のデータだけ表示する…しかし、ダッシュボードは一個にしたい…的な感じです。

もちろん各種BIツールはそのような機能を備えています。例えばTableauは下記の方法で実現することができます。

そして、Lookerもこういったことを実現することができます(アクセスフィルター)。というわけで実際にやってみました。

やってみる

対象ダッシュボード

実施する設定の概要

  • 上記のダッシュボードに対してアクセスフィルターを設定する
  • あるユーザーが上記ダッシュボードを見た時、自動的に「ブランド」の値をScooby Dooだけにフィルタリングする

実施する設定の手順

  1. アクセスフィルターを設定したいダッシュボードを決める
  2. ユーザー属性を作成する
  3. ダッシュボードの中でフィルタをかけたいLookのexploreを確認する
  4. modelファイルのLookMLにアクセスフィルターの定義を記述する(explore分)
  5. アクセスフィルターを設定したいユーザーに、ユーザー属性を設定する

ユーザー属性を作成する

まず、ユーザーに「このユーザーはこの値でフィルタリングします」と設定するためのユーザー属性を用意する必要があります。ユーザー属性はAdminメニューのUser Attributeから新規作成や既存ユーザー属性の編集等を行うことができます。

Create User Attributeからユーザー属性を作成することができます。

一部、個人的に覚えておいたほうがいいと思った項目について記します。

  • LookMLで指定する時に使うのはName
  • User Accessについて
    • 非管理者がこのユーザー属性を見られる or 編集できるかどうか
    • Editにすると、非管理者自身でユーザー属性を編集できる
    • 要件によっては合わない可能性もあるので注意する(そのユーザーには見せたくないデータがあってフィルタリングしたい場合など)
  • Data Typeについて
    • Stringは完全一致扱い
    • 複数の文字列値を使う時やあいまい検索のような動作を望む場合はString Filter (advanced)を選ぶ

詳細については下記をご覧ください。

今回は下記のように設定したユーザー属性を使用します。デフォルト値に%を指定する理由は後述します。

exploreの特定

アクセスフィルターはexplore毎に記述する必要があるので、アクセスフィルターをかけたいダッシュボード(のLook)で使用されているexploreを確認します。やり方は色々あると思うのですが、私は今回下記の方法で確認しました。

今回はダッシュボード全体にアクセスフィルターをかけたいので、このダッシュボードに使われているexploreすべてを特定します。ダッシュボードのメニューからGo to Dashboard LookMLを選びます。

すると、ダッシュボードのLookMLを見ることができます。ここで「explore」をページ内検索して、使用されているexploreを特定します。

このダッシュボードは下記2つのexploreが使われていることがわかりました。

  • order_items
  • events

LookMLでアクセスフィルターを記述

exploreがわかれば、いよいよアクセスフィルターを記述していきます(Modelに記述します)。

アクセスフィルターの構文は下記のとおりです。

今回の要件をもう一度整理すると、下記となります。

  • order_itemseventsにアクセスフィルターを定義する
  • アクセスフィルターに使用するユーザー属性はbrand_name
  • アクセスフィルターをかける値(ディメンション)はbrand

上記をLookMLに落とし込むと、基本形は下記のようになります。

explore: <explore名> {
  access_filter: {
    field:brand
    user_attribute:brand_name
  }
}

ただし、今回のように、(Lookerを通常運用している環境であれば)基本的にはexploreには既に色々と記述がされているはずですので、実際に組み込むと下記のようになります。

order_items

productsというviewがjoinされており、そのviewにbrandというディメンションが定義されているため、このような記述になります。

events

product_viewedというviewがjoinされており、そのviewにbrandというディメンションが定義されているため、このような記述になります。

ユーザーにユーザー属性を設定

Modelファイルにアクセスフィルターの記述が完了したので、いよいよアクセスフィルターを実行したいユーザーにユーザー属性を設定します。

Adminメニューのユーザー設定画面から設定したいユーザーの設定画面に移動します。

画面下部のUser Attributesでユーザー属性とその値を設定します。

確認してみる

フィルタは何も指定しないのに、明らかにデータがフィルタリングされているのがわかります。

クエリを確認してみる

あるグラフのexploreを確認してみます。

フィルタは何もありませんが…

クエリを確認すると、WHERE句に、先程設定したユーザー属性の値がフィルタとして指定されています。

このようにアクセスフィルターを設定すると、そのユーザーがダッシュボードを見た時、裏側でクエリにWHERE句の条件指定が強制的に入る仕組みになっている…というわけですね。ユーザー属性の設定でを既定値にしたのは、ユーザー属性を明示的に指定しないユーザーは、WHERE句のLIKEで全値が指定される(=フィルタされない)ようにするためです(は「0文字以上の任意の文字列」)。

おわりに

Lookerでユーザー毎に自動でフィルタをかける方法をやってみました。

今回はユーザー毎に指定しましたが、もちろんグループ毎にもユーザー属性を指定することができます。各部署毎にグループを作っておけば、「営業部グループのユーザーは、このダッシュボードを見た時、営業部のデータしか見られないようにする」といったことも可能です。

また、ちょっと別の要素も絡むのですが、ダッシュボードを外部サイト(自社の会員サイトなど)に埋め込んだ時に、ログインしたユーザーに応じてダッシュボードに表示させるデータを出し分ける…といったことも可能です(埋め込みについては、別エントリで触れたいと思います)。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.