Search requests filters (Air tickets)
Search requests filter — a plugin for the "Air Tickets" component of the Websky system.
Contents
Purpose
Search filters forbid undesirable searches for the agency.
The combination of conditions with different parameters (continents, countries, departure and arrival airports, type of flight, range of departure dates, days of week, flight legs) allows flexible adjustment of filters application to search queries.
Examples of use
- Restrict search to only the most popular destinations when selling with meta search sites.
- Reducing the cost of paid search transactions.
- Improvement of conversion.
- Reducing server load.
Work principle
The search request filter prohibits searches which the agency has defined by the filtering rules (see the article Search (Air tickets) for more details about search stages).
Each search query is checked by filtering rules before being sent to GDS.
As a result of the filter action, the search is either interrupted, i.e. the request is not sent to the GDS, or allowed, i.e. it is sent to the further routing (see Search (Air Tickets)).
Order of search queries filtering.
.
After the user starts the search on the search form:
- The Search Result Filter checks the search request parameters for compliance with the parameters of each blocking filtering rule
- If the search query parameters meet all conditions of at least one exclusionary filtering rule, the search is prohibited.
- If the search query parameters do not match any of the rules, the search is allowed.
- After checking the blocking rules, the allowing rules are checked.
- If the search query parameters meet all conditions of at least one filtering rule, the ban is removed and the search is allowed.
- For a filtering rule to work, all the filtering conditions specified in the rule must be satisfied.
- For a search query to be aborted, at least one filtering rule is sufficient.
- To cancel the ban on favorite searches, you need to specify an allow rule that will start the filtered search query.
If the search is interrupted by the filter, the user will receive a message Nothing was found on this request. There will be a message in the search log prohibited by the filter:
Warning "Search aborted: not allowed by request filters (FILTER_NUMBER)"
If the search is allowed by the filter, there will be a message in the log of the search allowed by the filter:
"Search allowed by request filters (FILTER_NUMBER)"
where FILTER_NUMBER — rule number.
Logging order of search request filter's work.
- All blocking rules are checked in order, as soon as a triggered rule is found, all previous (i.e. rules checked earlier) and the current, applied, request filter rule are logged.
- If a single blocking rule was applied, the allowing rules are checked in the same order and the ones checked with the applied rule are logged.
- Only checked rules are logged.
- If the rules coincided in all the features being checked, and a triggered rule was found in those rules, then the check is not carried out further, and therefore no untested rules are logged.
Request filters work for all types of routes, can be applied to segments or legs of the flight.
Search request filter operation is a procedure which will be performed for filtered search requests.
Search requests filter - a combination of conditions, at simultaneous execution of which the assigned action will be applied to the search request - the request will be interrupted or allowed.
Filter condition — the aggregate of a parameter, its properties and the specified values.
|
| Creating result filter |
|
| Example of search request filtering condition |
Rule operation mode - rule operation mode:
- Blocking - prohibits search if the search request meets the filter conditions.
- Allowing - allows you to search for directions prohibited by the search filters if the search request meets the filter conditions. Works as an exception to prohibiting rules of search request filtering - cancels banning of filters for search requests with specified parameters.
|
| Example of a banning filter for search requests |
|
| Example of a search request allowing filter |
Condition parameter — the sign by which a search request will be checked during filtering.
Condition property — the rule of comparison of the search request parameter with the values specified in the parameter condition. Condition property is determined by the way the values are specified:
- matches with (if you specify values with "Selected" option) - the filter will get only those search requests whose parameters correspond to the specified value.
- does not match with (if you specify values with "All but" option) - the filter will get only those search queries whose parameters do not correspond to the specified value.
Condition value — one or more specific parameter objects for comparison with a search request: specific continents, countries, airports, etc. If several values are specified, they are considered as alternative.
|
| Example of a filtering condition for search requests with the "does not match with" property. |
Attention!
- Allowing rule only allows search requests that have been filtered out by blocking rules.
- If there is one leg in the route, it has the sign of both the first and the last leg at the same time.
- If "Off" is selected for the parameter, the parameter has no effect on filtering.
Enabling search filters
Search request filters for user/agency are enabled by the option Request filters are enabled in the Product control → Avia tickets→ Processes→ Search process → Fine tuning section.
Creating search request filtering rules
Search requests filtering rules are created and edited in the section Product control → Avia tickets→ Processes→ Search process → Inquiries filters.
To create a filtering rule:
- Click Create new record button.
- Specify filtering conditions.
- Click the button Create new record at the bottom of the page.
The list of created filters of search requests is displayed in the table in the section Product control → Avia tickets→ Processes→ Search process → Inquiries filters.
|
| Search requests filtering rules |
Search request filtering options
- Allowing filter - switches to the allowing mode of the rule. The requests filtered by exclusion rules will be resolved if the search request parameters match those of the allowing filter.
- Departure continents - search requests with departures from specified continents will be filtered out/allowed.
- Departure countries - search requests for flights departing from the specified countries will be filtered out/allowed.
- Departure airports - search requests for flights departing from the specified airports will be filtered out/allowed. As values, you can specify particular airports or aggregation airports - cities ("Moscow-Domodedovo, Berlin-Tegel" or "Moscow, Berlin").
Attention! If an aggregation airport, e.g. MOW, is specified in this parameter, the filter will be triggered only for search requests where the aggregation airport is specified. For a request like DME-LED, this filter will not be applied. If you want the filter to trigger also when searching for flights departing from a particular airport, you must specify airport codes, for example DME/SVO/VKO.
- Arrival continents - search requests for flights arriving on specified continents will be filtered out/allowed.
- Arrival countries - search requests for flights arriving in the specified countries will be filtered out/allowed.
- Arrival airports - search requests for flights arriving at the specified airports will be filtered out/allowed. As values, you can specify specific airports or aggregation airports - cities ("Moscow-Domodedovo, Berlin-Tegel" or "Moscow, Berlin").
Attention! If an aggregative airport, e.g. MOW, is specified in this parameter, the filter will be triggered only for search queries where the aggregative airport is specified. For a query, e.g. LED-DME, this filter will not be applied. If you want the filter to trigger also when searching for flights arriving at a particular airport, you need to specify airport codes, for example, DME/SVO/VKO.
- Flight type - search requests with specified route types will be filtered out/allowed:
- One way - search requests with specified route types will be filtered out/allowed:,
- Round trip,
- Combined.
- Departure date after - search requests for flights with departure after the specified date will be filtered out/allowed.
- Departure date before - search requests for flights with departure before a specified date will be filtered out/allowed.
- ""Days of the week"" - search requests for flights, where the date of departure or arrival falls on the selected days of the week, will be filtered out/allowed.
- Check destinations (legs) - a way to check the rule parameters by legs:
- All - filtering conditions are checked by all legs (default value). The rules on all legs will be checked. For example: the country of departure: All except Ukraine (UA) filter is disabled. This rule will be checked for all legs, and in this case the request for a IEV-MOW-IEV route type will be filtered, because the second leg has a departure from Moscow.
- First - filtering conditions are checked only for the first leg of the flight. If you consider the same example, if this setting value is selected, IEV-MOW-IEV (RT) or IEV-MOW-PAR (CT) routes will already be allowed to be searched.
- Last - the filtering conditions are only checked for the last leg of the flight.
- All except the first and last (for complex routes) - the filtering conditions are checked for all intermediate flight legs.
Note: If there is one leg (OW) in a route, it has both the first and the last leg.
- Use airline's schedule - allows (or disables) search requests by destinations that correspond to the schedule of the selected airlines in the given details. For more details see section Request filter by airline schedule.
- Profile Package Numbers from Websky - permission (or prohibition) of search requests for selected packages. For more information, see section Request filter by Websky requisite packages.
- Number of passengers with a seat greater than X people - permission (or prohibition) of Websky search requests if the number of passengers with a seat greater than specified in this parameter.
Request filter by airline schedule
To use the airline schedule for allowing the search to start:
- Create a rule that forbids search in all directions.
- Create a rule that allows search on directions of the airline timetable:
- set the attribute of the allowing rule
- specify the requisites to load the schedule listed with a hyphen:
- IATA airline code (Supports Cyrillic characters input),
- GDS - specify (if necessary) the value: SIRENA.
- agency identifier in GRS (PCC, Client Id, etc.).
- Press the "Enter" key.
Value format: "<IATA airline code>"-"<GDS>"-"<agency identifier in the GDS">.
Example Values: AA-SIRENA-1234.
You can set no more than 3 values in one rule.
For correct operation of the schedule request filters it is also necessary to configure the airline's schedule request filters in Websky. It means to create a rule in the router for packages which are specified in request filters. In this case it is necessary to specify airlines for transmission as obligatory in GDS, the scheduled filters for which are configured.
At testing it's possible to use the following format of values: "<IATA airline code>"-"<GDS>"-"<agency identifier in GDS>"-"<Query execution environment>" for using the required environment (CERT or TEST), PROD is the default environment.
As a result, the search will only run on routes and dates that the airline has flights on. Not only the destinations are used in the schedule, but also the days of the week, on which the airline operates flights to destinations.
When segments are combined with a docking segment, the date of departure of the second segment on the shoulder shall be equal to or greater than one day relative to the date of departure of the first segment.
Attention! The schedule upload has been implemented for GDS Sirena Travel, Travelfusion, Navitaire, HITIT and Farelogix.
Filter requests by requisite packages from Websky
The +package numbers from Websky parameter allows you to enable application of rules to specific requisite packages.
To use this filter, you need to enter the numbers to the requisite packages field. If you want to apply a rule to several packages at once, they are written by commas. After you have set up the settings, this filter rule will be applied only to the packages listed. The rule will not be applied to the whole search and other packages not specified in this setting.
|
| "Use airline schedule and Websky requisite package number filter" filter |
Attention! Settings +Use airline schedule and +Numbers of requisites packages from Websky work only on the Websky side and are activated when the setting Websky search query filter is enabled (see the section Enable Websky search query filters). If this setting is not enabled, the parameters will be ignored.
.
Attention! If the search was blocked after checking all the rules without binding to packages, then further checking of rules with binding to packages is no longer performed.
Attention! Setting +Use Airline Schedule works only for GDS Sirena Travel and Travelfusion, in turn, the setting +requisite pacages Numbers from Websky is applicable for packages of all GDS.
Examples of search request filtering rules
Example 1. Stop searching for unpopular destinations
To interrupt the search for unpopular destinations with departure/arrival points in Alicante or Heraklion, and the departure/arrival point could be anything, create two exclusion rules.
| Filtering rule №1 | |
|---|---|
| Restrict search if the airport of departure is Alicante or Heraklion. | |
| + departure airports | Выбранные:
|
| + check directions (legs) | Все |
| Filtering rule №2 | |
| Restrict search if the airport of arrival is Alicante or Heraklion. | |
| + arrival airports | Выбранные:
|
| + check directions (legs) | Все |
The table shows the work scheme of filters №1 and №2 for each flight in search results.
| Work scheme of search requests filtering rules | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The table shows the joint result of the work of filtering rules №1 and №2 for each flight in the search results. The "Filtering purpose" column shows the correspondence between the actual work of filters and the expected results.
| Joint working result of filters №1 and №2 | |||||
|---|---|---|---|---|---|
| № | Departure airport | Arrival airport | Search Request | Filtering purpose | |
| Flight 1 | Alicante | St. Petersburg | The search will stop | True | |
| Flight 2 | Alicante | Yekaterinburg | The search will stop | True | |
| Flight 3 | Alicante | Heraklion | The search will stop | True | |
| Flight 4 | St. Petersburg | Alicante | The search will stop | True | |
| Flight 5 | St. Petersburg | Yekaterinburg | The search will be performed | True | |
| Flight 6 | St. Petersburg | Heraklion | The search will stop | True | |
| Flight 7 | Yekaterinburg | Alicante | The search will stop | True | |
| Flight 8 | Yekaterinburg | St. Petersburg | The search will be performed | True | |
| Flight 9 | Yekaterinburg | Heraklion | The search will stop | True | |
| Flight 10 | Heraklion | Alicante | The search will stop | True | |
| Flight 11 | Heraklion | St. Petersburg | The search will stop | True | |
| Flight 12 | Heraklion | Yekaterinburg | The search will stop | True | |
As you can see from the table, we got exactly the result we expected: all unwanted search requests were stopped.
Why can't I combine conditions with the "Departure airport" and "Arrival airport" parameters in one rule?
If you create a general rule with departure and arrival airports, some unwanted search requests will not be filtered out.
| Filtration Rule №1 | |
|---|---|
| Restrict search if the airport of departure or arrival is Alicante, Heraklion. | |
| + departure airports | Выбранные:
|
| + arrival airports | Выбранные:
|
| + check the directions (legs) | Все |
The table shows the scheme of filtering operation with combined conditions for "Departure airport" and "Arrival airport". The "Filtering purpose" column shows the correspondence between the actual filter operation and the expected results.
| The working scheme of the filtering rule №1 | |||||
|---|---|---|---|---|---|
| № | Departure airports: selected (Alicante, Heraklion) I Arrival airports: selected (Alicante, Heraklion) |
Rule's working result | |||
| Departure airport | Arrival airport | Search Request | Filtering purpose | ||
| Flight 1 | Alicante | St. Petersburg | The search will be performed | False | |
| Flight 2 | Alicante | Yekaterinburg | The search will be performed | False | |
| Flight 3 | Alicante | Heraklion | The search will stop | True | |
| Flight 4 | St. Petersburg | Alicante | The search will be performed | False | |
| Flight 5 | St. Petersburg | Yekaterinburg | The search will be performed | True | |
| Flight 6 | St. Petersburg | Heraklion | The search will be performed | False | |
| Flight 7 | Yekaterinburg | Alicante | The search will be performed | False | |
| Flight 8 | Yekaterinburg | St. Petersburg | The search will be performed | True | |
| Flight 9 | Yekaterinburg | Heraklion | The search will be performed | False | |
| Flight 10 | Heraklion | Alicante | The search will stop | True | |
| Flight 11 | Heraklion | St. Petersburg | The search will be performed | False | |
| Flight 12 | Heraklion | Yekaterinburg | The search will be performed | False | |
The search will be interrupted only if both the airport of departure and the airport of arrival coincide with the values specified in the rules.
If you specify both conditions (departure and arrival airports) in the same rule, you need to specify departure from Alicante or Heraklion and arrival in Alicante or Heraklion at the same time to fulfill the rule. Search requests in which only one airport (either the airport of departure or the airport of arrival) matches the filtering rule will not be filtered out and will be interrupted.
Example 2. Prohibit search in all directions, except allowed
With the help of search filters, you can prohibit all searches except for those in the areas of interest.
Suppose that search should be performed only for specified directions:
- Moscow → Saint Petersburg.
- Moscow → Yekaterinburg
- St. Petersburg → Moscow
- "Yekaterinburg" → "Moscow
- Yekaterinburg → St. Petersburg'
- Yekaterinburg → Tambov
- Tambov → Moscow
First, you need to disable search in all directions using the next disable filter:
| Filtering rule №1 Restrict search for all continents: | |
| Departure Continents | Selected:
|
| Check directions (legs) | All |
Then you need to allow searching in the required directions using the following resolution filters:
| Filtering rule №2 Allow the search if Moscow is indicated as the airport of departure, and St. Petersburg and Yekaterinburg are indicated as the airport of arrival. | |
| Departure airports | Selected:
|
| Arrival airports | Selected:
|
| Check directions (legs) | All |
If you leave only these two rules, the search will be started in the directions:
- Moscow → St. Petersburg
- Moscow → Yekaterinburg
In order to generate a target list of allowed directions, it remains to allow other required directions.
- Filtration rule №3 allows search by the direction St. Petersburg/Tambov → Moscow.
- Filtration rule №4 allows searches by Yekaterinburg → Moscow/Saint-Petersburg/Tambov.
| '"Filtering Rule №3"' Allow the search if St. Petersburg or Tambov is indicated as the airport of departure, and Moscow is indicated as the airport of arrival. | |
| Departure airports | Selected:
|
| Arrival airports | Selected:
|
| Check directions (legs) | All |
'"Filtering rule №4'". Allow the search if Ekaterinburg is specified as the airport of departure and Moscow, St. Petersburg or Tambov is specified as the airport of arrival. | |
| Departure airports | Selected:
|
| Arrival airports | Selected:
|
| Check directions (legs) | All |
Enable New Websky (Nemo Connect) Search Filters
Nemo Connect Search Filters is an improved version of Websky Search Filters. The new module supports an extended range of features and is notable for its performance. New Websky Search Filter does not require manual entering of rules, the filter uses rules of the Websky Search Filter module. After you enable the Nemo Connect Search Requests Filter module, synchronization is automatic.
To activate the Nemo Connect Search Requests Filter module:
- Perform login to Websky administration panel.
- Go to Air Settings → Profiles → User Profile section.
- Select the user of the Anonymous agency (if filters should work for the main site) or another user inside the agency, for example, a specific user for metasearch, if you want to enable filters specifically for metasearch.
- Enable the Use request filters option.
- For correct work, make sure that the following fields are filled in the Websky Administration panel:
- in the Agency Profile section: parameter Agency ID in Nemo 1 - agency number assigned in the Websky Administration panel.
- in the User Profile section for the selected Websky user: the parameter Subject ID from external system - the number of the user/group/company in Websky. Websky search filters import for a selected user rules for filtering that user/group/company from Websky whose number is specified in this parameter. As a result, Websky sets rules for a user which are set for the object (=user/group/company) in Websky.
Attention! In case the installed request filters fail after cache reset and there is a
Reset Websky search request filters cache error, it is necessary to check the type of the installed environment in Websky settings section For technical support → Websky Web Services → Interaction settings in the option Environment in use (Settings and Statistics server). If the environment you are using does not correspond to reality (e.g., a test environment is installed for a real agency), correct the setting value. Next, re-save the installed filters to Websky!
