単一レポートで動的にフィルターした値を比較する
GoodData では、多くの場合、ユーザーはダッシュボードのフィルターを用いてレポートのデータを制限します。これにより、特定のカテゴリのデータが省略され、その他のデータがレポートの計算に含まれることになります。
このセクションでは、すべてのカテゴリに値が存在すること、一部のカテゴリを除外すること、ユーザーがダッシュボードフィルターを使って所定の期間で除外するカテゴリを動的に制御できることを前提条件として、メトリック値の比較を可能にするシナリオについて説明します。
単一のレポート内で、特定のセグメントに絞り込んだメトリック値と全セグメントにわたるメトリック値を比較します。たとえば、トレンドを示す単一の線グラフにおいて、1つの線が選択したセグメントの値を表し、もう1つの線が全セグメントの値を表すようにします。
このシナリオでは、ユーザーはダッシュボードフィルターを使用してセグメントを動的に選択できることが必須です。
たとえば、さまざまなマーケティングキャンペーンから得られる1日当たり平均見込み客数を追跡する場合、次の論理データモデルに変換されます。
ソリューション1:WITHOUT PARENT FILTER
要件からは、2つのメトリック、つまりCampaign フィルターで絞り込みができる Avg Daily Leads メトリックと絞り込み不可の Avg Daily Leads メトリックが必要だと思われます。この2つのメトリックを次のように定義します。
Average # Leads
SELECT AVG(# Leads)
Average # Leads (All Records)
SELECT AVG(# Leads) WITHOUT PARENT FILTER
WITHOUT PARENT FILTER 句により、これらのメトリックには、ダッシュボード、レポート、または外部のメトリックで定義されているいかなるフィルターも適用されなくなります。これで問題は解決しますが、望ましくない副作用もあります。つまり、ダッシュボードには、「部分」メトリックと「完全」メトリックの両方に影響を与えるその他のフィルター (典型的なのは日付フィルター) が含まれることがあります。過去30日間でのフィルターする場合、調べたいのは、全期間にわたる全見込み客数に対するキャンペーンの貢献度ではなく、過去30日間に創出された全見込み客数に対するキャンペーンの貢献度です。
ソリューション2:変数
GoodData ダッシュボードに設定できるフィルターのドロップダウンには、属性フィルター、日付フィルター、変数フィルターの3種類があります。ほとんどの場合、属性フィルターと日付フィルターしか使用しませんが、状況によっては変数フィルターが有用な場合もあります。
GoodData のフィルター済み変数は、その他のプロジェクトの属性の値をサブセットで絞り込んでから、その属性を複製したものです。言い換えると、フィルター済み変数は、式Attribute IN (Value1, Value2, …) のプレースホルダーです。
(GoodData は数値変数もサポートしますが、このケースでは関係ありません。)しかし、属性値を全くフィルターせずに属性を複製する変数を作成することも可能です。実際に、既定では、値を一切フィルターしないように設定されています。
フィルター済み変数を作成すると、(変数フィルターを通じて) 次のようなレポートとメトリックを定義できます。
SELECT AVG(# Leads) WHERE Campaign_Variable
ここで注意したいのは、Campaign_Variable を「属性値を一切フィルターしない」ように定義すると、上記のメトリックは、SELECT AVG(# Leads) メトリックと同じ結果を返すことです。しかし、Campaign_Variable ダッシュボードフィルターを用いて Campaign_Variable をその場ですぐに再定義すれば、元のメトリックを変更せずに、変数メトリックを効果的に操作できます。
変数は当初の目的をすべて満たすことができますが、欠点がないわけではありません。属性ダッシュボードフィルターは、カスケードの親子関係と相互接続できますが、変数フィルターをサポートしていません。プロジェクトにおいてカスケードのダッシュボードフィルターを優先すべき場合には、別のソリューションを探す必要があります。
ソリューション3:キャンペーンを間接的に接続する
最後のソリューションは、マニアックなデータ科学者が創り出したもののように思われるかもしれません (確かにそのとおりなのですが)。しかし、実際には、この方法はフィルターインジェクションを使ったクロスデータセットフィルタリングをかなり変わった形で応用したものに過ぎません。メインのデータセット (Daily Leads) と Campaign 属性を接続する関連データセット (別名: フェースレスファクトテーブル) に基づく COUNT サブメトリックを使用して、フィルター (リンク) をインジェクトするというアイデアをベースとしたものです。
つまり、モデルの変更が必要になります。
図を見ると、Campaign は Daily Leads から参照されなくなっていることがわかります。つまりこれは、Campaign ダッシュボードフィルターにより自動的に Daily Leads をフィルターすることのメリットが失われていることを意味しており、これこそが意図した動作です。
「部分」メトリックは、次のようになります。
SELECT AVG(# Leads)
WHERE (SELECT COUNT(Campaign Daily Leads Association)
BY Daily Leads, ALL OTHER) > 0
Campaign フィルターは COUNT サブメトリックに影響を与えます。このため、BY Daily Leads, ALL OTHER 部分により、COUNT サブメトリックが Daily Leads のすべてのレコードについて計算されるようにします。さらに、「ゼロよりも大きい」という条件により、Daily Leads のレコードのみを選択し、関連テーブルの1つ以上のレコードを通じて、これらが選択した Campaign に接続されるようにします。
Campaign を関連するデータセットに移動するのではなく、通常のスライスやフィルターで使用できるようにする場合は、モデルを変更せずに、ダッシュボードフィルターのみによって使用される複製属性を追加します。その場合、データモデルは次のようになります。
「部分」メトリックの定義は同じになります。
結論
変数を使用することにより、フィルターで選択した値とフィルターしない値を比較するダッシュボードを簡単に作成できます。変数により、全体メトリックをフィルターするのではなく、特定部分のメトリックにフィルター規則を直接適用することができるようになります。
関連テーブルを通じてメインのデータセットにフィルター属性を間接的に接続し、このフィルターを COUNT サブメトリックに適用することによっても、同じ結果が得られます。
WITHOUT PARENT FILTER 句を「全体」メトリックに追加する方法は、一番わかりやすい方法です。しかし、これは、「全体」メトリックに適用することの多いすべてのフィルター (日付フィルターなど) を除外してしまうため、実用的ではありません。