データ活用視点に立つ「指標」のエンジニアリング〜DataOps Night#1 登壇後記〜

データサイエンスグループでエンジニアやっています竹野です。本日は先日登壇したDataOps Nightについて参加報告させていただきます。

DataOps Nightについて

finatext.connpass.com

「データガバナンス」や「アナリティクスエンジニアリング」、「DataOps」といったキーワードは近年注目の大きい分野となり、イベントも盛んに行われるようになりました。

DataOps Nightもその一つで、そのテーマに「データ品質の向上に取り組むエンジニアを集めて知見を共有する勉強会」を掲げています。データを溜めるだけではなく活用するところにまで踏み込んでいくためには、解決すべき問題が数多く存在しています。

この知見を共有しようというのがこの勉強会の主旨です。

登壇するにあたってお声がかかった際に悩んだのは、私自身はモデル開発や施策レポーティングといった形でデータ活用側に属していることもありデータエンジニアリングをDataOps Night において話すべきか、という点でそういう人がいても面白いだろうということで登壇させていただきました。本発表がコミュニティでのひとつの題材になれれば幸いです。

この記事ではこの参加後記として、発表に対するモチベーションと資料最後のプラクティスについて解説します。

発表に関する解説と補足

「指標」を支えるエンジニアリング: DataOpsNight #1 from 株式会社MonotaRO Tech Team

www.slideshare.net

「指標」の一元化は難しい

推薦システムの開発を活動を普段の生業としている私ですが、データ活用側の視点に立ってデータ整備について考えてみると「指標」というものの「再利用の難しさ」によくぶつかります。「同じ指標なのに人やシステムによって出し方が異なる」といった問題はデータ活用を考える組織では必ずぶち当たる問題ですが、実は根本解決の難しい問題です。

私のモチベーションはここにあって本発表は「指標がなぜ再利用が難しいのか」について焦点を当てて発表に臨みました。

「指標がなぜ再利用が難しいのか」という理由は単純で「用途」や「計測の目的」、「目的達成のための方法・手段」が異なれば必要な計測の仕方が変わり、指標の定義も大きく変わるためです。指標の「利用者」はこれらの要素を念頭に、指標が自身の目的を達するに足るものか判断する必要があります。

例えばCTRやCVRといった単純で主要な指標でも、どのようなユースケースで用いられるかによって集計方法が大きく変わります。

計測の目的:
- 指標の単位となる分析ユニットは何か: ユーザ、訪問
- イベントの定義: 例えばクリックにページ遷移しないクリックを含むかどうか
- 計測の対象のセグメントの定義
用途: この指標はどこで使われるか
- 施策用のABテストレポート
- チーム用のダッシュボード
- 社外提供用のBIサービス
目的達成のための方法・手段
- 異常なユーザ（ボット）に関する処理の仕方
- 指標自身の介入容易性 / 変化に対する検出力

指標を再利用するために「集計」されたファクトテーブルやワイドテーブルで提供されることは多いですが、集計は不可逆性が大きい操作です。これらのテーブルは利用者にとって一見便利ですが、この集計テーブルを意識するだけでは、上記の３項目への思慮がおざなりになり不適切な分析を招きます。

ファクトテーブルやワイドテーブルといった方法だけでは「指標」の背景にある「計測の要求や仮定」が満たせないことが多くあるのです。データ利用に対する成果物に責任をもつ立場としては、これは見過ごせない大きな問題です。

「指標」の再利用のためにできること

発表ではこの問題に対して次のプラクティスを提案をしています。

指標に関する標準化
オペレーショナルモデリングによるデータの整備

１つ目は、指標に関する標準化です。

「指標」に関しても、普段のソフトウェアと同様に開発が行えることが重要です。そのためには命名規則や共通して持つべきインタフェースと標準に従ったシステム、およびドキュメンテーションを行う必要があります。

「指標」自体は相対的に変化のしやすい代物であるからこそ、これらの整備によって基礎を作ることが重要になります。

２つ目のオペレーショナルモデリングによるデータの整備について

CTRやCVRなどに集計テーブルで提供された指標は不可逆性があり再利用しづらいものです。集計テーブルだけでは「どのようにそれが計算されたか」を知ることはできません。そして同じ指標名を用いていても、それが指す実態は取り組むプロジェクトによって異なります。例えば、検索やユーザの新規登録のそれぞれでCTRやCVRの意味合いは大きく異なるものです。

この問題を乗り越えるために、 BIに連携しやすい集計テーブルよりも、集計テーブル自身を作りやすいテーブルの存在が重要になります。前者をアナリティカルモデリングとすると、この考え方を「オペレーショナルモデリング」と呼び、最近注目されつつあります。¹

「指標」システムを開発していく上ではオペレーショナルモデリングについてファネルを定義するシグナルテーブルとエンティティテーブルという2種類の２つに分けて整理していくとよいと考えています。

シグナルテーブルとはユーザ行動ログなどのイベントテーブルに対して、指標の素となる要素を定義するテーブルです。CTRであればクリックやインプレッションの定義を定めるテーブルです。大事なポイントは、単一のイベントで定義するのではなくファネルとして定義することです。

例として、検索に関する指標に関しては次のようなSQLのシグナルテーブルを用意すると良いでしょう。

with signal as (
   select
       timestamp as triggerd_at
       , user_id
       , case 
           when /* 検索セッション外のセッション定義  */ 
                  then ‘session__start’
           when /* 検索セッションのスタートシグナルの定義  */ 
                  then ‘search__start’
           when /* 検索セッションのclickシグナルの定義  */
                  then ‘search__click’
           when /* 検索セッションのconversionシグナルの定義 */ 
                  then search__conversion’
         end as signal_name
   from `project.dataset.events`
)

select * from signal

このようなテーブルを用意していれば、以下のようにCTRを簡潔に定義することができます。

大事なのは定義が簡潔になることによって、指標の集計の素となったテーブルが別の分析にも転用しやすい点にあります。例えばダッシュボードでCTR低下がわかった時に、どのチャネルやセグメントまたはファネルが原因で低下が起きているのか？といった一歩踏み込んだ調査がしやすくなるでしょう。

select 
  "検索" as metric_namespace
  , "CTR" as metric_name
  , countif(signal__name = "search__click") 
    / countif(signal__name = "search__start") 
      as metric_value
from signal