明示的なリフティング (Explicit Lifting)

明示的なリフティング (Explicit Lifting) は、GoodData の Extensible Analytics Engine の機能です。レポート内でメトリックを集約する際に高い柔軟性を与えます。

下の論理データモデル (LDM) の図では、SELECT SUM(Value) などの Value (値) ファクトで集約されたメトリックは、赤で示す属性のいずれでも集約できます。これらは、Value をポイントする矢印を持っていることに注目してください。

明示的なリフティングにより、BY キーワードを用いて集約のグレインに対してトラバースし、このままでは特定のメトリックをスライスすることができない属性で、集約レベルをロックできます。

同じ LDM の次の例では、Shop_ID (ショップ ID) は Number of Residents (居住者数) ファクトには無関係であるように見えるにも関わらず、明示的なリフティングにより、Shop_ID で Number of Residents メトリックをスライスすることができます。

この集約については、下の例 1 でより詳しく説明します。

例 1 - 集約レベルを1つリフティングする

次のメトリックは、町の合計居住者数を表しています。

SELECT SUM(Number of Residents)

このプロジェクトの LDM (下図) では、Number of Residents メトリックは、町 (Town_ID) または郡 (County) でスライスできます。

その結果のレポートは次のようになります。

明示的なリフティングにより、メトリックの基本的なファクトに直接関係ない他の属性により、メトリックをスライスすることができます。たとえば、Number of Residents メトリックを Shop_ID でスライスするように定義を変更できます。

SELECT SUM(Number of Residents) BY Shop_ID

このレポートでは、各ショップが所在する町の Number of Residents が示されています。このメトリックは、Town_ID レベルで集約されています。

これで、Number of Residents メトリックを、各ショップの粗収益を表すメトリック (Shop_ID レベルで集約された取引合計額) を並べて比較できるようになります。

粗収益を計算するために、次のメトリックを作成します。

SELECT SUM(Value)

粒度のより大きい関連する属性 (上記の最初の図の赤で示されている属性) をレポートレベルで追加すれば、これらの属性でこのメトリックを内訳することができます。

たとえば、レポートに属性 County、Town_ID、Shop_ID を追加します。こうすることで、ショップが所在する町の居住者数と各ショットップの粗収益の間の相関を求めることができます。

例 2 - 複数レベルを超えてリフティングする

例 1 と同じ LDM を用いて、高収益のショップを運営しているマネージャーを調べることができます。これには、各ショップのマネージャーに関連付けられた合計取引額を計算します。

この Manager (マネージャー) は、LDM の Value ファクトとは無関係です。明示的なリフティングを行うことで、Value を Shop_ID レベルで集約し、これらの値を Records of Employee (従業員の記録) レベルで集約するように指定できます。こうすることで、Records of Employee に関係する Manager 属性でスライスできるようになります。

最初に、各ショップレベルで個々の取引の Value (値) を集約するメトリックを書きます。このメトリックは、各ショップでの全取引の合計値を計算します。

SELECT SUM(Value) BY Shop_ID

次に、これらの値を Records of Employee (従業員の記録) レベルで集約します。

SELECT ((SELECT SUM(Value) BY Shop_ID)) BY Records of Employee

最後に、MAX 集約関数を追加して、このメトリックを Manager (マネージャー) レベルにロールアップします。

SELECT MAX(( SELECT (( SELECT SUM(Value) BY Shop_ID)) BY Records of Employee))

SUM の周囲に SELECT をネストすることにより、カウントの重複を防ぎます (Manager と Shop の間に 1:1 の関係があると仮定しています)。MAX ではなく、SUM で集約すると、マネージャーとショップに割り当てられている従業員数を各値に掛けることになります。

1 人のマネージャーが複数のショップを管理している場合、このネスト型のメトリックは値を重複してカウントします。これは、M:N の関係でよく起こる問題です。

この結果、レポートには、個別の取引額を集約したもの、つまり取引による合計収益がショップマネージャーごとにスライスされて表示されます。

高収益ショップのマネージャーと各マネージャーのショップでの粗収益を調べるには、別の視覚化に切り替えます。

例 3 - 高度な明示的リフティング

顧客が最初に購入してから 2 回目の購入に至るまでの平均経過時間も計算することができます。

明示的リフティングを用いて、BY キーワードにより個別の取引レベルで Transaction Date (取引日) をロックします。次に、各購入者の取引日の差を計算します。これにより、各顧客の経過時間とともに、すべての購入者における取引間の平均経過時間が表示されます。

最初に、取引日数をカウントする必要があります。さまざまな取引の日付値を選択します。集約は不要です。

SELECT Date (Transaction Date) BY Records of Transaction

次に、取引日でリフトした元のメトリックを参照する 2 つのメトリックを作成します。

• 最初の購入日をフィルターするメトリック
• 2 番目の購入日をフィルターするメトリック

SELECT MAX(Transaction date lifted) WHERE Purchase Number = 1

SELECT MAX(Transaction date lifted) WHERE Purchase Number = 2

これらのメトリックは、MAX 関数でリフトされた取引日を集約し、購入回数でフィルターします。このようにする理由は次のとおりです。

• SUM は、Purchase Number (購入回数) = 2 に対応するデータの中で 1 つの値のみがあった場合に機能します。Purchase Number = 2 で複数の値がある場合には、メトリックは値を重複してカウントすることになります。
• AVG は、このメトリックの意図と類似しています。しかし、AVG は計算により長い時間がかかります。

最後に、2 つの購入日メトリックの間の差を計算するメトリックを作成します。これで、最後の結果をレポートレベルの属性である Shopper (購入者) で内訳することができます。

SELECT AVG(Second purchase date - First purchase date)

この結果、レポートは、最初の購入から 2 回目の購入までの時間を Shopper (購入者) 属性で内訳して表示します。

Total Value メトリックをこのレポート (SELECT SUM(Value)) に追加することにより、最初の購入から 2 回目の購入までの期間と支払合計額との間の相関を調べることができます。

すべての購入者にわたって、最初の購入から 2 回目の購入までの平均期間を求めるには、このメトリックを変更して、すべてのレポート属性を削除する必要があります。

SELECT AVG((SELECT Second purchase date - First purchase date BY Shopper))