1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

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

Last updated at Posted at 2020-12-13

当エントリは2020年アドベントカレンダー『Looker Advent Calendar 2020』の14日目のエントリとなります。

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

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

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

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

1)データの収集:データ可視化用に必要なデータを各所から集めてくる
2)データの集約:収集したデータを加工し、必要な数字に整える
3)データの可視化:集約したデータを活用しグラフ情報に変換する

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

  • 商品区分毎のテーブル(前提として一人の顧客が同日に複数セットを購入することはできない商品とする)
日付 商品区分 購入者数
12/14 Aセット 100
12/14 Bセット 200
12/14 Cセット 300
  • 日別の顧客のアクセステーブル
日付 顧客数
12/14 1,500

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

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

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


  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

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

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


  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などがいる)に限られている場合も多いと思ってまして、データを専門で可視化するのは少人数のスペシャリストが対応するか、ビジネス側のメンバでデータに強い人が兼務で対応する方式で、徐々にデータ可視化が広まってきている。という側面もあると思います。

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

1
0
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?