Geofencing in Hybris: Custom Shipping/Sourcing Zones
A geofence is a virtual perimeter or a fence around a geographical real-world area of interest. In e-commerce, these areas can be used for different purposes, from personalization to delivery cost or time calculation.
One of the real examples from my previous e-commerce projects is about the warehouse selection strategy. It used the customer address data to determine the most cost efficient way to source the product and move it to the point of sale for a local pick up or deliver to the customer address.
When the product is available at warehouse A, there is no problem at all – that warehouse is nearest to the customer. However, if the product is only available at other warehouses (for example, warehouse B), the cost of moving the product to the customer location or local store for pick up, may be too high for the seller. In that project, the delivery price is always fixed for all products, all customers, and all regions served.
The simplest way to deal with customer and warehouse locations is using postal codes.
However, this approach is not good for the following reasons:
- Using tables makes the system too complex in terms of management. Generally, postal codes cover the relatively small areas. In order to define the warehouses and delivery areas using the postal codes, you will need to deal with a really huge amount of data. Using primary and secondary warehouses doubles that.
- Using business rules doesn’t help here because the postal code system is generally too simple. You can’t group postal codes together by the delivery cost just because all these areas are close to each other. Some postal codes shouldn’t be grouped because there is a river between them and no bridges nearby.
Geofencing helps with the task. Using the simple tool you can mark areas on the map and process these areas differently. All customer locations inside the marked areas will be treated similarly. If you need to add an exception, you can create a new polygon and put it on the top of the existing. For any single address, you will have a list of areas. For the example above, there are two areas – red and black. All warehouses linked to the red area are primary for all customers inside this area. All warehouses linked to the black area are secondary for red area customers and primary for black area customers.
There are three components in the system:
- Storefront geofencing module
- Geofence editor
- Geofencing API
Storefront geofencing module is integrated into the customer address form. When the customer creates or updates the address, the following operations are performed:
- Geocoding. The latitude and longitude are calculated for the address. The Google Maps Geocoding API is used to get a latitude/longitude point to determine at the next phase if it is within one of your fences. Take into account that there are usage limits in the free version of Google Geocoding API, namely 2,500 free requests per day and 50 requests per second.
- List all fences that contain the point. Geofencing API is used for retrieving the fences. Geofencing API is a service component of the solution.
The list can be used in the various components, such as
- Delivery cost calculation
- Product availability
- Product price
- Delivery price
- Taxes etc.
Geofence editor is a Google Maps based web application that uses Geofence API for storing and retrieving data. Using the geofence editor you are able to:
- Create a polygon to define the area
- Name the polygon and save it
The editor is frontend-only, it uses Geofencing API for uploading fences to the server and read them from there.
The architecture involves the storing, indexing, and serving of complex fences. Each fence is represented as a polygon along with some metadata. The key function of the API is finding all fences a certain point is in.
This process isn’t actually as straight forward and, depending on the complexity of the fences, can include some intense calculations. That is why Google AppEngine is used for the API. The following components of Google AppEngine are used in the module:
The code itself and the data are hosted in the Google Cloud. Depending on the complexity of the fences, more or less resources are needed for the calculation. For the most e-commerce related cases, the basic configuration is enough.
These are the interfaces in the API:
- Adding fences to the Google DataStore collection.
- Listing all fences from Google DataStore
- Getting a fence metadata by its id
- Building and storing the index to memcache
- Finding all fences a certain point is in
- Finding a fence that intersect with a polyline.
- Finding a fence that intersect with a polygon.
For the last three operations the Java Topology Suite is used. Memcached is used for fast querying in a spatial index. The solution uses a STR-Tree (part of JTS) which is stored as a Java Object in memcache for fast access.
API is based on REST. Requests and responses are JSONs.
<iframe src=”https://player.vimeo.com/video/187942811″ width=”640″ height=”360″ frameborder=”0″ webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>
© Rauf Aliev, October 2016