はじめに
こんにちは、検索 Growth チームの西潟一生です。 DMM.com では動画や電子書籍など、計数百万を超える膨大な数の商品を抱えている一方で、国内屈指の商品保有数を誇る DMM であるが故に、その中からユーザーに好みの商品をどうやって見つけてもらうかという課題も抱えています。今回の記事では、私たち検索 Growth チームがどのようなモチベーションでこれらの課題と向き合い、検索改善の仕組みを構築してきたのか紹介していこうと思います。
一般的な検索改善とは
まず、「検索改善」が一般的にどのようなことを指すのかをご紹介します。一般的に検索改善という文脈では大きく分けて2つの性能の改善が考えられます。1つは検索エンジンのレスポンスタイムやスループットと言った検索のパフォーマンスや、検索システム全体を RASIS などの観点で性能を改善することを指します。特に売上毀損に直結する落ちない検索システムを構築することは重要課題の1つです。
一方で、速くて落ちない検索システムであれば十分かと言うとそうではありません。ユーザーが期待する結果を返すシステムでなければ利用されることはないでしょう。この「期待する結果になるよう改善すること」が2つ目の性能改善にあたります。
私たち検索 Growth チームの主な業務は後者の性能改善であり、日々、改善に取り組んでいます。
検索改善における指標とは何か
「ユーザーが期待する検索結果の改善」は一般的には以下の2点が改善ポイントとして挙げられます。
- ユーザーが望まないデータ（=ノイズ）が検索結果に含まれている割合
- ユーザーが望むデータが検索結果から漏れている割合
この「ノイズ」と「漏れ」の関係は、ノイズを減らせば漏れが増え、漏れを減らせばノイズが増えるというトレードオフの関係にあることが知られています。トレードオフにある関係を両立させるためには、検索結果のランキングが肝です。「検索漏れを少なくしたために、全体としてノイズが多かったとしても、ランキング上位にはユーザーが期待する結果が表示されている」状態を成立させられれば、ノイズが少なく、漏れもない状態を両立させられることになります。検索結果を評価する時の指標は数多くありますが、大体がこの観点を評価する指標です。
弊社のようなサービスではランキングの良さが重要であることを裏付けるデータもあります。以下のグラフは DMM のとあるサービスのランキングとクリック数の関係について示したものです。残念ながら実際のデータはお見せできないため、以下のグラフはダミーデータにしていますが、おおまかな傾向は崩していません。
具体的なクリック数は伏せますが、縦軸はクリック数とその累計割合、横軸はランキングです。このデータを見ると、ランキング 60 位くらいまでで全体のクリック数の約 8 割を占めていることがわかります。特に上位 5〜6 件ほどは突出してクリック数が高いことがわかります。
このような結果になる理由として、以下の2つのことが考えられます。
- ランキング上位にユーザーが欲しい商品が表示されていたため、ランキング上位の商品がクリックされる
- ランキング上位の商品は画面上部に表示されるため目に入りやすく、クリックされやすい
2つ目の状況は検索システムのバイアスとしてよく知られています。もちろんランキング上位にユーザーが欲しがる商品を並べられているからこそ上記のグラフになっているとも考えられますが、ユーザーがもっとも欲している商品が表示されていたかどうかは分かりません。クリックされやすい商品が欲しくない商品であった時の機会損失は大きいでしょう。このように、ランキングの良さは購買に直結し、売り上げを左右する重要な指標と言えるのです。
DMM における検索改善の難しさ
次に、DMM におけるランキング改善の具体的な難しさや課題感を紹介します。
ノイズの多さはランキングの良さによってカバーすれば良いと述べましたが、検索結果からノイズを判別してランキングの後方に位置させることは容易ではありません。特にサービスが抱える商品点数が多くなればなるほど相対的にヒット件数が多くなるため、結果としてノイズが多く含まれる傾向にあります。
動画や電子書籍のような嗜好性が高い商品の場合、アクション映画1つ取ってみても出演者やアクションの内容、時代設定など、嗜好性に対する変数は数多くあります。アクション映画だからと言ってこれを1つにまとめると、そのほとんどがユーザーにとって不要なものになりかねません。ノイズはユーザーによって様々なのです。
動画や電子書籍が映像や画像を主体としたコンテンツの場合は検索が更に難しくなります。理由は、これらの商品を構成するのは画像や音声であるのに対し、探し出す時の手段として文字列を使用しているからです。映像や画像に対するユーザーの嗜好性は非常に言語化しづらく、それが検索の難しさに繋がります。そのため、検索された文字列からユーザーの意図を汲み取るアプローチや、商品につけるメタデータの整備、潜在的にユーザーがどのような商品を欲しているのか推定するアプローチなどは非常に重要と言えます。
DMM における検索改善の KPI 設定
ここからは DMM の検索が抱える課題をどのような KPI に対してアプローチしているのか紹介します。
施策を考えるうえで重要になるのが、メイン KPI です。弊チームではサービス全体の売上を俯瞰できる ARPU（平均売上）をメイン KPI として定めることが多く、それを補足するうえで CTR/CVR などの指標を見ています。以下にその根拠を述べます。
検索結果が改善したか測る指標には一般的に、CTR（検索結果一覧のクリック率） や CVR（検索結果一覧からクリックされた商品の購入率）、カート追加率などがよく知られていますが、弊社のようなサービスにおいては、これらの指標の改善が必ずしも良い結果に繋がるとは言い切れません。まずは CTR から紐解いていきましょう。CTR が上昇する理由には少なくとも以下の2つが考えられると思っています。
- 検索結果にノイズが減ったことで、検索したけど何もクリックされなかった、もしくはあまりクリックされなかった状況が改善されて CTR が上昇する
- 検索結果が自分にマッチするか分からないため、とりあえずクリックして商品の詳細を確認する作業が増えたことで CTR が上昇する
前者は期待通りの改善結果と言えます。問題は後者で、ユーザーは欲しい商品を見つけられていない可能性が考えられます。ユーザーは本当に興味がない商品以外は思いの外クリックします。アクション映画好きのユーザーであれば、アクションぽい映画はクリックはしてくれますが、嗜好にマッチしなければ購買には至らないでしょう。
この場合 CTR のみの観測では不十分です。商品ページの滞在時間も計測し、すぐに検索結果一覧に戻っていないか計測することで仮説の信頼性を上げられる可能性があります。
では CVR を見れば良いかと言えば、そうではないケースもあります。DMM のサービスはサブスクもあれば、商品買い切りもあります。商品買い切りのサービスに対する施策では CVR が改善したのに喜べないケースもあります。それは安い商品が多く購入された場合です。CVR は上がるものの全体の売上は低下し、短期的に見てビジネスに悪影響を与えてしまうこともありえます。古い商品を安くするサービスでは、安い商品が並んでいた＝古い商品が並んでいた可能性も考えられます。
このような状況があることから、弊チームでは、サービス全体における 1 ユーザーあたりの平均売上を表す ARPU という指標をメイン KPI によく用いています。ポイントはサービス全体の ARPU で施策の良し悪しを判断しているという点です。検索の改善施策なので、検索経由のトラフィックに絞って ARPU が向上したかどうかを判断すべきと思われるかもしれませんが、施策がサービス全体の売上に悪影響を与えてしまっていては元も子もありません。
ARPU はあくまでメイン KPI として定めているだけで、CTR/CVR といったその他の KPI を見ないわけではありません。ARPU に有意差がなくても、総合的に判断してその他の KPI が向上したから有効と判断する施策も存在します。
DMM の検索システムの概要
KPI を達成するための DMM の検索システムを概観しておきます。
DMM では検索エンジンに Apache Solr（以下、Solr） を利用しています。検索 Growth チームが本格的に検索改善に取り組むまでは、DMM の Solr はごく一般的な日本語検索用のスキーマを使用していただけで、前述の観点で改善を実施したことはあまりありませんでした。そこで弊チーム発足後は、基礎的な改善策から発展的な改善策までをフェーズに分けて取り組んできました。最初に設定したフェーズは以下の通りです。
- スキーマ最適化や定性的観点でのフィールドの重み付け、Tokenizer の改修、同義語の拡充といった静的な設定変更による改善
- 検索エンジンに登録されている各データの値（購買数や人気度など）を定期的に変更し、その値によって動的に検索結果が変わるように改善
- ユーザーやセグメントごとに検索エンジンに投げるクエリを変化させ、動的に検索結果が変わるように改善
- ユーザーやセグメントごとに検索エンジンに登録できない2次情報（ベクトルなど）を用意し、その情報によって検索結果の TopN 件をリランクするように改善
1 と 2 のフェーズは全体最適と呼び、3 と 4 のフェーズは個別最適と呼んでいます。
全体最適フェーズでは検索エンジンが持つ機能単体を用い、「検索結果は最適化されているが、どのユーザーが検索してもクエリが同じであればランキングは同じ」という状態を目指します。
個別最適フェーズの 3 は検索エンジンが持つ機能のみで実現する点は全体最適フェーズと同様ですが、検索エンジンに投げるクエリをユーザー単位で変えることによって個別最適を実現します。
4 のフェーズまで来ると、検索エンジンの機能単体では実現が難しくなるケースも出てきます。例えば現在使用している 8 系 Solr ではベクトルの演算ができないので、この操作をしたい場合は検索エンジンの外で行うことになります。（この辺りは Elasticsearch に一日の長があります）
われわれの KPI に対して一番インパクトがあるのは 3〜4 であるケースが多く、現在はこの辺りのフェーズに力を入れています。中長期的な観点では 1 の充実がユーザー定着の観点から重要であることは認識しています。一方で 1 の改善は検索エンジンと密結合になりやすくもあります。これは今後の検索エンジンの技術選定や改修にも大きく影響するため、できる限り検索エンジン直前の API で検索をコントロールできる 3〜4 に注力しているという経緯があります。
施策の実施について
仮説の立て方
弊チームのメイン KPI は ARPU であることが多いため、深堀りするために、ARPU を以下のようにツリーに分解します。
この KPI ツリーからどの KPI を改善するのか大まかな施策内容を決め、期待できる ARPU 増加分を試算します。
PoC
検索エンジニア、ML エンジニア、データアナリストが多く所属する弊部では、仮説検証から PoC までを弊部専用プラットフォーム上にある Jupyter notebook 上で実装しています。これは検証や PoC のプロセスを誰でも再現可能な状態にするだけでなく、充実したリソースやライブラリが整っているプラットフォームで実行することによって PoC 完了までのリードタイムを減らすことを目的にしています。具体的な PoC の内容については割愛しますが、PoC が完了したら得られたアウトプットについてステークホルダーと共有し、レビュー完了後、A/B テストの実施となります。
施策リリース
PoC までは Jupyter notebook 上で実施していますが、A/B テストが実施される施策は、弊グループのバッチワークフローエンジン上で実行します。現在の改善施策では、バッチで求めた値を検索エンジンもしくは KVS に登録していることが大半です。検索時またはレスポンス時にそれらを検索用 API が参照し、登録している値に応じて検索エンジンに投げるクエリ書き換えや検索結果同士の類似度計算、検索エンジンのレスポンス書き換えなどの処理を行って最終的な検索結果を返しています。
検索エンジンがベースにはありますが、その手前でクエリやレスポンスを書き換えて検索エンジンだけでは実現できない柔軟な結果をユーザーに提供できているのが特徴です。
効果測定（A/B テスト）
施策の効果は A/B テストによって測定しています。
DMM では弊チーム以外の施策でもキャンペーンやセールなどが何かしら実施されている状況にあります。このような状況において、弊チームの施策が有効であったかを施策の前後で比較して測ることは容易ではありません。ARPU や CVR といった KPI が向上したとしても、キャンペーンやセールが影響したのか、弊チームの施策が影響したのか前後比較で判断することは難しいでしょう。
様々な施策が同時並行で実施されている DMM において A/B テストは非常に効果的な測定方法であり、現状では A/B テストを弊チームの唯一の効果測定として活用しています。
弊チームで実施している A/B テストの流れを簡単に紹介します。
- 施策対象のユーザー全体をランダムに 50:50 に割り振るランダムシードを求める
- ランダムシードを用いて A/B テスト開始日手前の過去 14 日間のユーザーを 50:50 で抽出する
- 抽出したユーザーの ARPU など、定めた KPI の値を確認し、統計的に有意差がないことを検定する（A/A テスト）
- 統計的に有意差がない 2 群が求められたら、14 日間の A/B テストを実施する
- A/B テスト終了後、定めた KPI の値を確認。統計的に有意差があるか検定し、有意差があれば有効な施策と判断する
上記の点を補足すると、これまでの施策の効果量、対象となるユーザーのサンプルサイズ、施策実行の頻度を鑑み、ログインしている全ユーザーを 50:50 に分けたり、テストの期間を 14 日間としています。その他 A/A テストから A/B テスト終了までの流れや検定方法は統計量の性質に合わせたスタンダードな手法を用いています。A/B テストで有効と判断された施策は、恒久的な施策としてリリースします。
まとめ
簡単ではありましたが、本記事では、DMM での検索改善の課題感や取り組みの方針について解説しました。
取り組みそのものは非常にスタンダードなものです。とは言え、ここまでの道のりは容易いものではありませんでした。特に弊チーム立ち上げ時は今と比べて簡易的な施策も多かった割に仮説と一致しない結果だったり、リリース時の障害が目立ったりしたこともありました。文章で書くとシンプルに見えるかもしれませんが、仮説立案から A/B テストまでの流れは、DMM のデータ分析基盤、実行基盤、A/B テスト基盤などが充実し、柔軟かつ堅牢であって初めて成り立つものです。
これらの基盤は弊チーム立ち上げ時から常に進化を続けています。当初は検索エンジンのチューニングしか行えず全体最適な結果のみ返せていたものが、今では検索結果を柔軟に変化させて、ユーザー個別に最適な結果を返せるところまで来ました。これはひとえに弊チーム及び DMM 全体がテックカンパニーとしてスピード感を持って取り組んできた結果と言えます。
弊チームでは今後もユーザーに最適化された結果を届けられるように高度な手法にも挑戦していきたいと思っています。そのためには、一緒に働いてくれる仲間がさらに必要です。
ご興味のある方はぜひ下記の募集ページをご確認いただきお気軽にご応募いただけると幸いです（カジュアル面談の場も用意しております！）
また今回の記事を読んで、技術的に気になった点があれば是非お気軽に弊チームまでお問い合わせください。この記事ではお伝えできないもう少し詳細な回答を差し上げられると思います。
データサイエンスを駆使した事業成長を手がける「Growth Scienceグループ」の正体とは？ - DMM inside
