一休.com Developers Blog

一休のエンジニア、デザイナー、ディレクターが情報を発信していきます

閲覧メインのページを検索メインのページに統合しました

こんにちは、プロダクト開発部の野口です。

一休にはたくさんの施設紹介ページがあるのですが、その中でもキュレーションページという流入数が高いページがありました。それをメイン動線であるリストページに統合したので、その経緯や裏側をご紹介します。

一休の施設掲載ページはたくさんある

一休には施設をまとめて掲載するページがたくさん存在します。

リストページ(メイン動線)

https://www.ikyu.com/area/ma000000/t105/si1/?adc=1&asc=01&cid=20221008&cod=20221010&hoi=1,2&lc=2&mtc=003&per_page=20&pn=1&ppc=2&rc=1

キュレーションページ

https://www.ikyu.com/theme/t105/

観光ページ

特集ページ

などなど。。。

その中でも今回はキュレーションページをリストページに統合したというお話です。

どうして統合したの?

キュレーションページは検索するためのページというよりも、検索エンジンからの流入口として用意されているものになります。そのため閲覧数は一休の中でもかなりいいほうなのですが、受動的な情報ばかりなので残念ながら予約までたどり着く割合は低かったのです。

一方でメイン動線であるリストページは検索に特化しており、ユーザが能動的に欲しい情報を要求し、的確な情報を表示できます。そのため予約までたどり着く割合も高く、メイン動線としての役割をしっかりと全うしています。

この2つを統合することで流入数と予約割合のどちらも高めたいというのが狙いになります。

苦労したこと

キュレーションページというのは、「地域xテーマ」ごとにページが生成されており、施設はランキング形式で表示されています。(先に掲載した画像は各キュレーションページの親ページになります)

一方でリストページはさまざまな条件で検索ができるのですが、キュレーションページと同じように「地域、テーマ」による検索もできます。しかもランキング形式での表示もできるため、キュレーションページと同じようなページを再現できます。

しかしながら、同じ条件で検索してもキュレーションページに表示される内容と異なることがあったのです。

原因はランキング生成ロジックがそれぞれのページで異なっていたからです。

もちろんどちらも八百長ということはなくデータに基づいてランキングを生成しているのですが、細かい条件が少しずつ異なり、結果別の施設が表示されてしまったのです。

実装方針ですが、キュレーションページには親ページが存在し、親ページでもランキングを掲載しており、その親ページは残すという前提がありました。そのためリストページにキュレーションページのロジックを持ってくる必要があります。しかし一休ではアーキテクチャを更新している最中で、キュレーションページ側は旧アーキテクチャ、リストページ側は新アーキテクチャと別れてしまったためロジックの移植はしないことにしました。代わりにキュレーション側のアーキテクチャで「エリアIDとテーマID」を受け取ってランキングを返すAPIを作成し、それをリストページのアーキテクチャが叩くことにしました。

進捗は順調・・・かと思ったら・・・

大体のページではランキングの結果が一致するようになり開発は順調かと思われたのですが、一部のページに限ってランキングの結果が合わない状況に直面しました。

キュレーションページのURLをよくよく見てみると、なにやら見たことない数字がいました。

https://www.ikyu.com/theme/a140000/g10/101/

「a140000」は東京を表すエリアIDで、「101」というのがテーマIDになります。「g10」は何者だ・・・?

キュレーションページに詳しい方に聞いてみると、どうやらキュレーション関連のページ限定の概念であるジャンルIDをいうものもページ生成に影響しているようで、「地域xテーマ」ではなく「地域xテーマxジャンル」で生成されているとのことでした。

ここで困ったことが起きました。

APIの方は単にジャンルIDも指定できるようにすればよかったのですが、リストページではジャンルIDという概念がないため、そもそもAPIのパラメータに含めることができなかったのです。

ジャンルIDを無視することも検討したのですが、それだとキュレーション親ページに表示されている施設とリストページに表示されている施設が異なってしまう可能性があります。一休ではユーザファーストを掲げているため、そんな体験は許されません。

そこでリストページのアーキテクチャにジャンルIDという概念を組み込むことにしました。「リストページ」に組み込むのではなく、「アーキテクチャ」に組み込みます。このため当初予定していたよりも多くの改修が必要になり、リリース予定日も延長してしまいました。

ですが、最終的には要件を落とすことなく、ユーザ体験も悪化させずにリストページに統合することができました。先のリンクを開くとリダイレクトしてリストページが開くのですが、「g10」の部分を変えることで結果が変わることを確認できると思います。

統合を終えて

今回の統合では要件を落としたり、無理やり実装したりという部分もいくつかあったためちょっと悔しい思いも残っています。

しかし訪れた人が予約した割合を比較してみると、統合前に比べて約1.6倍ほどに増えていました。少しでも使い勝手が良くなったと思い、端的に嬉しかったです。

今後のプロジェクトでもより良い体験を提供できるよう精一杯努力して参ります。

hrmos.co