LookMLのさまざまなパラメータ設定 #1

Looker30日間無料で使えるみたいなのでたっぷり使い倒してみた！
の第三弾として、LookMLプロジェクト内で定義できるさまざまなパラメータの設定について、みていきたいと思います。

Contents

1 さまざまなフィルタについて
2 ユーザーによる入力まち
3 Fields
4 access_grantとrequired_access_grantsとallow_value
- 4.1 Viewに対して設定
5 ParameterパラメータとLiquid変数
6 ビューの結合
- 6.1 自己結合の場合
7 ビューの結合
8 sqlパラメータ
9 LookMLプロジェクト

さまざまなフィルタについて

項目	説明
sql_always_where	SQLでいうwhere句と同じ意味です。つまりLookerからデータをとってくる際にデータをしぼってLookerにとってきます。これはとってくる際に絞るので、Exploreでガリガリ分析する際にはそのデータの存在自体わからないということになります。
sql_always_having	SQLでいうhaving句と同じ意味です。つまりLookerからGroupByなどした上で条件を絞ってLookerにデータをとってくるときに使います。
always_filter	「いつもフィルタ」なので、常にどんなユーザーがExploreで分析をしたとしても必ずデフォルトでフィルタがかかっています。変更はできません。
conditionally_filter	「コンディションでのフィルタ」なので、上のalways_filterに比べれば優しいフィルタです。LookMLで指定したフィルタはかけないといけないが、そのフィルタの値指定はユーザー自身で決めることができるというものです。

ん？ようわからん！って文章を読んだだけではイメージしづらいですよね。
実際に適用して挙動を見てみましょう！

今、フィルタはBQ上にあるGA4のunnestテーブルを参照するための、日付のみフィルタをしており、event_name自体にフィルタはしていない状態です。この状態から上記のフィルタを施したときにどういう挙動になるか検証してみましょう！

sql_always_having

以下のように指定。

このとき、指定したディメンションとメジャメントの組み合わせてメジャメントのcountが20より大きいもののみにフィルタがかかって表示されています。
ダッシュボードではディメンションとメジャメントを指定することで、そのディメンションの組み合わせでSQLでいうGroup byをして集計をします。
その集計結果に対してフィルタをかけるのがSQLでいうhaving句になります。
なので、以下のように20よりも多いもののみに絞られて表示されるようになってるのが確認できます。

sql_always_where

以下のように指定してみます。

そうすると、event_nameがpage_viewだけに絞られて表示されました。
Lookerからデータを参照してくるときSQLを生成しとってくるのですが、そこにwhere event_name = "page_view"が入った状態でSQLを実行してとってくるようになるので、Exploreの画面のfiltersにはpage_viewで絞るというようなフィルタがないが、裏でそのフィルタがかかっている状態になります。
なので、ユーザーには別に必要のないデータについては見せないようにするなどの設定が可能になります。
（あるユーザーにはこのevent名だけを見せて、あるユーザーにはこのevent名だけというような指定もできます。）

always_filter


explore: search_data{

  sql_always_where: ${search_data.isbrowser} == 0;
  sql_always_having: ;;
  conditional_filter: {
    filters: [cabinclass: "BUSINESS"]
    filters: [origincountry: "日本以外"]
  }
  always_filter: {
    filters: [destinationcountry: "JP"]
  }

}

このように、フィルタに出てきて、必ずユーザーはevent_nameに対して何らかの値を指定してフィルタをかけないといけません。
このフィルタは削除することはできないので、何らかの値を指定する必要があります。
なのでevent_nameなんて知らない！ってなったら、運よく正規表現などで引っかかってデータ取得できるかもしれません。
ただデフォルトでpage_viewが入っているだけになります。

always_filterを設定してみました。
このときExploreを見ると、上で説明した通りフィルタが明示的にかかった状態になってますね。それもHTMLのdisabled状態になっており、一切ユーザーは変更ができません。
sql_always_whereではそもそもデータをとってくる際にデータを削ってるので表示されません。
でもalways_filterも同じような効果とは言いつつも、ユーザーにどんなフィルタで絞ってますと明示的に示せるところが違いますね。

以下のように×印がないので、フィルタを削除することはできません。
なので何かはフィルタで指定しないといけません。

conditional_filter

conditional_filterは以下のようにユーザーに変更を促すことができます。


explore: search_data{

  sql_always_where: ${search_data.isbrowser} == 0;
  sql_always_having: ;;
  conditional_filter: {
    filters: [cabinclass: "BUSINESS"]
    filters: [origincountry: "日本以外"]
  }
  always_filter: {
    filters: [destinationcountry: "JP"]
  }

}

さらに、フィルタの値何か指定しないとだけど、どんな値が入ってるかわからないから、何指定したらいいかわからん！ってこともあると思います。
そういうためにLookerユーザーに対してこういう値が入ってるなど明示的に知らせることができます。
それがドロップダウンです。
入力欄を選択状態にすることで、リストが表示されそこから選択して指定できます。

以下のようにフィルタがかかるが、×とあり、ユーザーへフィルタしてもいいんじゃない？？という提案をします。

ユーザーによる入力まち

Looker Studioでも近しい機能としてパラメータというものがありました。
Lookerにも同様のものがあり、それがLiquid変数というものです。

Fields

setは数学で集合といいます。
なので、複数のディメンションをまとめたい場合、setパラメータを使うことができます。

以下のように、除きたいディメンション名を指定する。(-view名.dimension名)。デフォルトがALL_FIELDS*なので、-view名.dimension名のみ指定すると、1つも表示されなくなってしまうことに注意。(指定しているのでデフォルトで無くなってしまうため。)
必ず、ALL_FIELDS*も指定した上で、覗きたいディメンションを記載していったり、覗きたいディメンションを別のところで集合(set)として定義しつつ、指定する。

デフォルトでは、Viewに指定されているディメンションやメジャメントが一覧で表示されます。

ただ、ダッシュボードの作成では使わせたくないディメンションなどをExploreのFieldsパラメータで除外するなどの設定が可能です。
デフォルトでは、
Explore内でfieldsパラメータにはALL_FIELDS*が指定されています。

fields: [ALL_FIELDS*]

これは、そのView内での全てのdimensionを意味します。

ここで、
fields: [ALL_FIELDS*, -ga4_unnest.event_name, -ga4_unnest.campaign]
と指定することで、-(マイナス)つまり全体のdimensionから、ga4_unnestというViewのevent_nameディメンションを除外するということになります。

以下のように、Exploreの画面では、確かにga4_unnestのviewから、event_name(イベント名)と、campaign(キャンペーン)が除外されているのがわかります。

ちなみに、上では2つのディメンションを除く処理をしました。
1つずつ指定するのが面倒なので、数学で言う集合(set)の概念を考えて、
以下のように指定も可能です。

access_grantとrequired_access_grantsとallow_value

access_grantやrequired_access_grantsとallow_valueは、ディメンション1つ1つに対してユーザーがアクセスできるかを指定するものなので、Explore側での設定ではなく、dimension1つ1つに設定をしていくパラメータになります。
access_grantは1つ
required_access_grantsは複数形なので、色々？

required_access_grantsは、Exploreに指定できるもので、
Explore自体にアクセスできるユーザーを指定できます。

access_grantは、そのユーザーを指定するものになります。
なので、required_access_grantsとaccess_grantはセットで使うことになります。

required_access_grants: [user_attribute_value]

access_grant: user_attribute_value {
user_attribute: "country"
allowed_value: ["japan"]
}

今の僕のUser Attributeを確認すると以下のようになっており、User Attributeは自分で作成することもできます。
1つカスタムでUser Attributeを「country」という名前で作成し、この属性値によってユーザーのアクセス制御をかけてみます。
自分に「japan」という属性値を与えてみます。

そして、Exploreに以下のように
required_access_grantsとaccess_grantパラメータを指定します。
挙動としては、ユーザー属性「country」でその値が「japan」のユーザーのみ、Explore「ga4_unnest」へアクセスできるようになります。

実際に今は、japanという値なので、Exploreでga4_unnestへのアクセスができます。

では、以下のように属性「country」の属性値を「united_states」にしてみます。

出てきません。アクセス制限をかけることがうまくいってそうですね！

このように、required_access_grantsとaccess_grantを用いることで、Exploreへのアクセス制限を細かくかけることができました！
もちろんrequired_access_grantsは名前にsがつくのと、配列指定なので、複数のaccess_grantを指定することができます。
access_grantのallowed_valueも配列なので、1つの属性に対して複数の属性値を指定することもできます。
が、required_access_grantsに複数指定した場合、「または」ではなく「かつ」になることに注意。他の属性の人に見せたくないのに、ある属性はダメだけど他の属性で条件満たしてたら意味がないから。

さらには、viewの各dimensionにもrequired_access_grantsとaccess_grantを指定することができます！
Explore単位だけではなく、dimension単位までユーザーの属性値によってアクセスできるものを制限かけることができるのは、Lookerの魅力と言えるのかもしれません！

ここで、要注意としては、
指定するuser_attributeは、管理者以外のユーザーが属性値を変更できないようにする必要があります。
自分自身で変更をしたりして、もしかしたらアクセスできてしまう可能性があるためです。
実際、属性値をユーザー自身で変更できてしまう属性をuser_attributeに指定すると、以下のようなエラーが表示されます。
「access_grant "user_attribute_name" でユーザが編集可能な属性 "country" を使用できません。」

なので、User Attributesの設定から、以下の箇所でnoneにして編集できないようにしましょう！そうすることで、user_attributeで指定できるようになります。