A spell correction match occurs when a suggestion corrects a misspelled query. This match only applies when there are no suggestions for the original query, or when the user intent clearly is satisfied by the autocorrected suggestion (4.1.5 Spell Corrections).
Query: Gouds
Result 2:
Gouda, Nederland
Type: Address
In this example, the query is “Gouds” and the viewport is centred on the city Gouda. While there are several addresses and POIs that match “Gouds” directly, Gouda is a prominent city and the “S” is located right next to the “A”. In this case, , , .
the result for Gouda would fix an obvious typo.
In The Netherlands, the QWERTY keyboard layout is by far the most common.
When looking for a possible spell correction, it is important to keep this in mind.
Unlike in Search tasks, in Autocomplete tasks we don’t know if the user has entered the full query. For example, if the user enters the name of a town or city, there can be many other matches, like streets and POIs that also match the query. These are less prominent, but they might include what the user actually is looking for (4.2 User Intent).
Query: Amsterdam
Result 2:
Amsterdam Centraal
Amsterdam, Nederland
Type: Business
In this task, the query is “Amsterdam”. The first result is the city Amsterdam, which is a very prominent city and is the primary user intent. The second result is Amsterdam Centraal. This train station isn’t as prominent as Amsterdam, but it still matches the query and could be what the user is looking for. This station is a secondary intent, and Relevance should be demoted to Good.
Query suggestions are suggestions that give the user a completed query. Relevance for these suggestions is rated based on the results the query provides within the viewport. It is not enough for a query suggestion to match the query (4.13 Query and Category Suggestions).
Query: Bize
Result 2:
Bizet
Type: Query
In this example, the query is “Bize”. This is a short query with several matches. The closest match and most likely user intent is the street Bizetstraat, which is near the user.
The result is a query suggestion for “Bizet”. While this query suggestion matches the query, there are no results for this query anywhere near the viewport. The closest result for this completed query is a square named Bizet, which is over 30 km away from the viewport. For this reason, Relevance is demoted to Bad.
Relevance is always rated independently of data accuracy. If an address does not exist, relevance should be rated as if it did exist. However, the non-existing address does not affect the rating of any other matches that do exist (8.1.1 Address does not Exist)
Query: Hortensiastraat 175
Result 3: Hortensiastraat 175, Enschede, Nederland Type: Address
Result 4:
Hortensiastraat 175B
Wezep, Nederland
Type: Address
In this task, the query is “Hortensiastraat 175”. This is a pretty straightforward
query for an address. If we do some research and look for possible matches, we can see that there are only three possible matches for this query.
Result 4, which is located in Wezep is for an address that does not exist. Even though the address does not exist, relevance should still be rated as if it did exist. Because there is one existing match in Zwolle, which is a bit closer to the user, Relevance is demoted to Good for distance.
Result 3, which is further away in Enschede, is actually the second closest existing address. Relevance is also demoted to good for distance and it should not be demoted further because of result 3, because this address doesn’t exist.