Finding the sweet spot for your sensors is a challenge in many IoT projects. Collect too little data, and there isn’t enough to act on. Collect too much data, and the costs might jeopardize your project. So, where is the sweet spot for your application?
Goal
A retail store chain was looking for an affordable retail analytics system. It needed to track people’s movements to help improve the store layout and learn more about customers’ shopping behavior. The solution had to be easy to deploy, be discreet and not require any changes from shoppers. The solution was designed on the fact that most shoppers would have mobile phones, which could be used as an approximate count for the number of people in the store and could also help track their movements as they moved from one Wi-Fi hotspot to another.
A “People Sensor”was designed using the principle that mobile phones share their MAC address with Wi-Fi hotspots as part of the “handshake process” in order to obtain connectivity. ( MAC addresses are not associated with a specific individual or a mobile phone number, helping to preserve privacy. ) The sensor was built by modifying the firmware in low-cost Wi-Fi routers to count the number of MAC addresses from phones in the vicinity requesting connectivity and then send this information to the cloud for analysis. The People Sensor works in conjunction with existing Wi-Fi routers in the store, which provide shoppers with Wi-Fi connectivity and also the means to send sensor data to the cloud.
Initial Design
The initial rollout was planned for 100 stores with five People Sensors in each store continuously transmitting the count and movements of the people nearby. The size of each sensor data file fluctuated with the number of people nearby, but it averaged about 2 Kb.
The system worked technically as expected. But despite the small file size, the operating costs were much more than expected. The cause of the high cost turned out to be the frequent write requests (PUTs) to update the sensor data in AWS S3. Back to the drawing board.
SkilledAnalysts.com Refinements
A survey of the store managers showed they could accept reports on a shopper’s presence and movements with an interval ofevery minute rather than continuously.
The People Sensor firmware was modified to store MAC addresses from incoming connection requests rather than immediately forwarding this data to the cloud. Duplicate MAC addresses (resulting from shoppers’ phones making multiple connection requests in the one-minute sample interval ) are filtered to reduce the size of the data file being transmitted. Every minute the information stored in the People Sensor is transmitted to AWS and the local cache is cleared for the monitoring cycle to begin again.
SkilledAnalysts.com After further modeling with the AWS S3 calculator, it was clear that the sweet spot where reporting accuracy was preserved and costs didn’t balloon out of control was to have the sensors report by the minute. Reporting less often didn’t provide enough detail to the store managers, and reporting more frequently drove up the costs too much.
In this way the solution was refined to keep both the store managers and the finance department happy.
It pays to find your application’s sweet spot so you are optimizing for both business utility and cost.
This article is published as part of the IDG Contributor Network. Want to Join?
