David Bliss from Nurun San Francisco and Steve Tremblay from Nurun Montreal also contributed to this article.
After disrupting the retail industry with online commerce, the digital world is now attending to the more analog side of retail: brick and mortar stores. Retailers are rushing to bring real-world versions of online features into their physical retail spaces. The early adopters are already innovating with concepts like shopper analytics, endless aisles and virtual mirrors.
While thinking about such innovations and the possibilities of digital in store, our corporate innovation team and our San Francisco office collaborated on prototypes leveraging existing technologies, integrating them together to provide social features and services to customers within physical stores.
Our goal was to identify core social features taken for granted by online shoppers, and bring them into the experience of the offline store. We were looking for opportunities to integrate these features into the physical space, extending beyond the customer’s mobile screen.
The results are two prototypes for media shoppers (music, TV and film) built on top of a recommendation engine powered by online store data.
Behind the scenes
As you could understand from our eCommerce background, our first ideas were to offer our customers more in-store services that were related to features offered on retail websites. The two recommendations that first came to our minds were those typically seen online:
- Based on a product itself, customers who bought this product also bought…
- Based on a customer’s past purchases, similar shoppers also bought…
In a complete eCommerce architecture, those kind of recommendations often come from large and reliable engines used by large scale retailers. In our case, we needed something simple that could analyze tens of thousands of purchases made recently in a store, or a group of stores, and recommend products to customers.
To reach that goal, we implemented a simple database using Redis, a key-value store that leverages the typical datasets available in the most efficient way. By creating sets of customers and their purchases, we were able to implement a quick and efficient recommendation system that could easily push similar products and clients to our customers.
As previously mentioned, this database is used to provide two kinds of recommendations that are typically made in a store by a sales representative. As you’ll see in the other components, those recommendations are used in our apps to provide customers with relevant results based either on a product they have in-hand or by providing their client membership card and asking for recommendations based on past purchases.
For the techies out there, we tried the database on both Redis To Go cloud service and local implementations using a layer of PHP built services to communicate between our apps and the Redis database. The performance level required to scan through our database of purchases quickly drove us toward a locally-hosted solution for the prototype, but different requirements could perform better on the cloud platform.
In the Store
For inside the store, we’ve built two prototypes to leverage the recommendations. The first is a Kiosk that can be used by shoppers to find product recommendations, ratings and reviews. The second uses information beacons to identify and locate specific specials that are recommended for a shopper in the store.
Our goal for the Kiosk was to make it easy for shoppers to find products of interest and to leverage both the recommendation engine and social features to do so.
The basic function of the Kiosk is to provide quick access to product information that shoppers have grown accustomed to from shopping online. This includes ratings and reviews from product owners, related products and special offers. In addition, members of the store’s loyalty program can access personal recommendations by scanning their membership card.
Ideally, these Kiosks would be situated throughout the store, readily available to shoppers at any time. Rather than standalone computers and touch-screens, we envisioned a deployment using inexpensive Android devices and a custom accessory built using Arduino and Google’s accessory development kit.
To create an experience appropriate for a store, we have made some changes to the way tablet applications usually work:
- The tablet is connected to a barcode scanner that can scan membership cards and products in the store. Scanning a card pulls up items recommended for a particular customer. Scanning a product pulls up similarly recommended products (customers who like this also like…)
- Each product displayed on the tablet is accompanied by a QR code linking to a mobile version of the website page which allows the user to leave the kiosk and continue browsing while walking around the store.
- A printer is connected to the tablet, allowing shoppers to print information about the products they are interested in.
To ease development, we developed the application targeting Honeycomb 3.1, which is the minimum to support both recent tablets and Google TV. The minimal Android version our project required was Android 2.3.4, which is the earliest version to support the USB Open Accessories Protocol used by our scanner and printer.
From a code standpoint, the application is pretty simple. Apart from the connection with the accessory, nothing out of the ordinary powers the application.
To connect to the USB accessory, the application declares that it wants to be opened when our custom accessory is connected to the device through an intent-filter. When a USB accessory is connected, the application is opened automatically.
Technical side note: This intent filter can only be associated with an activity. This means that only the activity receives the Accessory Connected intent. If you are using a service registered as a broadcast receiver, this service will receive every USB-related intent except this one. The trick we used was to forward the intent to our service through the activity associated with the intent filter.
Once connected, the USB accessory can send commands to the application while it is running, no matter what screen is opened. For example, when a barcode is scanned, the accessory sends a command to the application and the application switches to the correct screen in response.
The application can also send messages to the accessory. In this way, the thermal printer can be used to print information about the products of interest. For the prototype, the information includes the product name, a map to find it within the store and a coupon to further entice purchase.
The Kiosk application is in no way a technical challenge. On the contrary, it shows how easy it is to interact with USB devices, even when they are custom made. To learn more about working with USB accessories, we recommend Google’s documentation on the topic.
Creating the accessory itself was also fairly straightforward. We used the Arduino ADK controller and version 2 of the USB Host Shield Library. Version 2 of the library is needed to create an accessory compatible with version 2 of the ADK (used by Jelly Bean). With these correct libraries in place, messages are managed on the Arduino in the same way they are for serial ports.
By creating a custom accessory, we are able to extend the built-in features of the Android tablet. For this prototype, we’ve added a barcode reader and a small thermal receipt printer. Further ideas could allow the tablet to respond to motion (turning on as customer’s approach) or control lighting of nearby product.
Another intention we had was to improve the connectedness of the experience when walking inside the store. The idea is that the user could use a mobile application to see the closest items that they are interested in or that have been recommended.
To achieve this we have built an iOS application that uses Bluetooth Low Energy technology to communicate with beacons positioned everywhere in the store.
Each beacon broadcasts a Bluetooth Low Energy advertising packet that contains the beacon’s identifier (think of it as the device broadcasting its name to its environment). This advertising packet is broadcasted very frequently and can be used by the application to determine the closest beacon to the user by using the Read Signal Strength Indication (RSSI) of the beacon. The closest beacon’s identifier is used to retrieve relevant products from the back-end and the items are shown in a list.
The beacons are made with Arduino Leonardos paired with BLE Shields from RedBearLab. By default the shield supports a two-way communication channel (tx/rx) between the Arduino and an iOS device with BLE support. Once the devices connect, they can exchange messages in text format (like a standard serial connection). We modified the configuration of our radios so that each has a unique ID within the advertising packet, allowing us to identify each beacon without connecting the devices. This is more efficient in terms of both time and battery consumption.
A modest starting point
These Store Club prototypes demonstrate how fairly simple technologies can be used to bring online shopping features to the in-store shopping experience.
However, they only just begin to scratch the surface of the potential available to retailers who want to integrate the benefits of digital services within their physical stores.
At Nurun, we’re looking forward to a future where the distinction between online and offline shopping is continually blurred.
More Tech articles from Business 2 Community: