Airbnb: 最も利用されている機能がベストだとは限らない

http://nerds.airbnb.com/experiments-airbnb/

1 comment | 3 points | by WazanovaNews 3年以上前 edited


Jshiike 3年以上前 edited | ▲upvoteする | link

A/Bテストを繰り返したり、検索機能を磨いたりというのは、どのようなウェブ/アプリサービスでも注力するところではあると思いますが、Airbnbの取り組みを学んでいると、「自分のサービスにとってはどのような機能を選択肢に入れて、どのように選択するべきか。」については、当たり前に聞こえるかもしれませんが、よくよく考えて決めなくてはいけないポイントだと改めて認識させられます。

A/Bテストで、コンバージョン率の改善がすぐに見られた機能をサクっと選択してしまい、実は中期的にはコンバージョン率が変わらない(もしくは悪化する)可能性を確認しない。「ほとんどのユーザが価格帯順のソートを選択するから、検索機能は価格帯順の検索結果をデフォルト表示にすればよいだろう。」という意思決定をしてしまし(もちろんこれが正解なときもあります。)、他にベストな選択肢/検索ロジックがある可能性を追求しない。というような失敗は、ツールを導入するだけではなくせないので、自分たちのサービスにベストな策を導きだすために更にどうすべきか、落ち着いてもう一段深く考えるクセを関係者全員が常に忘れないようもつ必要があります。

とはいえ現実的には、深く考えても解釈 & 判断に苦しむような事例はあるもので、「調べたけどまだよくわからないね。」という経験は自分もよくありました。試行錯誤が必要な泥臭い分野ですよね。。

同社のTech Talkビデオで、A/Bテストの工夫検索機能の改善の取り組みが紹介されています。

1) A/Bテストの工夫

  • サービスの季節性、曜日ごとの違い、そもそもサービスが成長しているトレンドがある、などの要素の影響を排除するため、従来の機能を利用しているユーザ群と新機能を利用しているユーザ群を比較する。
  • 従来の機能を利用しているユーザ群に対して、新機能を利用しているユーザ群のKPIの差分の変化率推移を時系列で確認する。
  • P値(ビデオでは「二つのオプションに違いがないときに一定以上の違う結果がでてしまう確率」という説明がされてます。この確率が低いと「偶然である可能性が低い。」、つまり信頼性が高いと言えるかと。詳しく知りたい方はこちら)が、5%よりも小さくなるかどうかみている。(追記: この後、5%を超える場合でも数値が安定するようになるタイミングを見ているという説明があるので、P値が一定の数値以下でないとテストがNGというような判断をしているわけではなさそう。)
  • 検索時に価格帯をスライダーバーで絞り込める機能をつけているが、その幅を$10-$300から$10-$1,000に変更してみた。ほどなく予約率は4%改善し、p値も5%を切った。しかし時間がたつと、予約率の改善はプラスマイナスゼロに近づき、P値は40%になった。このようにA/Bテストの結果が時系列で変動することは実はよくある。新しい機能に出会ったら、最初はとりあえず触ってみるだけのユーザもいるので、それが改善率やP値に影響を与えることもある。結果の解釈はそれぞれの場合の文脈次第なので難しい。P値が5%を切ったらすぐにA/Bテストを終了するという考え方は危険だということはわかる。P値の変動パターンは様々だが、少なくともP値の変動が安定しないうちは結果の判断は早計と思っている。(最終的には予約改善率がニュートラルだからといってダメな訳ではないと判断したとのこと。スライダーバーは現在サイト上は最大$1,000になっている。予約率が変わらなくても平均予約単価があがったので効果があるということだったのかもしれないけど、そこまで詳細は説明されてなくて残念。P値が安定するのにかかると予想される日数?はAirbnbの各係数をもとにシミュレーションしてるっぽい。)
  • 結果を検証するときに内訳の確認をすること。かつて、全体でネガティブな結果とでたA/Bテストが、ブラウザごとの内訳を確認すると、特定のブラウザでのバグが原因だとわかった。
  • ユーザアクションのステップごとの分析をする。Airbnbの場合、「検索 -> 予約完了」といってもその内訳は、「検索 -> 部屋の持ち主へのコンタクト -> 持ち主の了承 -> 予約アクション -> 予約完了」までの各ステップがあるので、どの段階でコンバージョン率が変わっているのか確認する。
  • 内訳を検証しようとすると、「サンプル数の減少」「特定のユーザアクションの計算は大変」「外部要因の影響は?」などの課題がどんどんでてくる。小さな影響の調査には回帰分析が役に立つ。
  • サードパーティベンダーから提供されているA/Bテスト結果がある場合、そのデータも念のため検証する。同じ仕様で、サードパーティのシステムで計測しているユーザとそうでないユーザのA/Aテストをして比較することもある。
  • Airbnbの機能はログインせずに利用できるものも多いので、同じユーザが複数カウントされる可能性がある。そういうユーザはかなりアクティブ。各セグメントごとのサンプルデータの取り方を統一しないと、結果にその影響がでてしまうことがあった。(追記: サンプル数が多ければ分散してそれほど影響でない気もするけれど。。例えば、セグメントを携帯/PCでわけて、携帯に超アクティブユーザがたくさん複数カウントされてしまい、数字が偏ったということがあったのか?質問に対して「Airbnb独自のことだったのであまり参考にならないかも。」とだけコメントして、どういう事象だったのか詳しく説明してくれてなかったのですっきりわからず。。2) のビデオの質疑で、検索ロジック変更の影響の計測レポートを自動作成するプログラムを走らせるときは、「ヘビーユーザは(結果が偏る可能性があるので)別枠で集計している。」という発言をしているので、サンプルの取り方は色々工夫しているっぽい。)

2) 検索機能の改善

  • リスティングされているのは60万件。宿泊予約にコンバージョンするユーザの中央値は、1日3セッションで20件閲覧。
  • リスティングされている部屋のクオリティについては、写真 / レビュー結果 / 場所の評価 / クリック率 / クリック後のユーザのアクション(部屋のオーナーへのコンタクト率、予約完了率)などによって判断している。
  • 宿泊後のレビュー項目の中にあるロケーションの評価から、地域ごとのロケーションレベルのデータを生成している。
  • 特定の都市の境界からはずれていても、ユーザがその街に関連すると思うはずという案件は相関係数をもたせて管理している。(都市ごとの絞り込みの工夫、例えばサンフランシスコと言ったときに、どの地点を中心にどの密度でリストアップするべきか、市周辺のお薦め物件をどう追加すべきかについては、「ユーザに最適な検索ロジックを徹底的に深堀りして考える」で紹介してます。)
  • ユーザの予約パターン(この場所を予約した次にこの場所を予約する)、検索ワードの関連把握(日本語入力した海外の都市を英語表記データで把握)、などのシグナルも考慮のうえ、1) そのクエリが予約にコンバージョンする確率、2) そのクエリで予約する物件がみつかるか、3) 最適なリスト数、4) クエリの対象となる場所と、実際に予約する場所の相関関係などをモニターしている。
  • 検索結果のパーソナライズ化として、そのユーザとのソーシャルネットワーク上でのつながりがあるユーザが既に宿泊した部屋も、つながりの強さの度合いの違いも考慮したうえで反映している。
  • 部屋の持ち主が好む(= 承諾の可能性をあげる)予約パターンの把握。「どれくらい前に予約するとよいか」「何日間泊まるの予約を承諾しているか」「宿泊予約間の間隔はどれくらい空けるとよいか」「週末の予約も受け入れているか」「何人宿泊しているか」などをマッチングロジックに反映。
  • 値段ごとのソートは9.9%のユーザから利用されていたが、上記のような様々なロジックの工夫の効果をさげる可能性があるので外したところ、予約率が2.2%向上した。
  • 都市ごとの繁忙の季節性を考慮に入れる実験中。

#airbnb

Back