Operators

For every field, you can add an operator to match the content of that field in a particular way.

The currently supported operators are:

• match – Optimized for returning most relevant results and applies common text matching techniques. It works on searchable string fields, which are fields that should contain large chunks of text. It returns more relevant results than contains and returns more results in general, which offers a better user experience for site visitors. Optimizely recommends the match operator as a default operator for site search.
• contains – Performs full-text search on a word or phrase, with support for language stemming when you add the the locale parameter. It matches on terms that are tokenized by word boundaries according to UAX #29: Unicode Text Segmentation. This means that when matching on a term with a leading or trailing punctuation character in a term, these characters are ignored. It is the recommended operator when doing full-text search.
• eq – Matches an exact literal value, but the value is case-insensitive but results matching case are ranked higher.
• notEq – Retrieves results not matching with an exact literal (but case-insensitive) value.
• gt – Retrieves results with matches that have a value which is greater than the value.
• gte – Retrieves results with matches that have a value which is greater than or equal to the value.
• lt – Retrieves results with matches that have a value which is less than the value.
• lte – Retrieves results with matches that have a value which is less than or equal to to the value.
• exist – Matches results that have this field with a value.
• startsWith – Retrieves matches that start with a certain value (prefix). It is case-insensitive.
  Example: startsWith: "eng" will match with "English" or "english", but also "engineering".
• endsWith – Retrieves matches that end with a certain value (suffix). It is case-insensitive.
  Example: endsWith: "lish" will match with "English" or "bullish".
• in – Matches with one or more exact literal (case-sensitive) values in a list.
  Example: in: ["word1", "word2", "this is a phrase"]
• notIn – Returns results that do not match with one or more exact literal (case-sensitive) values in a list.
  Example: notIn: ["word1", "word2", "this is a phrase"]
• like – Matches substrings with wildcard support. Example: % to match on 0 or more characters, _ to match on any character.

📘

Important notes on leading wildcards

For fields with the type SearchableStringFilterInput, leading wildcards only match on the whole value (alphanumeric string or single token) when wrapped with both a leading and trailing % character, so it will not match on a prefix within a word. Leading with only wildcards is not supported at the beginning of a whole value (like single word and sentence) and will result in an error. However, leading wildcards are supported for words within a sentence, just not a phrase.

Examples:
- like: "%app%" will only match with whole words like "app", "applications", "apple", "apples", and so on. It will also match a phrase like "Optimizely apps are most awesome!".
- like: "Course %ollaboration Mad% Simple" is an example of a sentence with a leading wildcard for a word within it, and will match on "Course Collaboration Made Simple".
- like: "%ears" is a leading wildcard with a single word and will result in an error.
- like: "%Course Collaboration Mad% Simple" is a sentence starting with a leading wildcard and will result in an error.
- like: "%_ourse %ollaboration Mad% Simple%" is a phrase containing a leading wildcard in a word and will result in an error.

For fields with the type StringFilterInput, matching (on a substring) with a leading wildcard is supported.

Examples:
- like: "%pp%" will also match on "app", "applications", "whopper", and so on.
- like: "%ears" will match on "ears", "bears", "years", and so on.