検索サイトの検索ページのURL体系についての考察(Elasticsearchの製品哲学?の影響を受けた版)

はじめに

題名のとおり、検索サイトの検索ページのURL体系についての考察をしてみた。 バックエンドがElasticsearchでの検索を想定しており、ElasticsearchでのクエリDSLへの繋がりが良さそうなものを...という意味ではそうなのだが、"Elasticsearch"というのをタイトルに入れたのはタイトル負けしているかもで、すいません。

※そもそもそれなりのオープンなサイトのプロダクト環境では、Elasticsearchの検索エンドポイントを生晒しにすることはない。 検索サイトのUI側に至るまでは、間にラップしたAPIかましたりと、クリーンなアーキテクチャを指向することもあると思いますが、一方で、Elasticsearchの検索クエリはサーチのビジネスロジックを比較的素直に表現できる類のものだと感じているので、それはそれで生かしたいので、Elasticsearchの製品哲学のようなものに引きずられるのはヨシと考えている。

結論(僕の考えた検索サイトの検索ページのURL体系について)

結論というか考察の結果をまとめたものを先に書き出します。こんな感じです。

f:id:azotar:20181128000130p:plain

  1. プリフィックスを付けよう。できれば同じ探し物に関する検索はこのプリフィックスに集約しよう。
  2. パラメータには役割に応じた種類があり、クエリパラメータはできるだけ見て分かるものにしよう。昔のIEのようにURL長の限界も緩和されているし、逆にJavaScriptなどででリッチなUIが実現できる分、URLの引き回し範囲も限られて逆に最大長は必ずしも長くならない傾向だし。
  3. SEO的にはcanonicalを意識すればちょうど都合が良い。
  4. やりすぎない範囲で、セットになるデータは、1つのパラメータにまとめよう。

この結論に至った背景について、少し飛躍する&言葉足らずなのは承知だが、次節につらつらとりまとめます。

背景

検索ボックス

1BOXか複数BOXかは一つの分かれ目でしょう。当たり前か。 あるいは1BOXを基本に、絞り込み検索の選択肢付きか。

まあ、これは突き詰めていくとハマるので、プロダクトオーナーが好きに決めてくださいの方がうまく行きそう。 (ただし、ペルソナだったり、別のところで考察するような、データとシーンとゴールの検証とBOX数が噛み合っているかの点検はしましょうね。)

さて、一旦1BOXを例に考察を進めると、入れられるのがキーワード検索語になるわけだが、複数ワード入れられた場合に、サイトとしてANDかORかは決めておきたいところ。 でも、GoogleはじめANDが多いので*1、こだわってORにしても気づかれない/無用な混乱を招くかもしれないね。

表示モード変更

続いて、モード変更(検索結果の対象全体は変わらず、表示の方法の切り替え)について頭の整理をしてみる。

ソート条件の変更やローカル検索系での地図へのマッピング表示への切り替え、ECサイトでの画像表示や詳細表示モードへの切り替えがこれにあたる。

表示件数も潔癖に考えるとどうかなというところもあるが、おおまかに捉えるとこの範疇と考えよう。

「設計」の視点から見た、特徴としては、複数のサブモードの組み合わせはあれど、サブモードの中の選択肢は一つに決まるということ。

ECサイトでの例なら、表示件数は50件と20件が同時に選択されることはない。表示件数50件で画像表示モードというものはあれど。

時に、検索方法と表示モードが密接な関係になることもあろうけど、表示モードはあくまで表示モードなんだろうと思う。

絞り込み(ファセット)

続いて絞り込み(ファセット)である。

実のところ、ファセットについては次のような種類(分類)があると捉えたがどうだろう。

どういうファセットがあれば便利かというところを探求しつつ、それが次のどの種類にあてはまるか整理するのは全体のUXのバランスを考えるのには良いかもしれない。

  1. ORかANDか択一か→ ECサイトで「文房具」で検索した際に、「ペン」「ノート」...のようにどれかに絞り込むなら択一、いやいやユーザは「シャープペン」「ボールペン」どちらかは決めてなくて、書くものを探していると考えられるので、ORで検索できるべきでしょうという発想もあるかもしれない。ちなみに、「シャープペン」「ボールペン」ではなくて、「筆記用具」のように分類すべきではと言う話が出てくるかもしれないがここではその考察はしない。この流れで例える例が思いつかなかったので無理な例だが、「ペン」かつ「ノート」で絞り込むならANDに分類することになる。
  2. 検索結果の特定の属性をグループ化したものを絞り込み条件として提示か、ドキュメント全体や全文検索対象の属性から特徴的なワードをなんらかのランキングに従い抽出したものを(ある種のグループと見なして)提示か。
  3. 前項でいうグループ化は、実際の検索結果から導出するか。あらかじめ絞り込みパターンのマスタを用意しておき、それと検索結果を照らし合わせてグループ提示するか。 マスタを用意しておく考え方の場合、0件の場合にそもそも選択肢として表示するか、存在しないことも情報だと示すために「カッコ0」をあえて表示するか。
  4. 前々項でいうグループ化については、日付で言うと、今日から10日前、11日から20日前、...のように幅でグループ化されるものもある。また幅の大きさが一定でない場合もある。例えば、今日、昨日、 あるいは今日、昨日、今週、今月のような例もあるだろう。

※ここでは、簡単のために、純粋に「絞り込む」ものに話を絞りました。検索の幅出しやより良いおすすめ検索条件の変更はファセット風の選択肢としてUI表示したとしても別物だと思います。

Elasticsearchでは、基本的にはファセットの元ネタは、aggsで炙り出せる&SQLと異なり、aggsという考え方が独立して存在しつつもメインの検索条件と同じクエリ内で値を取得できるという便利なところなので、

パンくず

本当のトレーラー(遷移をたどる方式)とするかデフォルトの体系に従って表示するか、URLの上位パスに合わせて表示するか(この場合は、URLの体系が先かそのようなカテゴリ階層の体系整理が先かのニワトリたまご問題がある)あたりが定石だと思う。どれがおすすめかといえば、URLの上位パスに合わせて表示が自分は好きかもしれない。ただし、神経質になりすぎないようにね。

SEOとかユーザフレンドリーURLとか

キリがない世界(& 言うとボロが出る)なのでここでは引用も説明もしないけど、URLとかURIってリソースロケーターだと思うのですので、それらしくパスもクエリパラメータも設計すれば良いと思うのです。

ローカル検索の場合

ローカル検索の場合、検索エリアの扱いについて考察が必要かもしれない。

  1. 住所を中心にすえるかどうか。住所コードの体系の考慮や検索ワードで入れられるのは市区町村レベルまでとするかどうか。
  2. 鉄道駅の扱い、路線の扱い。
  3. ランドマークやスポットの扱い。
  4. 地域名や正式な住所ではなく慣習的なエリア名の扱い。
  5. 離島の扱い。
  6. 同一名の地名の扱い。→ ”港区”
  7. Geo検索の取り扱い。Geo検索に対応するなら、住所コード軸はやめて「座標」中心に考えるという手もある。
  8. 市区町村合併時の旧住所の扱い
  9. エリア入力ボックスの入力ワードはANDかORか。どちらだとしても、並びにどこまで意味を持たせるか。(今だったら検索エンジンの機能や住所確定ロジックで無駄に頑張るよりガイダンスを出した方が良さそう)
  10. 複数エリアへの検索対応。

この件は別途考察したい気がする。

*1:ワードによってはORぽく動くことはあるかもしれない