【TECH BLOG】ZOZOTOWNホーム画面におけるログ設計と改善サイクルの紹介

はじめに

こんにちは、ML・データ部推薦基盤ブロックの宮本（@tm73rst）です。普段は主にZOZOTOWNのホーム画面や商品ページにおいて、データ活用やレコメンド改善のプロダクトマネジメントを行っております。

近年ビックデータ社会と言われる中、データドリブンという言葉をよく耳にします。ZOZOTOWNのホーム画面は、ホーム画面の各パーツごとにViewable Impression（以降、view-impと表記）を取得できるようになったことでデータドリブンな評価や意思決定が促進されました。

本記事では特にZOZO独自のview-impの設計とview-impを用いてどのようにホーム画面を改善しているかについて紹介します。データドリブンな施策の推進を検討している方に向けて、本記事が参考になれば幸いです。

本記事におけるViewable Impressionの定義

本記事ではホーム画面のview-impの定義を「ホーム画面の各パーツに対して、ユーザーが実際に目に触れて認識した閲覧ログ」とします。そのため、パーツの内容を把握できない瞬間的な表示や部分的な表示はview-impの発火と見なさず、表示時間や表示面積などの発火条件を満たしたときに発火と見なします。具体的な発火条件に関してはこの後のセクションで説明します。

背景

ZOZOTOWNホーム画面の運用について

ZOZOTOWNのホーム画面はバナーや検索機能をはじめとする多くのパーツで構成されています。中でもページの大半を占めるのが「モジュール」と呼ばれるパーツになります。モジュールは「タイトル、一覧ページ、コンテンツ」の3つのパーツで構成されています。なお、タイトルの上部にサブタイトルが付くモジュールや一覧ページがないモジュールなどもあります。

モジュールは多数ありますが訴求の種類で分類すると、現状は大きく以下の4つになります。

モジュール名　　　　　説明
導線モジュール　　　　　閲覧した商品を軸としたリターゲティング系モジュール
企画モジュール　　　トレンド商品や企画商品など企画チームが考案したモジュール
広告モジュール　　　広告商品用モジュール
レコメンドモジュール　ユーザーごとにパーソナライズされたモジュール

ホーム画面では上記のモジュールを組み合わせてユーザーにさまざまな商品を提示しています。また定期的にビジネスチームと連携しながら、モジュールの並び順を調整したり別のモジュールに差し替えたりといった運用をしています。

課題

モジュールの運用の理想的なサイクルは、実際に表示したモジュールを正しく評価し、その結果を次の運用に活用することだと考えています。しかし、これまではファッションに関する市場調査や他社の事例を参考とする定性的な意思決定に基づいたモジュールの運用をしており、定量的な意思決定に基づいたモジュールの運用はできていませんでした。もちろん最近のファッショントレンドや他社の取り組みを把握し、それを施策として反映することは重要です。とはいえ、新たなモジュールを次々に作ったとしてもそのモジュールを正しく評価できないとモジュールの良し悪しが判断できず、モジュールの改善に繋げることができません。

定量的な意思決定に基づいたモジュールの運用ができていなかった理由として以下の3つが考えられます。

良いモジュール・悪いモジュールを定量的に判断する基準がない
モジュールを評価するためのデータが足りていない
定常的にモジュールに関する数値を確認できるレポートが存在しない

上記の課題を解決することでデータドリブンな評価や意思決定に繋がると考え、各課題に対して以下のアプローチをとりました。

課題解決へのアプローチ

前述した課題を解決するためのアプローチは以下の3つです。

モジュールの良し悪しを評価するKPIの設計
モジュールのKPIに必要なview-impの設計
KPIモニタリング用の定常レポートの作成

それぞれの取り組みについて具体的に紹介していきます。

データドリブンを実現するための取り組み

モジュールのKPI設計

ホーム画面におけるKPI分解とモジュールの役割

ZOZOTOWN全体ではGMVをKGIとしており、またホーム画面では以下の3つをメインKPIとしています。

ホーム画面のメインKPI
説明
ホーム画面経由の受注金額
ホーム画面に表示されている商品をクリックしたセッション内での受注金額
ホーム画面ランディングセッション直帰率
ホーム画面の直帰セッション数÷ホーム画面ランディングセッション数
コンテンツクリックユーザーあたりホーム画面経由の受注金額
ホーム画面経由の受注金額÷コンテンツクリックユーザー数

ホーム画面のメインKPIをモジュールのメインKPIに分解したいのですが、モジュール単位で考える上での注意点が3つあります。

「ホーム画面ランディングセッション直帰率」などホーム画面に関するKPIをそのままモジュールの評価に使用した場合、並び順が異なるモジュール間での比較を正確に行えない
定期的にモジュールは変更されるため、収集できるデータ量の少ない「購入」や「カート追加」などの指標はサンプル数不足になる可能性がある
コンテンツには記事やショップページなど商品以外のパターンも存在する

このため、単純にホーム画面のメインKPIをモジュールのメインKPIに分解してしまうと、モジュールの評価を正確に行えない可能性があります。例えば「モジュール経由の受注金額」をメインKPIとすると、並び順の異なるモジュール間の比較ができなくなってしまいます。またサンプル数不足によって統計的な判断が行えない場合もあります。

そこで正確なモジュールの評価ができるKPIを設計するために、モジュールの役割を考えました。モジュールはホーム画面の大部分を占めており、コンテンツや一覧ページなどを通じて他のページへの導線が多数存在します。したがってモジュールの役割は「ユーザーにモジュールを通じてZOZOTOWN内を回遊してもらい、探している商品や趣味嗜好に合う商品を見つけてもらうこと」だと考えました。

モジュールのメインKPIの決定

前述した注意点と役割を踏まえて、モジュールのメインKPIを「次ページ遷移率（以降、CTRと表記）」としました。また、サブKPIとしてはコンテンツクリック数、「すべて見る」クリック数、カート投入数、モジュール経由の受注金額などを設定しています。以下にメインKPIとサブKPIをまとめています。

種類　　　指標
メインKPI CTR
サブKPI　　コンテンツクリック数
　　　　　　「すべて見る」クリック数
　　　　　　　view-imp数
　　　　　　　カート投入数
　　　　　　　モジュール経由の受注金額
　　　　　　　モジュール経由の注文商品数
　　　　　　　コンテンツクリックあたりカート投入数

CTRの定義は以下です。

CTR = コンテンツクリック数 ÷ view-imp数

CTRはモジュールの組み合わせによる影響やポジションバイアスが存在すると想定できますが、それらを除けば単純に並び順が異なるモジュール同士を比較できる指標です。もちろん、モジュールの目的に応じてCTRではなく他の指標をメインKPIとする場合もありますが、ほとんどのモジュールはCTRで評価できます。CTRを高めることで商品ページや検索ページへの遷移が増え、ユーザーが商品の購入を検討する機会が増えます。間接的ではありますが、これは最終的にZOZOTOWN全体のKGIであるGMVに貢献できると考えています。