コミュニティフォーラム (Japanese)

ようこそLookerの日本語コミュニティへ!リリースノートやイベントのご案内などは「ニュースと告知」、Lookerの製品機能に関するちょっとした疑問・質問は「ヘルプとサポート」、その他TIPsやデータにまつわる話は「コラム」のカテゴリへご投稿ください。みなさまの投稿・コメント、心よりお待ちしています!

132 Topics

Looker アクション - Sendgrid

Looker アクション - Sendgrid 本記事は Looker Actions - Sendgrid 🇺🇸 の翻訳記事です Lookerは、Sendgridアクションを起動し、お客様がLookerからSendgridを介してデータをメールに送信できるようにします。 このアクションにより、Lookerのお客様は、1回のみまたはスケジュールに基づいて、Sendgridを介してLookerデータを電子メールに送信できます。 Sendgrid アクションの有効化 Note: Looker インスタンスが Looker 5.6 以上である必要があります. Lookerでアクションを有効にするには、管理パネルに移動し、プラットフォームヘッダーの下にある[アクション]タブ* [your-instance.looker.com/admin/actions] *。 (管理>プラットフォーム>アクション) Sendgridアクションで「有効」を選択します。 Sendgrid APIページで、webhookコネクターを使用してワークフローを作成します* * [https://app.sendgrid.com/guide/integrate/langs/nodejs#settings/api_keys]* (** Sendgrid->キーの作成->コピー**) Sendgrid APIキーをコピーして、Lookerアクションページに貼り付けます。 Sendgridワークフローにデータを送信 これで、LookerがSendgrid APISHと通信できるようにアクションを設定できました! レポートの作成と送信、スケジュール Lookerで、view a Look、explore dataまたはダッシュボードを表示でSendgridに送信するデータを表示します。 次に、今すぐデータを送信するまたは データをスケジュールする を選択すると、後にまたは定期的に送信されます。 送信またはスケジュール ウィンドウの 宛先 フィールドで, “Sendgrid”を選択します。 To フィールドで、データ受信者の電子メールアドレスを指定します。 オプションで 、From 、 ファイル名 、 件

Google Sheetsを使ってデータディクショナリーを生成する

本記事は Generating a Data Dictionary in Google Sheets 🇺🇸 の翻訳記事です なぜGoogle Sheetsを使ったデータディクショナリーが必要なのですか? Lookerを使うことで、より多くのユーザーがデータにアクセスしたり探索したりすることができるようになる一方で、多くのユーザーにとって、定義されたフィールドの意味や元になっているデータソースについてはわからなくなってしまうケースもあり、混乱して間違ったクエリーを発行してしまうことがあります。こうした混乱を防ぐ一つの方法として、Looker APIを使ってデータディクショナリーを定義し、Google Sheet上から簡単にアクセスできるフィールド情報を生成する方法があります。本記事ではその方法を記載します。以下のソリューションはview上で description パラメータをフィールドに定義している場合に特に便利です。 スクリプト このスクリプトは Apps Script と Javascript の組み合わせで記述されており、こちらのリポジトリーにリストアップされている関数を使っています。 本スクリプトを使用する際の注意事項は以下の通りです: model_name と explore_name は大文字小文字を区別する必要があります このスクリプトは、それぞれのViewの情報を独立したGoogle Sheetに作成します。それぞれのGoogle Sheetの名称はViewの名称となります(全ての情報を一つのシートに作成する場合は、以下の注を参照してその動作を強制する方法をご覧ください)。 このスクリプトでは、Exploreの各ビューへのGoogleシートマッピングを使用します。各Google Sheetには対応するビュー名が付けられ、そのビューに関連するデータのみがGoogle Sheetに表示されます。 また、このスクリプトはシートを開いた6時間後にAPIをコールしてアウトプットを出力します。 // ベースドメインをご自身のインスタンス名で置き換えてください var BASE_URL = 'https://instance_name.looker.com:19999/api/3.1'; // API認証情報を置き換えてくださ

Looker 7.0 リリースノート

リリース予定スケジュール リリース開始日: 2020/1/12 リリース完了およびダウンロード可能: 2020/1/23 ⚡ APAC地域のリリースタイミングについて、以下通り変更となりました⚡ 2020/1/30 10am - 12pm PST (日本時間 2020/1/31 3:00 am - 5:00 am) 過去のリリースノート レガシー機能の終了スケジュール 重要なお知らせ: オリジナルのリリースノート(英語版)は標準のLooker documentationにて掲載されます。以下リンクよりご参照ください。 Looker 7.0 Release Highlights Looker 7.0 Changelog その他日本語のLookerドキュメントリスト 本スレッドへのコメントは公式には追跡されないことにご注意ください。ヘルプ・リクエストや障害報告については、新規トピックを追加いただくかLooker Help Centerからご連絡ください。 リリース・ハイライト Marketplace (マーケットプレイス) IDEの改善 PDT再構築の拡張 System Activity ダッシュボードの拡張 ボード Descriptions Marketplace (マーケットプレイス) Marketplace (beta) Labs 機能がデフォルトで有効化されます。 マーケットプレイス上で、ユーザーが関連する有用なコンテンツを簡単に見つけられるようにします。Learn more Lookerユーザーは、マーケットプレイス上でLookerブロックス、アプリケーション、カスタムビジュアライゼーションなどのコンテンツを検索、インストール、およびアンインストールできます。今回のリリースでは、以下を公開しています Sales Application 23の Lookerブロックス 12の カスタムビジュアライゼーション IDEの改善 IDEのファイルとフォルダの一括編集、およびIDEのUIが以下の通り改善されました。 フォルダとファイルの一括移動および削除がすることが可能です Shift +クリックを使用して、IDEサイドバー内のフォルダまたはファイルの範囲を選択することが可能です 折りたたまれたフォルダーにフ

Chrome のカスタム検索でよく使うダッシュボードに即座にアクセス

些細なことだけど地味に便利、Lookerを使う上でのライフハックシリーズです。 普段みなさんがお使いのダッシュボードで、特定の製品、ブランド、顧客名などをフィルターで指定して利用するようなものはありませんか。 本記事ではGoogle Chromeのカスタム検索機能を使って、ブラウザの検索バーから一発で特定の条件でフィルターをかけたダッシュボードを開く方法をご紹介します。 ここでは弊社がデモでよく利用しているブランドアナリティクスのダッシュボードを例に挙げます。 こちらのダッシュボードは、フィルターで指定した特定のブランドについて各種数値を表示するものとなります。通常の使い方を想像すると ブラウザからLookerにアクセスする ブランドアナリティクスのダッシュボードを開く フィルターに特定のブランド名を指定する 実行(データ取得)する といったステップを踏む必要がありますが、今すぐある特定のブランドについての数字を見たい!や、いくつかブランドのフィルター条件を切り替えて見たい!といった場合、都度上記のステップを踏むのが煩わしく感じることはないでしょうか(私は感じる) そんなときは、Google Chromeのカスタム検索機能を使って、ブラウザから一発で特定のパラメータでフィルタをかけたダッシュボードを開けるようすると、作業時間を大幅に短縮することが可能です。 1. 該当のダッシュボードのURLをコピーする フィルターに適当な値を指定して実行し、URLを取得します。以下のように、フィルタに指定した文字列をパラメータに含むURLが取得できるかと思います。 ※ &filter_config 以降は不要 https://<LOOKER_HOST_NAME>/dashboards/6?ブランド=Lee&期間=90%20days 2. Chromeの設定で、検索エンジンに以下を追加する こちらはGoogle Chrome側の設定となりますので、こちらを参照しながら以下のように検索エンジンを設定します。 Search Engine : 任意の名称(例:ダッシュボードの名前) Keyword : 任意のキーワード(例:"brand" などクイックに入力できるもの) URL with %s in place of query : 1でコピ

BigQuery Standard SQLで、ネストされたデータをモデリングする

本記事は Modeling nested data in Big Query Standard SQL 🇺🇸 の翻訳記事です。 Big Queryの標準SQL(Standard SQL Dialects)のリリースされ、LookMLでネストされたデータセットをモデル化することがはるかに簡単になりました。 ネストされたファイルと繰り返しファイルがBigQueryでどのように機能し、それらがなぜ重要なのかについての簡単な入門については、 ダニエルの投稿 をご覧ください(訳注:こちらはリンク切れです)。 また、こちらのリンクからGoogle Analytics PremiumとGA360用のBlocksを参照できます。こちらをご覧いただければ、以下に示すプラグ・アンド・プレイですぐに使えるLookMLのコンセプトがよく理解できると思います。 以下に示す例は、ネストされた繰り返しフィールドを多用するGoogle Analytics Premium(GAP)をBig Queryにエクスポートしたデータセットに基づいています。 ネストされた繰り返しフィールド(例:STRUCTの配列)の結合ベースのクエリー、FLATTENSの置き換え Google Analytics Premiumスキーマには、セッションレベルのデータが格納されたテーブルが1つあり、個々のヒット(例えばイベント)レコードがそれぞれのセッション内にネストされています。ヒットレベルとセッションレベルのデータを同時にクエリする(たとえば、ヒットレベルとセッションレベルのデータを同時にカウントする(例えば、セッションの合計数とその時間内のヒット数の合計数)ために、これらの2つの異なるレベルのネストを参照するための新しい結合ベースの構文があります(ドキュメントはこちら )。 この構文を参考にし、モデルのセッションフィールドとヒットフィールドに個別のビューファイルを定義し、それらをExploreで結合します。 view: session { sql_table_name: `google.com:analytics-bigquery.LondonCycleHelmet.ga_sessions_*` ;; # このViewファイルにセッションに関連する全てのディメンションとメジャーを定

Create_Process を利用した PDT を単純増分する方法

本トピックは、How to: Simple incremental PDTs using create_process にて記載されていた内容を、翻訳・加筆したものになります。 テーブルのDROP and CREATE を毎晩実施するよりも、PDTに対してデータを増分追加したくなることがあるでしょう。 Lookerには、crate_process を利用して上記を達成することが可能です。以下に例を記載しますので、皆さんの参考になれば幸いです。 私が増分追加しようとしているテーブルは非常にシンプルなものです。1つのテーブル(基準に適合する)から行を引き出し、それらを少し修正してから別のテーブルに挿入しますが、より複雑なプロセスにおいても、同じソリューションを適用できると思います。 まず最初に、増分追加させたいテーブルをDWH上(PDTを作成するのと同じスキーマ・データセット)に作成する必要があります。ここでは、DDL文については言及しません。 また、Lookerが利用しているデータベースのコネクションに対して、SELECT と INSERT 権限が対象テーブルに対して必要になります。 LookML上で、以下のようなviewを作成します。 view: incremental_table { derived_table: { create_process: { sql_step: CREATE TABLE ${SQL_TABLE_NAME} AS ( SELECT DISTINCT col1, col2, col3, tstamp FROM existing_table AS e -- Only select new rows WHERE e.tstamp > (SELECT MAX(tstamp) FROM schema.incremental_table_name);; sql_step: INSERT INTO schema.incremental_table_name SELECT * FROM ${SQL_TABLE_NAME} -- Op

BigQuery のワイルドカードテーブルを1つのViewを通して検索する方法

BigQueryでは、以下のようなSuffix(接尾辞)付きのワイルドカードテーブルを、ワイルドカードを使って検索することが可能です。 テーブル例 log_table_20190101 log_table_20190102 log_table_20190103 ・・・ SQL例 SELECT * FROM `<project-id>.<dataset-id>.log_table_*` これらのテーブルに対して、Lookerにてcreate view from tableを行ってしまうと、log_table_20190101、log_table_20190102、log_table_20190103、・・・といった対となるViewがそれぞれ作成されてしまいます。このままでは、各テーブルにまたがった集計を行うのがとても不便です。そこで、これらのテーブルを一つのViewを通して一貫的に検索できるようにするためには、ViewおよびExploreにて行う必要があります。 まず以下の例のようにViewを記述する必要があります。_TABLE_SUFFIXをディメンションとして登録することで、WHERE句で適用可能な疑似列として利用できるようになります。 view: log_table { sql_table_name: `<dataset-id>.log_table_*` ;; dimension_group: partition { type: time sql: TIMESTAMP(PARSE_DATE('%Y%m%d', REGEXP_EXTRACT(_TABLE_SUFFIX,r'\d\d\d\d\d\d\d\d'))) ;; } 以下、必要なDimension, Measureを定義してください。 ・・・ } 次に、このViewを通してデータを探索するためには、以下の例のようにモデルでExploreを設定します。この時に、日付で検索対象のテーブルを絞り込まれるようにするために、connditionally_filterを使用しています。これにより、where句で_TABLE_SUFFIXを対して強制的にフィルターされるようになり、適切なパーティションフィルタリングが行われます。 explore:

アグリゲートアウェアネスによるパフォーマンス改善

本トピックは、弊社のHelpに記載のAggregate Awareness using _in_queryを翻訳したものになります。 Liquid attribute の _in_query を利用することで、Exploreでユーザがどのフィールドを選択し、SQLを動的に変更することが可能になります。これにより、多くの潜在的なユースケースが考えられます。この記事では、データベースリソースの消費を削減することで合理的にパフォーマンスを向上させる「アグリゲート・アウェアネス」と呼ばれる概念に焦点を当てています。 Lookerの多くのお客様は、イベントレベルまたはトランザクションレベルで非常に大量の詳細なデータをレポーティングしています。これは、個々のレコードの調査など、特定のシナリオには役立ちますが、基本的な統計だけが必要な場合、詳細なデータのクエリには多大なコストがかかります。 一般的な解決策は、これらのユースケース用に、より集約されたテーブルを作成することです。この場合、クエリのコストは低くなりますが、それぞれ独自のエクスプローラを利用する必要があります。そして、エンドユーザーが利用すべき最適なエクスプローラを知らない状況が発生する可能性があります。 _in_queryを利用することにより、一つのExploreだけを利用して、最適な集約データへのルーティングを行うことが可能になり、この問題を解決することができます。これは、基本的な統計に対しての問合せ時間を減らすことが可能です。 サンプル これは、LookerのLiquid variable ドキュメントにて提供されているものに近い基本的な利用例です: view: orders { sql_table_name: {% if orders.created_date._in_query %} orders {% elsif orders.created_week._in_query %} orders_smry_week {% elsif orders.created_month._in_query %} orders_smry_month {% else %} orders_smry_year {% endif %} ;;

Looker 6.24 リリースノート

リリース予定スケジュール リリース開始日: 2019/11/10 リリース完了およびダウンロード可能: 2019/11/21 すべてのリリースノート 6 レガシー機能の終了スケジュール 重要なお知らせ: オリジナルリリースノート(英語版)のDiscourseへの掲載は今回のリリースが最後となります。今後リリースノートにつきましては標準のLooker documentationにて掲載されます。 尚、日本語翻訳版に付きましては引き続きDiscourseに掲載する予定です。 🇺🇸 Release Notes in English 🇺🇸 日本語のLookerドキュメントリスト 本スレッドへのコメントは公式には追跡されないことにご注意ください。ヘルプ・リクエストや障害報告については、新規トピックを追加いただくかLooker Help Centerからご連絡ください。 リリース・ハイライト 一般的な改修と機能強化に加えて、このリリースには次のカテゴリの新機能と機能改良が含まれます。詳細については以下を参照ください Labs機能として、Slack Appを導入 Labs機能として、新しいダッシュボードエクスペリエンスを導入 Labs機能として、キュレーション検索を導入 ClickhouseのDialectサポート Snowflake接続におけるOAuthサポート リリース準備 ⚡ が付いている項目は、既存の機能への変更を示しているので注意が必要です。 詳細については、以下の「従来の機能の更新と機能別のセクション」を参照してください。 Labs機能のキュレート検索はデフォルトで有効化されます Table-nextはLabsのベータからはなくなり、デフォルトで利用可能な機能となります アラートはLabsのベータからはなくなり、デフォルトで利用可能な機能となります API 3.0および3.1のエンドポイントにおける修正と拡張 ベータ及び実験的Labs機能 ⚗マークが付与されたベータ及び実験的機能 は、新規追加及び改良されています。 新しいSlack App 新しいキュレーション検索 新しいダッシュボードエクスペリエンス 注目機能 Slack App &#x2

テーブル計算を使った小計の計算方法

本記事は Subtotals with Table Calculations 🇺🇸 の翻訳記事です。 本記事はLookerの標準のテーブル計算機能を使って小計を算出する方法を紹介しています。Looker 6.10 では、テーブルネクストが追加されており、これを使うと小計がネイティブに算出できるようになります。より詳しい情報についてはこちらのドキュメントを参照してください。 小計(subtotal)はグループ分けされた項目の合計を手早く確認するのに使われ、例えば、全体の合計の売上数値を見つつ、同時にブランド別の売上の小計なども参照する、というようなケースで便利です。本記事ではこの実現方法についての手順をご紹介します。 これは暫定的なやり方になりますので、こちらのコミュニティーに投稿されている優れたクロス結合による小計(Subtotals with a CROSS JOIN)パターンも参照してください。より柔軟な魔法のようなやり方を学ぶことができます。 例 下記画像のような例を使って考えてみます。いくつかのブランドがあって、その中にカテゴリーとメジャーがあり、売上合計または利益が算出できるものとします。これを今回のデータセットとして考えます。 さて、ここで、例えばブランドマネジャーがブランド毎の売上合計がどのくらいなのか、つまりそれぞれのブランドの小計が欲しいというケースを考えます。 テーブル計算を使うと、それぞれのブランドの最後の行と同じ行に4つ目の列を生成することができます。 これをやってみましょう。非常にシンプルなやり方です。 方法 ステップ1 テーブル計算を作成して、それぞれのブランド毎に行番号を表示させます。 この番号はブランドが変わるたびに 1,2,3... のようにカウントしていきます。 テーブル計算は次のように書きます。 if(match(${products.brand},${products.brand})=offset(match(${products.brand},${products.brand}),-1) , 1+row()-match(${products.brand},${products.brand}) , 1) ここでは match() を使ってそれぞれのブランドが最初に登場するユニ

System Activityで見えること

こんにちは。LookerAdvent Calendar15日目の記事として「System Activity」について少し掘り下げて書いて見ようと思います 。 1. System Activityとは Lookerは、インストールされているインスタンスに関する使用状況やパフォーマンス情報等を保持しています。System Activityは、Labsの機能ですが有効にするとそれらの情報をダッシュボードやExploreで閲覧することができるようになります。 System Activity 2.誰がアクセスできるの? Lookerの管理者および、「see_system_activity」パーミッションが与えられているユーザーが利用可能です。(Permission Listについてはこちら) 3. 有効化方法 Lookerの[管理]メニュー内の[Labs]の中の[System Activity Model]をONにします。 Lookerの画面を更新すると、管理メニュー内に[System Activity] メニューが表示されるようになります。 4. User Activityで見えること ユーザーの利用状況に関する情報を確認することが出来ます。 例えば、以下の数値が確認出来ます。 ユーザーアカウントと利用状況 各種ユーザー数 どんな権限のユーザーがどのくらいいるかを確認出来ます。 ユーザー数合計、管理者/開発者、コンテンツ制作者、データコンシューマ(閲覧者)、埋め込みコンテンツ制作者、アクティブユーザーの割合(過去7日間にクエリかけたことある人/全ユーザー) クエリーユーザー数:過去6週間の、週次のクエリ実行者数です。 ユーザー別エンゲージメント 過去6週間の、週次のユーザーあたりの平均利用時間(クエリ実行時間から推測)と平均クエリ実行数 グループ別のクエリ実行者数(過去7日) 過去7日以内で実行した人、していない人の人数をグループ別に。 日別のクエリソース別の実行者数(過去7日) Dashboard、Explore、API、スケジュールタスク等のクエリソース別の実行者数 ユーザーに関する詳細 トップユーザー 過去7日以内の利用時間(クエリ実行時間から推測)のトップ10ユーザー トップダッシュボード構築者 過去7日以内に

Looker Git Repository 移行手順

本記事では、既にGitリポジトリに接続しているLookMLプロジェクトを、別のリポジトリに移行したい場合の手順を紹介します。 方法としては、Masterブランチの履歴を保持するパターン(シンプル)と、すべてのブランチを保持するパターン(ちょっと大変)の2つがあります。 本記事の内容は、Help Centerに記載の内容を翻訳したものとなります。最新の情報については、Help Centerの記事を参照してください。 Simple Solution: Masterブランチの履歴を保持 Git connectionをリセットし、新しいGit URLを登録すると、LookMLは新しいリポジトリへ移行されます。以下の手順を参照ください。 該当プロジェクトのプロジェクト設定ページへ移動します。 プロジェクト設定ページにて、Reset Git Connection ボタンをクリックします Gitの設定画面において、新しいGit URL(移行先として利用したいGit URL)を入力し、Continue ボタンをクリックします。 接続にSSHを利用している場合は、 Reset Key ボタンを確実にクリックして下さい。そうでない場合、同じSSHキーが利用され、両方のリポジトリが同じサービス(i.e., Github)で利用されている場合、コンフリクトが発生する可能性があります。 SSHコネクションにおいて、リポジトリに新しいdeploy keywoを追加し、Write Accessを付与するのを忘れないようにしてください。HTTPSを利用している場合、Gitリポジトリに対するログイン・クレデンシャルを入力します。(Gitの設定に関する詳細は このページを参照してください)。. 以上で、プロジェクトは新しいリポジトリに接続されます。 Advanced Solution: すべてのブランチの保持 上記の手順では、マスターブランチと、ログインして操作した開発者のブランチの履歴のみが保持されます。すべてのブランチとその履歴を保存するには、より複雑なプロセスが必要です。 最初に、自身でリポジトリを保有する必要があります。プロジェクト設定ページにの下部にURLが記載されています。URLがlloker/始まる場合、Lookerがホスティングしているものになります。

Firebase Blocks v3 (日本語翻訳記事)

本記事は github で提供されている Firebase Blocks 🇺🇸の Readme の翻訳です。 この block の役割 BigQueryにあるFirebaseデータには大きな分析ポテンシャルがありますが、クエリーできるようにするのは簡単ではありません。それは以下のような理由があります: 毎日新しいテーブルが(events_YYYYMMDDという名前で)作成されてしまうため。これによりBigQueryのコストは下がりますが、クエリーがより複雑になってしまいます。 どの event_name も、 event_params.key や event_params.value のようなネストされた Key-Value 型のペアになっており、クエリーするときに複雑な UNNEST 処理を行う必要があるためです。 user_properties も同様に Key-Value のペアになっていて何階層にもネストしているからです。 この block でできること 期間を選択して魔法のようにパーティションされたテーブルから必要なデータを選択できるネイティブな方法を生成します。 セッション化(Sessionization)を追加できます。(これはFirebaseデータにはありません) [訳注] 「セッション化」についてはこちらの記事も参考にしてください。 リテンションのコホート分析を追加できます。 event_name または event_params.key 、 user_properties の組み合わせのディメンションを作成できます。 データのモデリングを開始して価値を引き出すための最初のステップとして最適です。 仕組み どの Firebase スキーマも類似点は多いものの event type と user properties は異なるため、この block が event 構造に沿ったユニークなスキーマを生成します。Python notebook を使用して Looker API とご自身のデータベースに接続してLookMLを自動生成します。 利用方法 Looker側の準備 こちらの記事を参考にしてリポジトリーからクローンしてプロジェクトを新規作成します。 https://docs.looker

Lookerで始める機械学習

Looker Advent Calendar 2019 Day 8の投稿になります。 Lookerで始める機械学習ということで、Lookerを使って機械学習をする手順とそのメリットについてまとめていきたいなと思っています。 ##機械学習に必要なステップ 例えば、機械学習や統計解析などを使ってデータサイエンス的ななにかを行う場合、多くの場合以下のような手順で行います。 1. ローデータの収集 2. データのクレンジング 3. 検証したい仮説の実績データを取得 4. 統計/機械学習アルゴリズムを使用して予測の実施 5. 可視化やアラートなどを利用し、結果を共有 この手順にツールを追加すると・・・ 1. ローデータの収集 → ETLツール 2. データのクレンジング → ETLツール/SQL 3. 検証したい仮説の実績データを取得 → SQL 4. 統計/機械学習アルゴリズムを使用して予測の実施 → R/Python/各種機械学習サービス 5. 可視化やアラートなどを利用し、結果を共有 → BIツール データ活用を検討されている企業の場合、その多くはすでに1,2については安定した運用が行われているケースが多いですが、3以降ではそれぞれの手順で異なるツールやテクノロジーが必要とされるため、利用にあたり高いスキルが必要とされたり、運用管理が複雑になってしまいます。 しかし、Lookerではこの手順で必要とされるものをシンプルにして実行することを可能にします。 ##Lookerで実施する場合の手順 前述の通り、1,2に関してはすでに構築済みだと思いますので3からの手順に焦点を当てていきます。 ###3. 検証したい仮説の実績データを取得 機械学習を利用して様々な状況の予測を実施するためには、仮説を立て、仮説が正しいかデータをクエリし確認します。 通常、この手順では立てた仮説のもと実態の確認のためにデータを探索します。この際、多くのパターンの仮説検証を繰り返すために何度もSQLを書きます。これが地味に手間なのですが、LookerではExploreの画面から簡単にデータセットの中に自由にクエリをかけることができるため、思いつく限りの多くのパターンの仮説の検証が可能になります。 ###4. 統計/機械学習アルゴリズムを使用して予測の実施 3で検証したデータを元に予測をしていきま

salesforceをIdPにしてSAMLでSSOする方法

LookerはSAMLに対応しており、SP-initiatedでSSOすることが可能です。 今回は、SalesforceをIdPとして接続し、Lookerにログインするための設定手順を以下に示します。 まず、salesforceをIdPとして利用できるようにするために、salesforceにて以下の設定がまず必要です。salesforceのヘルプを参照して、設定してください。 A. 私のドメインを登録 B. IDプロバイダの有効化 こちらが完了していることを前提に、今回の目的のための設定手順を説明します。 手順 Salesforceの接続アプリケーションを登録 1.1 設定画面に移動し、ID -> IDプロバイダ へ移動する 1.2 画面上部にある”証明書のダウンロード”ボタンをクリックし、証明書をダウンロードする ※ Lookerでの設定に利用 1.3 画面下部にあるサービスプロバイダのセクションにあるリンクをクリック 1.4 表示された画面の項目に、以下のLookerのインスタンスに関する情報を入力し、保存する 接続アプリケーション名: 任意の名前 (例 Looker) API参照名: 任意の名前 (例 Looker) 取引先責任者メール: システム管理者のメールアドレス 開始URL: LookerインスタンスのURL (例 https://xyz.jp.looker.com/) SAMLの有効化:チェック入れる エンティティID:任意のFQDN形式の文字列 ※Lookerでも同じ文字列をセットする必要あり ACS URL:LookerインスタンスのURL + /samlcallback (例 https://xyz.jp.looker.com/samlcallback) 件名識別:統合ID 名前ID形式:urn:oasis:names:tc:SAML:2.0:nameid-format:transient 発行者:任意のFQDN形式の文字列 ※Lookerでも同じ文字列をセットする必要あり Idp証明書:デフォルトのIdP証明書 他の項目は空白のまま 1.5 保存後、以下の画面にて"Manageボタン"をクリック 1.6 画面が切り替わった後、画面下部にあるプロファイルにて、"プロファイルを管理する"ボタンをクリックする 1.7 Loo

「最新の」値だけをメジャーにする方法

この記事は、Only measuring the “latest” values🇺🇸 の翻訳記事です メジャーとは何か? 非常に多くのケースで、私たちは、自分自身に不必要な制約をかけてしまって、メジャーやメトリック、あるいは集約するということは、SQLで提供される基本的な集約であるSUM、COUNT、AVERAGE(あるいは方言がサポートされている場合はMEDIANも含む)のことであると考えてしまいます。 しかしここでちょっと立ち戻って、なんのメジャーが本質的なのかを考えてみましょう - 通常、あるグループやディメンションの中で、潜在的に多数の基礎データポイントを取得して、それらを利用可能なデータに凝縮するメジャーを選びましょう。数千の注文を集約する際は? メジャーには総売上が良いです。数百万のセッションでは? サイトの平均滞在時間が良さそうです。何百万人ものセグメントあたりユーザー数は? 訪問頻度のヒストグラムになります。多数のキャンペーンと、たくさんの日付、訪問データは? 直近30日間の訪問回数のスパークラインなど。 上記の例はちょっと言い過ぎかもしれませんが、要点はつまり、あなたの想像力が制約になっているということです。ここでは、最新のデータポイントのみを使用する必要があるデータを要約するときの簡単なメジャー使用方法を次に示します。例としては、在庫のスナップショットや、バランス・シート、タイムスタンプ付きの変更リストが与えられた属性の状態履歴などのデータです。 「最新の」メジャー 今、以下のような在庫のスナップショットデータで、日毎にそれぞれ在庫数を持っているとします。 INVENTORY_SNAPSHOT inventory_id | taken_at | amount ------------------------------------ 1 | 2018-01-01 | 17 2 | 2018-01-01 | 9 3 | 2018-01-01 | 29 1 | 2018-01-02 | 13 2 | 2018-01-02 | 37 3