/
Analysis impact of changing autocomplete parameters

Analysis impact of changing autocomplete parameters

The solutions proposed to reduce the current delivery errors that might happen in the platform today require adjusting parameters in the Google auto complete API used for address predictions. This is a delicate topic since results are subjected to a degree of randomness and it is unfeasible to cover all possible scenarios in manual tests.

This document aims to validate the impact via an exploration of the proposed changes and analysis of amplitude data to check how the customer experience will change.

In summary, the changes are:

  • Restrict autocomplete predictions to addresses

  • After the user has selected a street, include a bias in predictions to give a heavier weight to results close to the current location

More details are giving for each parameter in the following sections.

Restrict autocomplete predictions to addresses

The AutocompleService used by the white label has the option to restrict results to certain types defined by the API. The full list can be checked in this table. If no type is included, all of them are considered valid.

Currently, the customer “select your address” page doesn’t have any restriction, allowing results such as “Madrid, Spain”, while the search on the “confirm your address” page is restricted to address types:

image-20240821-185340.png

However, the removal of the street name input requires we no longer accept addresses without a street name, a problem that can be fixed by making the type restriction apply to both searches. From the docs:

image-20240821-190123.png
Table 3: Type collections supported in Place Autocomplete requests

Data exploration

To check the impact, I’ve gathered real data from amplitude to analyze how the search predictions will change for real-life scenarios. Using the “Manual Location Search” we can check what text the user has typed in the search bar (searchInput) and what prediction they selected (selectedAddress). The table below contains the example for five PROD customers searches and compares the current predictions with the new predictions after the inclusion of the address restriction.

searchInput

selectedAddress

current result

new result

searchInput

selectedAddress

current result

new result

Calle Dionisio Acedo

Calle Dionisio Acedo, Cáceres, España

 

 

 

 

Calle Carrero Juan Ramon 2

Calle de Carrero Juan Ramón, 2, Madrid, España

 

 

 

 

C. de carabel

C. de Carabelos, Madrid, España

 

 

 

 

Sevilla

Sevilla, España

 

 

 

 

Del jacobeo

Calle del Jacobeo, Madrid, España

 

 

 

 

Although these five are a small sample, as expected we can see that the prediction will show fewer results than previously. More importantly, in the 4th example we can see I customer searching by city, an use case that no longer will work.

Related content

[Solution] Reduce delivery address errors - core
[Solution] Reduce delivery address errors - core
More like this
[Solution] Reduce delivery address errors - enhancements
[Solution] Reduce delivery address errors - enhancements
More like this
Tech Refinement - Reduce Delivery Address Errors
Tech Refinement - Reduce Delivery Address Errors
More like this
[Opportunity] Reduce delivery address errors - enhancements
[Opportunity] Reduce delivery address errors - enhancements
More like this
[Opportunity] Reduce delivery address errors - core
[Opportunity] Reduce delivery address errors - core
More like this