はじめに
こんにちは、データサイエンスグループ検索Growthチームの田代真生です。
昨年の4月に22年新卒でDMMに入社し、8月から検索Growthチームに加わり、データサイエンスの力を用いてより良い検索体験をユーザーに提供する仕事をしています。
今回は検索Growthチームの取り組みの一例として、検索UIの改善を行なった事例とともに検索Growthチームの仕事内容を紹介します。加えて、DMMのデータサイエンスグループで働いた新卒1年目の感想もお伝えしたいと思います。
施策の概要
DMM の各サービスの検索では、ジャンルやメーカーといった、商品の属性で絞り込める機能を実装しています。
この絞り込み軸のことを「ファセット」と呼んでおり、これによってユーザーは欲しい商品により近い検索結果を得られるようになっています。
本記事ではファセットをパーソナライズし、ユーザーが欲しいファセットを上位表示させたことによって、検索UXの向上を果たした施策を紹介します。
背景・課題
背景
適切に使うことでユーザーの要求をより反映できるファセット検索ですが、ファセット検索を実装するうえでは考慮すべき制限があります。その一つが限られたファセット検索の表示スペースで、ユーザーが使いそうな絞り込み条件を表示する必要があるということです。
以下は一般的なファセット検索UIの一例であり、これを見ると絞り込み候補となり得るジャンルの数に対して表示できる件数は5件と、非常に限られた数であることがわかります。
課題
このように表示スペースの制約がある中で、これまでの絞り込み検索では「絞り込む前の検索結果に含まれる属性が多い順で表示する」という実装をしていました。
先ほどの例でいうと「コンピューター」や「インターネット」は、それらのジャンルの商品が検索結果に多く含まれているために上位表示されて絞り込みやすくなっています。
しかしこの仕様では、商品数の少ないジャンルがファセットに現れることが少ないという欠点があります。
例えば「コンピューター」は、どの検索結果にも多く含まれることから多くの検索結果においてファセット検索に表示されます。
一方で例えば「AI・機械学習」などの最近生まれたジャンルの商品は人気で、絞り込み検索がよく行われそうであるのにも関わらず、「コンピューター」などと比べると商品数が少ないために多くの場面でファセット検索に表示されません。
そのためユーザーがファセット検索をする際に、「絞り込みたい条件で絞り込みづらい」というのが今回の課題です。
ちなみに検索Growthチームでは、検索の状態を把握する目的で独自に作成したダッシュボードの確認やユーザーからの検索に関する要望の確認、検索システムを実際に利用して課題がないかの調査を定期的に行なっています。
その中で特定の属性の絞り込み条件が不可解に少ないという気づきがあり、今回の課題が見つかりました。
施策の詳細
施策案
今回の施策では「絞り込みたい条件で絞り込みづらい」という課題に対して、ユーザーの絞り込みたい条件を予測し、ファセット検索に優先的に表示することで解決しようと考えました。
具体的には、「ユーザーは好みの属性ほど絞り込みやすい」という仮説のもとで各ユーザーの購買履歴を分析し、推測されたユーザーの好みの属性を優先的にファセットに表示させるようにしました。
今回の施策におけるユーザー好みの属性の推測手法としては、シンプルに直近の購買数の多さを見る手法を取りました。
これは今回調べたい仮説が「ユーザーの好みの属性を優先的にファセット検索に表示することで、ファセット検索が使いやすくなるか」であり、ユーザーの好みの属性の予測精度を上げる作業は、その仮説の結果次第で無駄になってしまうと考えたためです。
またユーザーの購買回数の多い属性がファセット検索で使われやすいというデータも出ており、今回の施策においてはこの手法でも結果が出ると考えました。
施策の実装
今回の施策の設計は以下の図のようになっており、実装にあたっては主に検索プロキシAPI(下図参照)の実装とバッチの実装の二つをする必要があります。
今回の施策では、通常通り検索エンジンから返されるレスポンスの中のファセットの情報を検索プロキシAPIで書き換えて、ユーザーに返すという実装を行いました。 そのため、検索プロキシAPI自身の実装と検索プロキシAPIが使う加工データを日次で取得するためのバッチの実装を行う必要がありました。
詳細な説明は、過去の記事のシステムアーキテクチャの詳細やバッチアーキテクチャの概要をご覧ください。
余談にはなりますが、私は新卒で入社して初めて施策を実装した中で、検索Growthチームの開発体験が良いと思う点が2点ありました。
1点目は、検索システムに関わるさまざまな技術に触れる点が魅力的です。
バッチは主にPythonやPySparkを用いて実装し、検索システムの改善はGolangを用いて実装されます。 そのほかにも、SolrやEKSインフラ周りなどのさまざまな技術に触れながら実装していくため、機械学習の関連技術からAPIの実装まで幅広い技術を学べるのがチームの魅力であると感じました。
2点目は、すでに作られているシステムアーキテクチャのおかげでリードタイムが短く実装できる点も魅力的でした。
検索Growthチームの多くの施策は、検索プロキシAPIの変更のみで完結できるようになっているため、自分達のチームの工数だけで非常にスピーディに施策を進められ、アイデアのPDCAを素早く回せる環境が整っていると思います。
施策の効果
今回の施策でも他の施策と同様にA/Bテストを実施しました。
検索GrowthチームでのA/Bテストの詳細については以前こちらで紹介させていただきましたが、検索Growthチームの施策は原則A/Bテストを通して反映の可否を判断します。
基本的にはメインKPIであるARPUと施策ごとに異なるサブKPIを観測しており、今回の施策ではファセットクリック率をサブKPIとして置きました。
結果を見てみると、ファセットクリック率が20％近く上昇し、ARPUもわずかながら上昇が確認できました。
このことから、ファセット検索のパーソナライズによってファセット検索のUXを向上し、さらにファセットクリックを増やすことでユーザーの潜在的なニーズをより引き出すことに成功したと考えられます。
まとめ
今回は検索Growthチームの取り組みの一つとして、ファセット検索UI改善の取り組みを紹介しました。
私にとっては、今回の施策が検索改善チームに所属して最初の仕事であり、新鮮なことが多くあったのですが、この施策を通して印象に残った点が3点ありました。
1点目は、DMMでの検索改善の面白さです。
今回の記事では紹介できませんでしたが、DMMの検索Growthチームは検索の並び順の改善から今回のような検索UIの改善、さらに新たな検索機能の開発など幅広い施策に取り組むことができます。
そして、その施策案を自分の分析によって生み出すことから始めるので、主体性や好奇心を持ちやすくなっており面白いと感じました。(もちろんチームメンバーも施策案を決めるのを手伝ってくれます)
2点目は、施策実施を通して感じた難しさです。
先ほども触れましたが、施策を実施するにあたって機械学習に関する実装以外にも、バックエンドの実装に触れたり、検索エンジンに触れたりする機会が多くあります。
さらに、実装自体は部内で完結することが多いですが、それでもさまざまなステークホルダーと合意を取って施策を進めていく必要があるため、合意形成に必要なデータ分析を進めていく力やコミュニケーションをとって合意形成を進めていくことが必要であると感じました。
このように施策実施には幅広いスキルが必要となってくるため、慣れない私にとっては難しさを感じるとともに成長の機会が多かったと感じる期間でした。
3点目は、施策のサイクルの速さです。
これも先ほど少し触れましたが、インフラエンジニアの方が作ってくださった検索システムアーキテクチャのおかげで、検索改善の実装は他の部を巻き込まずに進められることがほとんどです。 そのため、事業規模が大きいDMMでも施策を素早く実験し、改善を進められるのは驚きで、非常に魅力的であると感じました。
このようにDMMのデータサイエンスグループでは、統計や機械学習の技術を用いてさまざまなタスクに取り組んでおり、このほかにも面白い課題が数多くあります。
