はじめに
こんにちは、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はモジュールの組み合わせによる影響やポジションバイアスが存在すると想定できますが、それらを除けば単純に並び順が異なるモジュール同士を比較できる指標です。もちろん、モジュールの目的に応じてCTRではなく他の指標をメインKPIとする場合もありますが、ほとんどのモジュールはCTRで評価できます。CTRを高めることで商品ページや検索ページへの遷移が増え、ユーザーが商品の購入を検討する機会が増えます。間接的ではありますが、これは最終的にZOZOTOWN全体のKGIであるGMVに貢献できると考えています。
Viewable Impressionの設計
ここからはCTRを求める際に必要なview-impの具体的な仕様について紹介します。補足として、これ以降の話はZOZOTOWNアプリのみを対象（Web版は除外）とします。また、view-impはコンテンツやバナーなども考えられますが、本記事ではモジュールのview-impを指すことにします。
以下ではZOZOTOWNホーム画面におけるview-impの仕様を3つの項目に分けて紹介します。
- 発火範囲
- 記録間隔
- 再記録
発火範囲
view-impの発火範囲の条件は「モジュールの高さが50％以上画面に表示されたとき」としています。閾値を50％に設定している理由は以下です。
- 1モジュール全体の画面に占める表示領域の割合が大きいため
- ZOZOTOWNアプリではモジュールのコンテンツを2段組みで表示しており、上段・下段のいずれかを閲覧した場合でもモジュールを閲覧したものとして判定するため
また、この条件は言い換えると「モジュールの高さの中心が画面に表示されたとき」と解釈できるため、実装上の複雑さを軽減している利点もあります。
以下の図はview-impの発火範囲の条件を満たしたパターン（上段3つ）と満たしていないパターン（下段2つ）の例を示しています。赤い枠の領域が画面に表示されているモジュールの領域を表しており、青いラインがモジュールの高さの50％の位置を表しています。青いラインが赤い枠内にある場合、発火範囲の条件を満たします。
記録間隔
view-impは前述した発火範囲の条件に加えて、「1秒以上モジュールが画面上に表示されていること」も発火の条件としています。具体的には、100ms間隔でモジュールの高さの中心が画面に表示されているか確認し、10回連続で観測できればview-impのログとして記録します。記録間隔を100msとしている理由は、「デバイスでの計算処理の負荷を軽減するため」と「人間の反応時間（人間が事象を認知するまでの時間）は最小で100msであり、100msより短い間隔でデータを収集する必要はないため」です。この記録方法によって静止状態だけでなくスクロール中も集計できます。
再記録
再記録とは1度view-impのログとして記録されたモジュールが再度記録されることを指します。なお、view-impの発火範囲内であればスクロールしても再記録されません。再記録されるパターンは以下の4パターンです。
- ログ発火後にモジュールの高さが50％未満となり、再度50％以上になった時
- ホーム画面内でのモールタブ・性別タブの切り替え時
- バックグラウンドからの復帰時
- 別画面への遷移からのページバック時
KPIモニタリング用の定常レポートの作成
モジュールの運用を改善していく上で、モジュールのKPIを定常的にモニタリングする必要があります。今回はモジュールのKPIをモニタリングする環境として、Google社が提供するクラウド型BIツールであるデータポータルを採用しました。データポータルは弊社でデータ基盤として使用しているBigQueryとの親和性が高く、ビジネスチームへの展開が容易といった点から、弊チームのモニタリング環境として利用されることが多いプロダクトです。
実装上の工夫
バッファリング&リトライの設計
アプリの通信とパフォーマンスを考慮し、リアルタイムでログを送信するのではなく、バッファを利用することで送信回数を減らしました。バッファの送信タイミングの仕様は以下です。
- アプリの起動時に送信
- 120秒間隔で送信
- ローカルに保持したログが100件到達時に送信
もし送信に失敗した場合は次回の送信時にリトライとして送信します。ただし、送信失敗時にログが100件以上の場合は120秒後の送信タイミングまで送信されません。
また端末の容量を圧迫しないように蓄積するログのハードリミットを1000件としました。ハードリミットに達した場合、1001件目以降のログは破棄され、その破棄件数をログとして記録しています。
ログの内製化
ここ最近で内製のデータ基盤が構築され、このデータ基盤を通じて社内の様々なデータがBigQueryに蓄積されています。この影響でログの内製化が加速し、今回紹介したモジュールのview-impはHOME画面において内製で実装した初めてのview-impでした。
今後の内製ログの拡大を見越して、他のview-impの実装で再利用できるように、ログ送信方法を汎用的に設計しました。また、デバッグ時に通知やトーストなどで送信したログを表示する仕組みを作成し、確認テストを行い易いようにしました。
効果
良質なモジュールの生産効率の向上
定常的にモジュールのKPIを確認できるようになったことで、モジュールの良し悪しを素早く判断できるようになりました。以下のテーブルは定常レポートにおけるモジュールごとのKPIの一部を表示しています。
このように定常レポートから日々指標を確認しながらモジュールの良し悪しを判断し、次のモジュールリリースの改善に努めています。また、データがたくさん集まってくると良いモジュール・悪いモジュールの傾向も掴みやすくなり、良質なモジュールの生産効率の向上が期待できます。
モジュールの並び順改善
ここではview-impによるCTRの導入によって、異なる並び順のモジュールを比較できるようになった一例を紹介します。以下のグラフはある特定期間におけるモジュールの並び順と商品クリック数・CTRの関係を図示した棒グラフです。両グラフとも横軸は「ホーム画面の上部から下部にかけてのモジュールの並び順」を表しています。縦軸はそれぞれ対象期間における「商品クリック数の合算値」と「商品クリック数の合算値とview-imp数の合算値から算出したCTR」を表しています。
CTRのグラフから、3番目のモジュールのCTRが他のモジュールと比較して低いことがわかります。3番目のモジュールのCTRが低いとわかれば、他のモジュールとの差し替えや後方への位置変更によって並び順を改善できます。商品クリック数でこの判断をすることは難しく、CTRを導入したことで正確な並び順の評価ができるようになりました。
今後の展望
「良いモジュール」の分析と要因追求
良いモジュールと言われるモジュールには必ずその理由があります。「タイトル・サブタイトルがユーザーの目を引くものだった」や「表示しているコンテンツがユーザーの趣味嗜好に合っていた」など様々な要因が考えられます。特にコンテンツに関しては横スクロールをしないと全てのコンテンツを確認できなかったり表示数が限られていたりするため、コンテンツの種類や並び順によってユーザーがモジュールに持つ印象に影響を与えることが予想されます。
ログの内製化の促進により、各コンテンツのview-impやクリック数も取得できるようになりました。そのため、今後はコンテンツに関わるデータも使用して良いモジュールの要因を探り、さらなるモジュールの改善に努めていきたいと考えています。
ユーザーセグメントの分解
良いモジュールと一口に言ってもユーザーのセグメントによって好まれるモジュールの傾向は変わります。一例として、最近の分析ではZOZOTOWNでの購入経験の有無で好まれるモジュールの傾向に違いがあることがわかってきました。購入経験のないユーザーは、タイトルやサブタイトルに「季節」関連の単語を含むモジュールやタイムセールモジュールを好む傾向があります。また、購入経験のあるユーザーはタイトルやサブタイトルに「新作」や「限定」などの単語を含むモジュールやクーポン関連のモジュールを好む傾向があります。
このようにユーザーのセグメントごとにモジュールの傾向が見つかれば、そのセグメントごとにモジュールを出し分けすることでよりユーザーに適したコンテンツを提供できます。ZOZOTOWNのホーム画面でもこれらを実現するために、今後は「セグメントごとのモジュールの傾向分析」と「セグメントごとにモジュールを出し分けできる機能開発」を進めていきたいと考えています。
ホーム画面におけるパーソナライズ強化
多種多様なデータが集まると、そのデータを最大限活用してホーム画面を良くしていきたいものです。ホーム画面の改善案の1つとして、パーソナライズ化があります。ホーム画面に訪れるユーザーは、探している商品や好みのブランド・ショップがそれぞれ異なるため、同じ商品を訴求するよりもユーザーによってパーソナライズするほうが良い推薦と言えるでしょう。特にホーム画面はサイトの顔でもあるため、ユーザーがホーム画面に訪れた際、そのユーザーの探している商品を正しく訴求できれば機会損失の防止に繋がると思います。
直近ではパーソナライズモジュールの作成に注力しており、第一弾として2022年4月にリリースしました。こちらのパーソナライズモジュールの詳細は以下の記事にまとまっているため、ご興味のある方はご覧ください。
ただし、こちらのパーソナライズモジュールは開発スピードを優先してルールベースの簡易的なロジックを利用しています。また、開発当初はログの内製化が開始されたばかりで、view-impなどのログは存在していませんでした。そのため、現在のパーソナライズモジュールはまだまだ改善の余地がある状態です。この改善に向けて、view-impなどのモジュールに関するデータを活用した機械学習モデルのパーソナライズモジュールを絶賛開発中です。
ホーム画面におけるパーソナライズ化の道は果てしないですが、ユーザーが探している商品を1つでも多く見つけてもらえるようなホーム画面にしていきたいと考えています。
おわりに
本記事ではZOZOTOWNのホーム画面におけるデータドリブンな取り組みについて紹介しました。今後の展望に挙げたように、これからさらにデータの活用やレコメンドの改善を進めていきます。ZOZOではこのような取り組みを一緒に進めていただける仲間を募集中です。ご興味のある方は、以下のリンクから是非ご応募ください！
また、カジュアル面談も随時実施中です。是非ご応募ください！
