Lookerを用いた分析の標準化と効率化

Wantedly の BI チームでデータアナリストをしている奥山です。
最近 BI チームで取り組んだメール分析の標準化・効率化プロジェクトについて紹介します。

メール分析の標準化と効率化に関する問題

ここ数ヶ月で、複数のチームがグロースや新機能のコンセプト検証を目的としたメール施策を行っていました。Wantedly の開発チームでは、エンジニアは実装を行うだけでなく、施策の提案・実施・検証まで一貫して行う文化があり、各チーム内でメール施策の分析が行われていました。

この際に以下の問題が発生していました。

標準化の観点

指標の定義が明確に決められていなかったことで、分析時の指標の定義がチーム間で異なり、比較が困難であった
- 例: 「クリック数」の集計において、チームAではメール本文の会社ロゴのクリックを集計から除くが、チームBでは除いていない
- 例: チームAは「クリック率」を「クリック数 / 送信数」 として集計するが、チームBは「クリック数 / 開封数」 として集計する

効率化の観点

一部のチームでは BigQuery のビューを使って分析方法の標準化を進めたが、汎用性の高いビューの作成が進まず、施策ごとに大きめのクエリを調整・レビューするコストが発生していた
メール送信対象者をユーザセグメント別に分析したいが、クエリの作成に時間がかかっていた
- 例: 休眠期間ごとのクリック数の集計

これらの中でも、「比較が困難」であるとチーム間での知見の共有が進まず、施策の結果から学びを得る機会を損失してしまっていると考えたため、組織全体において特に重要な問題と捉えていました。

これらの問題を解決するため、BI チームが組織横断でメール分析の標準化と効率化を進めることにしました。

Looker を用いた課題解決

弊社では BI ツールとして Looker を用いています。Looker を用いた課題解決のイメージを Looker 内で用いられる言語である LookML の例を示して説明します。

Looker を用いた課題解決の流れ

BigQuery に格納されているメールのアクションログをもとに LookML でビューを作成し、標準化すべき指標を以下のように実装します。

# sent_mail_logs.view 内に実装
  measure: count {
    label: "メール送信数"
    type: count
  }

# click_mail_logs.view 内に実装
  measure: unique_click_mail_count {
    label: "メールクリック数"
    type: count_distinct
    sql: ${mail_log_id} ;;
  }

# sent_mail_logs.view 内に実装
  measure: unique_click_mail_count_per_count {
    label: "メール送信に対するクリック率"
    type: number
    sql: ${unique_click_mail_count} / ${count} ;;
  }

Explore を定義し、Explore 内にビュー間の関係性を記述します (主に SQL の JOIN 句に対応する処理です)

explore: sent_mail_logs {
  label: "Mails"
  join: click_mail_logs {
    relationship: one_to_many
    sql_on: ${sent_mail_logs.mail_log_id} = ${click_mail_logs.mail_log_id} ;;
  }
}

ここまでの実装で、Explore が利用できる状態になります。Explore は Looker のデータ探索のベースとなる画面で、定義済みのディメンション、メジャーを選択すると SQL が発行され、集計を行うことができます。(参考: https://docs.looker.com/ja/exploring-data/exploring-data)

データ分析者はクエリを書くのではなく、Explore を用いることで、誰もが同じ定義で分析できるようになり、標準化することができます。

以降ではこの Explore を用いた課題解決事例を3つ紹介します。

1. クリック数の集計方法の標準化

まず冒頭で述べた、

「クリック数」の集計において、チームAではメール本文の会社ロゴのクリックを集計から除くが、チームBでは除いていない

の解決手段について紹介します。

Click Filter というフィルタを定義し、以下のように設定値ごとにクリック数の集計方法を切り替えられるようにしました。

Standard: 標準的な集計。会社ロゴのクリックをクリック数の集計から除外する (デフォルト値)
Any: あらゆるクリックをクリック数として集計する

Any に関しては、目的によってはロゴのクリックを取得したいケースがあるため、切り替えの選択肢として提供することで、特殊な用途の場合にも Looker 上で分析が完結するよう意識しました。

2. 休眠ユーザの分析

メール送信対象者をユーザセグメント別に分析したいが、クエリの作成に時間がかかっていた

の解決手段について紹介します。

メール受信ユーザの休眠期間を任意の日数 (上図では30日) ごとに分割してそれぞれの指標を確認できるようにしています。休眠期間別の分析はクエリが複雑になりがちなため、Looker 上で行えるようになることで効率性に関してインパクトがありました。

Looker は LookML が実装されていないと分析できず、LookML を書けるようになるには学習コストがかかるため、Explore で分析ができない場合に LookML 実装を追加するのではなく、BigQuery 上でクエリを作成・実行するといったことが発生しがちです。そのため、休眠期間別の分析をしたいといった利用者が重視するようなユースケースを事前にヒアリングして把握し、Looker だけで分析が完結することを意識しました。

3. アドホックなユーザセグメントの分析

休眠ユーザの分析に関連して、よりアドホックなユースケースにも答えられるようにしました。メール施策によっては、「このセグメントはこの施策の分析以外では使わなそうなので、LookML を実装するほどではない」といったことがあり、このユースケースに対応できるようにしました。

例として user_id が奇数のユーザ群と偶数のユーザ群のメール指標を比較するケースを紹介します。

user_id が奇数か偶数かの情報を付与したビュー (segment_views.example) を以下のクエリで BigQuery 内に作成します。

SELECT
  id,
  IF(MOD(id, 2) = 1, "odd", "even") AS segment
FROM
  `users`

データセット名・テーブル名を Explore 上で指定することで、このビューに対応する (LookML としての) ビューが Explore 内で結合され、上の画像の出力が得られます。

Looker の特性上アドホックな分析が難しいのは一般的によく言われている気がしています (前述の通り、LookML が実装されていないと分析できないため) が、ここで述べた実装により、アドホックな分析も Looker 上で行えるようになりました。この手段によって、BI チームの工数を取ることなく、開発チームだけで SQL を書いてビューを追加し、アドホックな分析が行えるようになったため、弊社の組織構造の観点からも効果の大きい取り組みであったと感じています。