Looker運用しはじめに起こりやすい数値ズレの事例について



当エントリは2020年アドベントカレンダー[『Looker Advent Calendar 2020』](https://qiita.com/advent-calendar/2020/looker)の14日目のエントリとなります。

今回は、LookerなどのBIツール運用時に案外起こりやすい数値ズレの事例と対応方法について紹介していきます。


## 表示値が誤った数字のまま運用されてたという事例

Lookerに限った話ではないですが、BIツールで表示される数字が間違っている。
ということは結構、起こりやすい事象ではないかと思われます。

一般的に、BIツールでデータを可視化するためには、

**１）データの収集：データ可視化用に必要なデータを各所から集めてくる**
**２）データの集約：収集したデータを加工し、必要な数字に整える**
**３）データの可視化：集約したデータを活用しグラフ情報に変換する**

といったステップを踏むことが多いと思いますが、この２）の集約の段階で、**個別の明細情報から取得したデータ**と、**日別サマリー情報から取得したデータ**を組みわせてデータを集約した場合に以下のような事象が起こる事があります。

- 商品区分毎のテーブル（前提として一人の顧客が同日に複数セットを購入することはできない商品とする）

| 日付 | 商品区分 | 購入者数 |
|:-------:|:-------:|:-------:|
| 12/14  | Aセット   | 100     | 
| 12/14  | Bセット   | 200     | 
| 12/14  | Cセット   | 300     | 

- 日別の顧客のアクセステーブル

| 日付 |  顧客数 |
|:-----:|:-----:|
| 12/14 | 1,500  |

上記２つのテーブルを日付をKEYにして集約した結果以下のようなテーブルが出来上がるとします。

| 日付 | 商品区分 | 購入者数 | 顧客数 |
|:------:|:-----:|:-------:|:-----:|
| 12/14  | Aセット  | 100    | 1,500  | 
| 12/14  | Bセット  | 200    | 1,500  | 
| 12/14  | Cセット  | 300    | 1,500  |

このテーブルから **日別の購入率＝購入者数／顧客数** を見たい場合に、LookMLで以下のようなコードを書くとします。

```sql

  measure: pay_uu {
    type: sum
    label: "購入者数"
    sql: ${TABLE}.pay_uu ;;
  }

  measure: access_uu {
    type: sum
    label: "顧客数"
    sql: ${TABLE}.access_uu ;;
  }

-- ↓　購入率を算出するための追加コード
  measure: pay_uu_rate {
    type: sum
    label: "購入率"
    sql:  pay_uu / access_uu ;;
  }

```

上記の結果から日別購入率を可視化すると以下のようになります。

| 日付 | 購入率
|:------:|:-----:|
| 12/14  | 0.13 |

#### →購入率が実態よりも低い状態で、報告＆運営され、後ほど間違ってることが発覚する。という悲しい事件に。


なぜこんな状態になっているのかというと、LookMLで計算された結果は以下のようになっています。

| 日付 |  購入者数 | 顧客数 | 購入率
|:------:|:-------:|:-----:|:-----:|
| 12/14  | 600    | 4,500  | 0.13 |

↓　上記の詳細な計算結果は以下のような感じ。

```
購入者数：　100名（Aセット） ＋ 200名(Bセット) ＋ 300名（Cセット） = 600名
顧客数：　1,500名（Aセット） ＋ 1,500名(Bセット) ＋ 1,500名（Cセット） = 4,500名
購入率： 600名 / 4,500名 = 0.13
```

#### 原因：顧客数がレコード数分だけ増えてしまって３倍になっていた。


#### この状態をLookML上のコードで対処する

```sql

  measure: pay_uu {
    type: sum
    label: "購入者数"
    sql: ${TABLE}.pay_uu ;;
  }

  measure: access_uu {
    type: sum
    label: "顧客数"
    sql: ${TABLE}.access_uu ;;
  }

-- ↓　購入率を算出するための追加コード(sqlの中でaccess_uuをAVGを利用して平均値にすることで整合性を保つ）
  measure: pay_uu_rate {
    type: sum
    label: "購入率"
    sql:  SUM(${TABLE}.pay_uu) / AVG(${TABLE}.access_uu) ;;
  }

```

これで正確な値が表示されました。

| 日付 | 購入率
|:------:|:-----:|
| 12/14  | 0.4 |

↓　上記の詳細な計算結果は以下のような感じ。

```
購入者数：　100名（Aセット） ＋ 200名(Bセット) ＋ 300名（Cセット） = 600名
顧客数：　平均(1,500名（Aセット） ＋ 1,500名(Bセット) ＋ 1,500名（Cセット）） = 1,500名
購入率： 600名 / 1,500名 = 0.4
```

今回の事象は業種に問わず、結構起こりがちな事象と思った為、紹介してみました。
（もし身に覚えのある方は是非LGTMお願いします。）


## あとがき

近年、どんな業種でもデータ可視化の需要が高まってきていると思います。それに伴って、**データガバナンス含めたデータ品質を高く保つためのテクニック**なども議論＆共有される機会が増えてきているように思います。コロナ化においてはリアルでそういった話をするのは難しいですが、代わりにウェビナーなどのイベントに参加することで、その辺りの情報も得やすくなってきているとも思われます。また、**データセキュリティの向上、品質を高める為の専門部署やチェック機構などの立ち上げ**をするところも徐々に増えつつあるのかな？と思います。

その一方で、そういった変化は勢いのあるベンチャーや大手IT＆WEB系企業、または経営側がデータを重要視しやすい企業（CTO、CAO、CIOなどがいる）に限られている場合も多いと思ってまして、データを専門で可視化するのは少人数のスペシャリストが対応するか、ビジネス側のメンバでデータに強い人が兼務で対応する方式で、徐々にデータ可視化が広まってきている。という側面もあると思います。

そういったデータ専門人材向け以外でも、役立つノウハウがググって見つけられるようになると、よりデータ可視化が良い方向に向かい、人々の需要が満たされ、社会も良い方向に向かっていけると良いなぁと思ったりしていますので、こういったアウトプット機会があればまた何かしらのノウハウ投稿していければと思います。