本記事は Algolia Advent calendar 14日目の記事になります。

こんにちは、Algoliaサポートエンジニアの半田です。 Advent calendarも無事折り返しを過ぎましたね。 気づくと年内の営業日も少なくなってきて、激動の2020年も終わりが近いと思うと感慨深い気持ちでいっぱいです。

さて、本日の記事ですが、私がAlgolia の機能の中でも一番好きな機能である Rules について取り上げてみたいと思います。 Rules はランキングストラテジーの結果に対し、一定の条件にマッチする場合にその結果のカスタマイズを行うことができる機能です。 と聞くと一見地味な機能のように思われるかもしれませんが、実際のところそのユースケースは幅広く、とてもパワフルな機能です。 個人的にはその凄さは、以下のような点にあると思っています。

• インデックス側の設定のみで対応でき、フロントエンドでのクエリ変更なしに結果をコントロールできる
• 影響範囲を明確にコントロールできるため、想定外の副作用などが起きにくい
• 検索結果の柔軟なカスタマイズが行え、拡張性が高い

Algolia では透明性の高いタイブレーキングアルゴリズムのおかげで、クエリに対する検索結果のランキングの予測や理解がしやすいことは前々回の記事にてご紹介しました。 Rules を使うことにより、特定の条件を満たすケースでこのランキングに追加で恣意的な操作を加えることができるようになり、結果として非常に細やかなランキングのコントロールが可能になります。

なお、ご利用にあたって Algolia の料金プランとしてはPremium プランが必要になります。Freeプランでもルール数・一部機能制限を前提にご利用いただけますが、Standardプランではご利用いただけない点にご注意ください。

それでは、Rulesで具体的にどのようなことができるのか見てみましょう。

Rulesの基本

Rules は Condition (条件)と Consequence (結果)のペアで記述されます。 Condition はその名の通りルールが適用される条件を指定するものです。 Consequence は実際にランキングに対して適用されるカスタマイズの内容を設定します。 すなわち、「もしクエリがXなら(condition)Yを適用する(consequence)」というのが基本構造です。 ダッシュボード上ではRulesメニューより新規作成することができ、ルールごとに1つないし複数のConditon、Consequenceを記述していく形になります。

それでは、もう少しCondition、Consequenceの詳細を見てみます。

Condition

Condition にはクエリパターン、コンテキスト、フィルター（現在はベータとして提供）の指定が可能です。 すなわち、以下のような状況を Rule の Condition として取り扱うことができます。

• クエリがXなら
• クエリコンテキストがXなら
• フィルターの値がXなら

ダッシュボード上では使用したいConditionのトグルボタンを有効にすると該当の condition を入力できるようになります。 右上のゴミ箱ボタンを押すとConditionが削除でき、何も指定しなければConditionlessルールとして動作します。

上記スクリーンショットで一番上に見えるクエリパターン Conditionはクエリに特定の単語が含まれる場合にルールを適用できるConditionです。 このCondition は is, contains, starts with, and ends with のいずれかの anchoring とともに設定します。

例えばConditionとなるクエリパターンが sale、anchoring が contains の場合には "sale" や "smartphone sale"、"sale samsung" といった検索クエリに対しルールが適用されます。

この状況で、anchoring のみを変更するとマッチするクエリが変化します。例えば anchoring がstart with であれば "sale" または "sale samsung" が適用対象のクエリとなりますし、end with を指定すると "sale" と "smartphone sale" が適用対象となります。 個々のキーワードは部分一致には対応しないため、例えば"salesforce" といった検索クエリはこのクエリパターンのConditionにはマッチしません。

これに加え、{facet:color} のように指定することでクエリ中に含まれる facet となるような語を検出することも可能です。(参考)

コンテキスト conditionは、クエリパラメータの rulesContexts を介して渡された文字列を使用する Conditionです。 一般的にはクライアント側の環境情報、例えば 'mobile'、'desktop'といったプラットフォーム情報や言語設定などに応じてルールを変更したい場合に活用することができます。 使用するにはクエリを投げる側で該当の値を渡す処理を実装する必要がある点にご注意ください。

Consequence

続いて、Consequenceについてです。 Consequenceはその適用タイミングによって、大きくPre-processingタイプのものとPost-processingタイプのものに分けられます。

Pre-processingはクエリそのもの、あるいはクエリパラメータに対して検索処理が行われる前に影響を与えるものです。 Pre-processingで実行できる Consequence としては以下のものがあります。

• Add Query Parameter : クエリパラメータの追加
• Remove Word : 検索キーワードの削除
• Replace Word : 検索キーワードの置き換え
• Replace Query : クエリ全体の置き換え
• Filter/Boost Matching Attributes : 検索ワードにマッチするアトリビュートのブーストもしくはフィルタ

これに対し、Post-processingは検索処理実行後、ランキング付された結果に対し追加で処理を施すことができるものです。 Post-processingで実行できる Consequence としては以下のものがあります。

• Pin an item （アイテムのピン留め）
• Hide an item （非表示アイテムの指定）
• Return Custom Data （カスタムデータの返却）

このうち、カスタムデータはやや他のアクションとは毛色が違い、検索結果中の customData というプロパティで任意のデータを返せるようになります。 ユースケースとしてはフロントエンド側でこの値を参照してバナーを表示させたりリダイレクトするといった処理が可能になります。

ダッシュボード上での consequence の設定画面は以下のような雰囲気です。

Additional settings

上記 condition、consequence のほか、各 Rule には以下の設定を適用することができます。

• Description : ルールの説明を記述する
• Timeframe in UTC : ルールが有効となる期間を指定する
• Pinned items must match active filters to be displayed : 特定のアイテムをピン留めするconsequenceで、フィルターにマッチする場合にのみピン留めしたアイテムを表示させる

Rules のユースケース

とまあ様々な Condition、Consequnce が利用可能な Rules ですが、リリース時の Blog を読んでみると特にカバーしようとしているユースケースは以下の2つに集約されます。

• 検索意図の検出 (detecting intent)
• Merchandising

検索意図の検出

一般的に検索機能を利用するユーザーの意図は「検索クエリ」 という形で表現されますが、検索クエリに含まれる一部の語についてはフィルターなどの形で扱うほうが効果的な場合があります。 例えば「ドレス ブルー」のようなクエリが入力された場合、「ブルー」というキーワードは商品の色を意図して追加されていると理解できます。しかし、そのまま検索キーワードとして扱ってしまうと色以外のブランド名などにもマッチしてしまい、検索結果にノイズが混ざる可能性があります。

従って、より検索意図に即した検索体験を提供するため、以下のようなルールを設定することができます。これにより、インデックス側の処理で該当キーワードをフィルタとして扱うことになります。

• Condition:
  • 検索クエリが「ブルー」を含む(contains)場合
• Consequence(s):
  • color:blue という optionalFilters を適用して該当するアイテムのランキングをブーストする
  • 検索キーワードから「ブルー」を取り除く

該当ルールをRules API で使用できる JSON で表現すると以下のような形になります。

Copycopy code to clipboard
1{
2  "conditions": [
3    {
4      "pattern": "ブルー",
5      "anchoring": "contains",
6      "alternatives": true
7    }
8  ],
9  "consequence": {
10    "params": {
11      "optionalFilters": "color:blue",
12      "query": {
13        "edits": [
14          {
15            "type": "remove",
16            "delete": "ブルー"
17          }
18        ]
19      }
20    },
21    "filterPromotes": true
22  },
23  "enabled": true,
24  "objectID": "rule-to-detect-blue"
25}

同様に、例えば 「格安」というキーワードがあったら自動で価格フィルタを適用したり、出力や規格といった情報を検知してフィルタを適用することで検索体験を改善できるケースがあります。

こうしたクエリ改善の入り口としては Search Analytics ダッシュボードを見ていただくことがおすすめです。Search analyticsでは No result になっている検索クエリの情報などが確認できるので、そうした検索クエリのキーワードを入れ替えたりクエリ全体を書き換える、といった対応に活用が可能です。また、Click Analyticsを使用するとクリック位置の情報もとれるので、Promotion等によって改善が必要そうなクエリがより確認しやすくなります。

Merchandising

Merchandising のユースケースは検索サービスの提供側の意図を検索結果に反映させるものです。 例えばeコマースのサイトを想定すると、発売直後に「iPhone」というキーワードで検索する顧客は最新のiPhoneを買いたい可能性が高いと考えられます。 しかし、従来のカスタムランキングで使われるような売上やレビューといったデータは存在しないため、全体のランキングに影響を及ぼさずに新機種を上位に持ってくることはカスタムランキングだけでは難しい可能性があります。

こうした場合に、以下のようなルールを設定することで該当キーワードをフィルタとして扱うことができます。

• Condition:
  • 検索クエリが「iPhone」を含む(contains)場合
• Consequence(s):
  • 新しいiPhone を1番目にピン留めする

このルールを API用の JSON で表現すると以下のようになります(ルール内のobjectIDは仮のものです)。

Copycopy code to clipboard
1{
2  "conditions": [
3    {
4      "pattern": "iphone",
5      "anchoring": "contains",
6      "alternatives": true
7    }
8  ],
9  "consequence": {
10    "promote": [
11      {
12        "objectIDs": [
13          "4564272002"
14        ],
15        "position": 0
16      }
17    ],
18    "filterPromotes": true
19  },
20  "enabled": true,
21  "objectID": "rule-to-promote-the-latest-iphone"
22}

また、特定の検索クエリに対してカスタムデータを活用してバナーを表示させるといったことも可能です。例えば Apple 製品に関する検索キーワードに対し、特設ページへのリンクが用意されたAirPods Max の広告バナーを見せるといったようなユースケースが考えられるでしょう。バナーの表示にはフロントエンド側の実装も必要になりますが、InstantSearch.js ではカスタムデータを扱える queryRuleCustomData Widget も用意されています。

この他にもドキュメントでは Conditionlessルールを使ってデフォルトサーチパラメータを指定したり、エンドユーザーのプラットフォームに合わせて検索結果をカスタムするといったユースケースもご紹介しています。上記に留まらず様々な使い方ができる機能ですので、ぜひこれに縛られず新しい使い方を模索してみてください。

なお、Merchandising ユースケースでの注意点として、もし多数のアイテムをピン留めしなければならないような状況があったとしたら、それはもしかしたらRuleを増やすことではなくカスタムランキングを見直すことで対応すべき状況かもしれません。Rulesによるカスタマイズは便利ですが数が多くなるとその影響の把握が難しくなりますし、なによりランキングのベースとなるランキングクライテリアが適切でない可能性があるため、このような状況ではカスタムランキングの見直しを検討いただくことをおすすめします。

Visual EditorとManual Editor

ちなみに、ダッシュボード上からRuleの作成画面を開くと、以下のようなエディタ選択画面が表示されます。

このうち、Visual Editor は今年追加された比較的新しい機能で、Rulesの marchiandizing 用の機能に特化し、GUI操作で設定できるようにした機能です。Manual Editor 上では例えば特定のカテゴリをブーストさせる操作などは json でフィルタを記述する必要が有りましたが、Visual Editorを使うことでそうした記述を行うことなく、直感的に検索結果に対する Rule 設定を行うことができます。 設定できる項目としては Manual Editor の方が豊富なため、上記も踏まえて使い分けていただけると良いかと思います。

なお、Rules を含む Algolia の機能はほぼすべて API 経由で操作でが可能です。このため、Shopify や Magento 用の Algolia extension でも Merchandising toolという形で Rules の作成や管理が可能になっています。

Rules の動作確認

Rules を作成したら dashboard で Condition に該当する検索クエリを投げてみてください。 Ruleが適用されると以下の画面のように該当の Rule の情報が表示されます。

一時的に Rule を無効にしたり、rulesContext を渡したい場合には +Add Query Parameter の "Search" タブメニューから該当のパラメータを操作することが可能です。

また、複数のRuleのConditionやConsequenceが衝突するケースもありますが、こうした場合は Precedence logic に従って処理が適用されます。こちらの詳細は、リンク先のドキュメントをご確認いただければと思います。

まとめ

ということで今回の記事では Algolia の Rules について解説してみました。 Rules は非常に強力かつ柔軟に、検索結果のカスタマイズを可能にしてくれます。また、拡張性の高い機能となりますので、是非今後の機能アップデートにも注目してみてください。