AppBrew Tech Blog

AppBrewのエンジニアチームの日々です

【ユーザーファーストで】LIPS の検索システムを改善する【考える】

AppBrew でアルバイトをしている Pin(@spinute)です。先月は【無職が】AppBrew でアルバイトをしてみた【やってみた】という記事で私がこの会社で働いている経緯を説明しました。

今日はもう少しテックブログらしい内容で、LIPS の検索機能改善について紹介します。

小規模なチームでは、検索機能専任の人はおらず、開発者が片手間に検索機能のお世話をすることが多いと思います。 そうするとイマイチ勘所がわからず、どこに着目し・どう手を加えればいいのか、迷ってしまうこともあると思います。 そういう場面で改善の指針となる評価指標を、実例を混じえながら紹介していきます。

また、背景にある考え方は検索システムに限らないものなので、検索を担当するかどうかによらず開発者の方は参考にしていただければ幸いです!

LIPS の検索機能

検索システムは、ユーザの入力した文字列(クエリ)に基づき検索結果を返します。構造化データの入った RDB と、文書検索ができる Elasticsearch などの DB を組み合わせて実装することが多いと思います。LIPS もそうです。

LIPS の場合、検索対象は商品や投稿、ユーザやブランドなどです。単に商品名やブランド名で検索するだけなら、そのものを見つければ良いのですが、ユーザはフリーテキストで探しているものを指定します。その結果、構造的な検索だけでは検索結果を上手く見つけられず、またそもそも何が良い検索結果なのかが曖昧です。

例えば「日焼け止め」と入力されれば良さげな日焼け止め商品を見繕い、「ニキビ」と入力されればニキビ対策をしたいのだと見抜き、「みきぽん」と入力されれば「かわにしみき」さん*1を見つけられる必要があります。

f:id:spinute:20190527143814p:plain

LIPS は3月に300万ダウンロードを突破し、現在までに80万件超のクチコミが投稿されています。ユーザがコスメやそのクチコミを見つける体験を支えるためには、お利口な検索システムが必要です。

指標の設計に使えるログの例

データ駆動な開発プロセスに馴染みのない方もいるかもしれないので、ログの話もしておきます。

LIPS のログ収集基盤はスタートアップでも出来る分析基盤で社長が紹介してくれたものです。ユーザの行動ログを記録し、それを集計して指標を計算できます。

例えば以下のようなログがあります。

  • どのようなクエリで検索したか
  • どの検索結果を見て、どれを選択したか
  • 遷移先にどのくらいの時間滞在したか

以降では、このようなログを使って、検索機能の評価に使う指標を設計していきます。

主要な指標、副指標

検索システムの文献を読むと、その評価はしばしばクエリと結果の関連度(relevance)を中心に説明されます。*2 他にも、レイテンシやメモリ使用量、あるいはユーザビリティなどの、一般的な指標も使われます。

一方、仕事でアプリを作るときには、ユーザ数や収益などの経営レベルの指標のことも考えなければいけません。

そして、これらの指標の間にはしばしばトレードオフがあります。

仕事では主要な指標としては経営指標を置き、これを改善するための手段として他の指標を参照するのが良いと思います。

LIPS はユーザからお金を貰うアプリではないので、ユーザ数・滞在時間・RR などを主要な指標としています。*3

主要な指標はゴールを明確にします。一方、プロダクト寄りのより細かい指標があると、個々の施策を仮説検証しながらゴールに近づいていくために役立ちます。この指標を副指標と呼ぶことにします。*4

副指標だけを見ていてはいけない

副指標に関する注意点として、それだけを見ていてはいけません。具体的な施策のことを考えていると視野が狭くなりがちですが、ゴールは主要な指標を改善することであり、副指標はあくまでそのための参考になる値として利用すべきです。

例を挙げます。CTR(Click Through Rate のこと。インプレッション数あたりのタップ数)は汎用な評価指標です。以前は AppBrew でも、検索結果の CTR 改善を目指していました。しかし、この数ヶ月、検索改善施策を経て CTR は日に日に下がっていきました。

施策を打つたびに下がっていく切ない CTR の様子
施策を打つたびに下がっていく切ない CTR の様子

この原因は検索結果を出せていないクエリが元々多くあったことです。 そのようなケースで検索結果を出せるよう改善を進めた結果、インプレッションが増え、CTR が下がりました。 一方で、検索結果にたどり着ける人は増えたので、この施策は成功でした。

f:id:spinute:20190527145057p:plain:w300
検索結果にたどり着けた人の割合

評価指標を設計する

デカルトは「方法序説」にて「困難は分割せよ」と言っています。問題解決の理論であるアルゴリズム論でも、分割統治は主要な設計パラダイムのひとつです。ここからわかる、主要な指標からより扱い易い副指標を導く一般的なアプローチは分割することです。

例えば、アプリの収益モデルを KPI に分割したものである KPI ツリーは、この発想に基づくものです。

https://d1b8ifz9kd2pqh.cloudfront.net/2016/02/Retention-Tree-Full-1-979x1024.png
アプリの KPI ツリーの一例(https://growthhackjournal.com/monetize/kpi-tree-for-app より引用)

では LIPS 検索システムの評価指標はどのように分割できるのでしょうか?汎用的な着眼点をいくつか紹介します。

ファネルで分割する

検索ユーザの動線を時間軸に沿って分割したファネルをもとに、副指標を設計できます。

LIPS の場合、ユーザは以下の手順で検索機能を使います。

  1. 検索窓をタップする
  2. 検索クエリを打ち込む
  3. 検索結果リストを眺める
  4. 興味があるものをタップする
  5. 見つけた結果を眺める

f:id:spinute:20190527005900p:plain

ファネルでの分割は、ユーザインパクトの見積もりにも役立ちます。

  • 前半ほどユーザが多いため、前半の改善ほどより多くのユーザに影響を与える
  • 離脱率が高い箇所ほど、改善の余地が大きい

定義式で分割する

例えば以下のような定義式を使って、副指標を設計できます。

  • 検索滞在時間 = 検索試行回数 * 検索試行あたり平均滞在時間
  • 検索試行回数 = 検索利用者 * 平均検索利用回数

特徴で分割する

ある側面に着目しログを分類することで、副指標を設計できます。

  • 検索利用者 = 新規ユーザ + 既存ユーザ
  • 検索実行者 = 結果をタップした人 + 結果をタップしなかった人(検索離脱者)

このとき分割の仕方によって結果の見え方が変わることには注意が必要です。

  • 新規ユーザと既存ユーザは、利用開始日からの日数にしきい値を設けて区別します。新規ユーザが定着していく様子は連続的であり、しきい値は恣意的なものです
  • 検索実行者をタップの有無で2値に分けるのではなく、タップの回数によって分類することもできます

https://1.bp.blogspot.com/-vI7t2-ddeZM/Wat2bTFu4UI/AAAAAAABGXw/P5C6jJfReNYaTz9GxIEMRg62CWvXZ_nZQCLcBGAs/s400/egg_separator_egg.png
卵の黄身と白身を分割するエッグセパレーター(いらすとや より)

LIPS 検索システムの評価指標

最後に、LIPS 検索システムの評価指標を具体的に紹介します。

まず、検索機能のゴールは、ユーザが対象を見つけ、その内容に満足することです。つまり、検索機能のユーザ価値を、ファネルに沿った検索動線の達成度または達成割合で定量化できます。そこで「検索試行あたり結果ページ滞在時間」を検索機能のユーザ価値としました。

副指標としては、例えば以下のものを設定できます(太字は特に重要だと思うもの)。

  1. 検索窓をタップする
    • 検索機能の利用率
    • 検索機能の平均利用回数
  2. 検索クエリを打ち込む
    • 検索候補のタップ率
    • 検索候補により入力を省略できた平均文字数
  3. 検索結果リストを眺める
    • 1件以上の結果を表示できた割合
    • 1ビュー以上の結果を表示できた割合
  4. 興味があるものをタップする
    • 検索離脱率
    • 検索試行あたりタップ数
    • CTR
  5. 見つけた結果を見る

余談ですが、指標を計算する際に使うログはユーザの鏡です。ユーザファーストの実践を目指す身として、ログを丁寧に扱い、深く理解することは欠かせないことだと日々感じています。

おわりに

エモいことを書いたついでに、takram の Shenu: Hydrolemic System という作品を紹介します。

www.youtube.com

これは「荒廃した未来の世界における水筒」をテーマにした作品だそうです。

水質汚染等により供給可能な水が極端に限られた世界では、現状の延長上にある水筒を考案することが非現実的に思われました。そこで、このような差し迫った環境において、人間が一日に排泄、排出する水分を極限まで少なくできれば、そもそも人体が必要とする水分を少なくできるのではないか、という結論に達しました。これが最終的に、人工臓器を含む新しい一連のプロダクト群に結実したのです。水筒を作るのではなく、人間の体を水筒と捉え、生存に必要な人工臓器を提案しました。このように、課題自体を見直すことにより、水筒という課題に対する新しい解釈が生まれたのです。

https://ja.takram.com/projects/shenu-hydrolemic-system/ より

問題を解くことと同じくらい、あるいはそれ以上に、正しく問題を定義することは重要です。そしてそれは難しく、また知的に面白いことでもあります。AppBrew では、データを見ながら事業目線で開発に取り組める仲間を引き続き募集しています!

*1:有名 YouTuber。誕生日が僕と同じなことで有名(ではない)

*2:例えば、Information RetrievalIntroduction to Information Retrieval が二大有名教科書ですが、いずれも relevance を中心に説明されています。

*3:余談ですが、AppBrew では会社・チーム単位で主要な目標を明文化しています。特に Measure What Matters という書籍で一躍有名になった「目標と成果指標(OKR, Objectives and Key Results)」というフレームワークを使っています。このテーマについては、原著または Google の公開している資料が参考になるので、興味のある方は是非参照してみてください。

*4:副指標は一般的な用語ではなく、ここで説明のために僕が勝手に定義した単語です。