はじめに
every Tech Blog Advent Calendar 2023 24日目の記事になります。
DELISH KITCHENでデータサイエンティストをしている山西です。
普段はDELISH KITCHENの企画/改善に向けた分析をPdMと連携しながら行っています。
今回はその経験談をもとに、分析用ログ策定の流れを改善&仕組み化した事例をノウハウとして紹介したいと思います。
経緯: ログがカオス
DELISH KITCHENサービスの改善に向けた分析では、ユーザーのイベントログ(ユーザーがいつ、どこで、何を見たかの情報が含まれるもの)をデータとして利用しています。
これをSQL等の手段で集計し、分析を通して意思決定に向けた示唆が得られるような利活用をしています。
ところが、ログをいざ集計しようとなると困難に直面することが多々ありました。
これは、歴史的経緯から行き当たりばったりで設計されたものであったり、（データ利活用文化が発展途上だった頃）必ずしも分析観点で整理、設計がなされていなかったりしたことに起因します。
理想とする状態とのギャップをAs-Is/To-Beとして以下に整理しています。
| As-Is | To-Be |
|---|---|
| 必要なログが存在しない | 分析したい観点に必要なログが存在している |
| ログはあっても集計したいカラム、項目が足りない | 分析要件に応じて、必要な情報が発火されるようになっている |
| 使われていない&用途も不明なログが散見される | 必要の無いログは減らし、開発工数やコスト面での最適化を図る |
| 企画書&設計書を読んでも、どのイベントとログが対応しているかよくわからない | 関係者が齟齬なく解釈できるようなドキュメントとして整理されている |
| ログはあるものの、集計難易度が高い | 楽に集計できる（SQL習熟度が必ずしも高くないPdM、ビジネス層でも書けるくらいの難度感） |
ログ設計フローの見直し
このギャップを踏まえ、目指すべき状態(To-Be)に向けて分析ログ設計フローを整理し、PdMとともにこれに則って進行していくようにしました。
以下がその全体図です。
仮説を立てたうえで分析方針を決定し、その後に手段（ログ）を選定するという流れを意識しています。
※ログの活用用途は他にも探索的分析（EDA）、機械学習の特徴量等々がありますが、本記事は仮説検証型の事例ベースで紹介します（思想自体はその他用途にも応用できると思います）。
ここから、各段階でやることを順に整理していきます。
1. 分析観点を整理する
ログの具体に入る前に、まずは「何を分析したいか」を言語化し整理します。
- 施策（機能やデザインの改善/機能追加）によって、何が期待されるかを仮説として言語化する
- その仮説を踏まえ、どういう分析をしたいか方針を決める（指標の定点観察なのか、SQLや可視化を通じて深掘りするのか）
- KPI, 指標として何を観察すべきかを明文化する
分析観点の例
| 種別 | 例 |
|---|---|
| 1. 事業への影響を測るKPI | 課金CVR, 広告影響指標 |
| 2. 汎用的に使用されるKPI | 画面imp率, クリック率 |
| 3. 機能エンゲージメントを測る指標 | あるコンテンツに接触した後の機能継続率 |
| 4. ファネル分析 | 特定の画面遷移の離脱率 |
1はビジネスへの貢献を示すために優先的に設定されがちです。
また、2は「とりあえず分母分子を置いて観察する」ように定義がしやすく”わかりやすい”ため、企画時に見逃されることは少ないです。
一方、3や4は事前の仮説立て、導線や機能の観察を怠るとおざなりになりがちです。
結果、「分析したいけどログがない」に陥ることが多々ありました。
上記のフォーマットは、この反省を踏まえて整理したものになります。
こうして、まず「何を分析したいか」が明確になりました。
2. 分析する面のイベント, ユースケースを洗い出す
ここでは分析対象の面（ページや機能など）でどんなイベントが発生するか、そこでどんなユーザー行動が発生し得るかを整理します。
具体例とともに見ていきます。
まず、「画面を見た」「ボタンがクリックされた」等のユーザイベントを自然言語で表現し、一覧化します。
次に、ユーザー行動を想定し、その際発生し得るイベントを時系列整理したものを作ります。
このように、遷移の順番の多様性、およびユーザーのステータスの差異(課金有無など)がある場合、例え同じページを閲覧&機能を利用していたとしても、そこから発生していくイベントの順番や有無は異なります。
そのため、代表的なペルソナのユースケース別に、想定し得るイベントの発生順を整理しておきます。
これが、次工程での整理に役立ちます。
※ 全ての組み合わせを網羅する必要は無いです。
なお、ここで採用している手法はイベントストーミング手法に着想を得ています（以下記事に詳しいです）。
3. ログを仕込むべきイベントを見定める
ユーザー行動をイベントの粒度で整理出来たら、「どのイベントにログを対応付けるか」を見定めていきます。
その判断軸となるのが1.で整理した分析観点です。観測ポイントをどこに置けば欲しい指標、やりたい分析の集計ができるかを想像しつつ行います。
以下が完成系のイメージです。
分析対象によってその検討内容は千差万別ですが、例えば
- 分子/分母にどのイベントを置けば、指標が表現できるか
- イベントが起きた、という事実以外に取得すべきものは何か（例: どんな料理レシピを見たかを知りたい場合は、その情報も必要）
- 離脱状況をファネル分析したい場合、どのイベントをチェックポイントとすべきか
等々に考えを巡らせます。
この際、先の工程で実施したイベント＆ユースケースの整理が役立ちます。
仮に全てのイベントに機械的にログを仕込もうとすると大変ですが、こうして目的に応じて整理をすることで、設計&実装をより本質的なタスクに集中することが出来ます。
4. 設計叩き台を作る
ログとして仕込むべきイベントが見定まったら、PdMとデータサイエンティスト間で要件をすり合わせしつつ、設計書の叩き台を作ります。
- そのログがどのイベントに対応するものか
- どんな項目（カラム）が欲しいか
- どういう形式で情報を持つと、後の集計が楽になるか
の視点をもとに、具体として埋めていきます。
なお、この際、ログ実装としての優先度を決めておくと後に役に立ちます（どうしても分析に必要なものは「高」、後々役立ちそうなものは「中」など） 。
ここまでで、
- 「何」を分析したいか
- そのために「どのイベント」が集計対象となるか
- ログとして「どんな項目」を集計すべきか
分析要件として整理できました。
5. 開発側と議論しながら設計を完成させる
ここまで準備できたら、PdM & データサイエンティスト & 開発エンジニアでログの設計を具体として話し合う場を設けます。
ログを実装してもらうことになるサーバーサイドおよびクライアントサイドのエンジニアに設計叩き台を共有し、
- そもそも実装として実現可能か（技術的に可能か）
- 工数感はどんなものか（現実的に可能か）
等々の観点でレビューしてもらい、このまま実装に進むか、はたまた軌道修正すべきかを擦り合わせていきます。
「何がやりたいか」「そのために何が必要か」が優先度と共に事前整理&説明されていることで、納得感が生まれたり、技術的には難しい場合には代替手段を検討しやすかったりと、建設的な議論が可能になります。
ここを通過したら、あとは開発側の実装にバトンタッチです。
実装後、開発環境で意図通りにログが発火されるかをテストします。
それを見届けた後は、サービスがリリースされてそのログを使って分析を待つのみです。
やってみた所感
ログの抜け漏れが減った
何を分析したいか、そのためにはどういう項目がログとして実現されるべきか、という流れで整理するようにしたことで「必要なものがないから分析できない」「必要が無いログを過剰に仕込む」問題は自ずと解決されていきました。
分析計画の視野が広がった
企画の初期段階で「ログ」という具体に走らず「何を分析したいか」と抽象度を上げておくことが振り返りや意思決定の質に寄与すると実感いたしました。
最初からログの具体を設計しようとすると、自ずと視野が狭くなりがちです。
「難しさ」の事前対策がしやすくなった
当初想定したログ設計や集計が難しいことが見えてきた場合も、事前に対策しやすくなりました。
例えば、
- 出したいイベントログのloggingが技術的に難しい場合は、近い導線のイベントログで代替し、近似値として集計する
- イベントログだけだとSQLの集計が複雑する場合は、データチーム側で中間テーブルを用意しておき、PdMにはそれでクエリを書いてもらう
等の判断を、分析観点やユースケースに立ち戻りながら円滑に行えます。
挙動がイメージしやすくなった
イベントとユースケースを一通り整理しておくことによって、どのタイミングでどのログが発火されるかを想像しやすくなりました。
これまで、後から企画書や設計書を読んでもログがどこの導線&イベントに対応しているかがわからなかったり、開発端末やMockで画面遷移を見ながら目視で動きを確認したりする場面が多々ありました。
それらが込み入ると、だんだん何を見ていっているのかがわからなくなってきたり、関係者間で知らないうちに齟齬が起きたりに様々な辛みにつながります。イベントとユースケースの整理は、その対処に一役買ったといえます。
機能追加に向けた現状整理がしやすくなった
既存イベント&想定ユースケースがログと紐づくように整理され、挙動がイメージしやすくなったことで、機能の改修や追加がある際に現状との差分を確認しやすく、影響範囲を見定めやすくなりました。
終わりに
「ただ機能に対応するログを仕込む」ではなく、「分析者の目線に立ってログを設計する」という意識変革とその実践事例を紹介しました。
一連の取り組みを通じて、ログ設計の最適化はもちろん、継続的に分析&改善サイクルの質も向上することが出来ました。
本記事がデータ分析の取り組みにおける一助となれば幸いです。
