Retail supermarket now knows what visitors buy and can propose tailored recommendations
This pilot project with using location trackers to analyze visitors behavior was implemented in two supermarkets with a large store traffic. The Head of the IT Department represented the supermarket and provided all permissions to install and maintain the pilot project.
Therefore we had permission for external connection of our system to supermarket FTP and their server systems, where all checks of the supermarket were recorded, allowing us to use these records.
The Idea
The key idea was to send targeted promotional offers to supermarket visitors. These could be long-term or short-term offers, sent out whenever the supermarket needed to encash some selected products asap.
Initially, the main task was to obtain information from each buyer’s check. Later this information formed a common database of product preferences for thousands of shop customers.
In other words, the buyer would choose a range of goods, pay for them at the checkout, and 30-40 minutes later we would have the information about their purchases at our service.
The technical idea was to install equipment directly at the entrance to the retail space. The intention here was to track the entries of regular customers.
The key idea was to send targeted promotional offers to supermarket visitors. These could be long-term or short-term offers, sent out whenever the supermarket needed to encash some selected products asap.
Project implementation flow
Visitor enters the store. His card was scanned by the reader at the entrance, but, as it turns out, we know nothing about him, – there is no information. But just the point is that after this “clean” visitor makes a purchase, our cloud is updated in up to half an hour with this visitor data – and we have the feeling of his buying preferences.
- Visitor enters the store. His card was scanned by the reader at the entrance, but, as it turns out, we know nothing about him, – there is no information. But just the point is that after this “clean” visitor makes a purchase, our cloud is updated in up to half an hour with this visitor data – and we have the feeling of his buying preferences.
- We then process this information and save it in a common database. We are creating a large group of user profiles, allowing us to work with big data.
- For example, if the customer X purchases milk of a certain brand, and then buys yogurt produced by the same manufacturer, then it is recognized as part of the dairy products group. In turn, this group of dairy products can be compatible with other groups of goods for various reasons (the information is analyzed by us). This means that we can send an offer of, for example, smoked meat to buyer X, and we can be confident, based on our extensive analytics, that the client will buy this meat with a probability of 70%.
- Probabilities are calculated after examining millions of checks. In this way we identified certain interconnections between purchases, as that was important for us to maximise sales.
- The concluding stage of this whole process is the offer itself, the promotion. When customer X visits the store a few days later, we already know which offer to send them (if such a proposal has been prepared by the marketing department, of course).
The Notifications Server receives data non-stop from the Marketing Promotion Server, so all new offers from the supermarket that need to be shown to a certain group of visitors with cards are deployed at the right moment.
Visitor enters the store. His card was scanned by the reader at the entrance, but, as it turns out, we know nothing about him, – there is no information. But just the point is that after this “clean” visitor makes a purchase, our cloud is updated in up to half an hour with this visitor data – and we have the feeling of his buying preferences.
Marketing Behind the Service
The marketing department sends us the data for about 2000 items. Typically, the marketing department puts a certain time frame on when to advertise a certain group of goods.
For example, buyer Y enters the store and, taking into account our analysis of their past buying behavior, we can come to the conclusion that they like wine and chips. We transfer this information to the Marketing Promotion Server. Then the specialists of the marketing center look at whether there are any product offers available that could be advertised for the Y-visitor. The center forms the text of the advertising message, gives a signal to the Notifications Server and finally sends a message to Y with an advertising offer. The point is, the marketing service knows which offer to send. Simply put, one offer might be designed for milk lovers, while another could be sent out to fish fans.
The Marketing Promotion Server worked on the basis of Node.js in conjunction with MongoDB. It also kept all the information that the supermarket shared about advertising companies.
Next the frequency algorithm comes into the foreground – to whom do we show messages more often, to whom less frequently? In order not to annoy advertising to those buyers we sent messages often, we slow down a little and send only to those who received our messages rarely.
The marketing department sends us the data for about 2000 items. Typically, the marketing department puts a certain time frame on when to advertise a certain group of goods.
Technical implementation
High-piercing readers were installed over the lanes in supermarkets; initially we used RQ3 RFID readers. Supermarket visitors had loyalty cards with unique RFID tags. The card itself was applied at the checkout when making purchases for a certain amount, or according to any other commercial program.
As a result, when a prospective buyer entered the supermarket, we already had their information on hand.
The idea was to immediately transfer all commercial store offers to cell phones and apps. However, this would significantly reduce the number of visitors who could use it. This situation raised the bar: we needed to implement the best solution so that elders could also use the commercial mailing. So the supermarket’s challenge to us was to cover at least 60% of all standing customers to the store.
Accordingly, the mass communication channel was to be premised on SMS or USSD notifications.
A visitor would enter the store and their card would be scanned with a special reader. Our server would then receive a signal (via the application based on Node.js, which was replaced with Python), raising the question of whether or not a promotion would be useful in this case. Was there a pattern for the customer or not? … If there was an offer for the buyer, they would receive an SMS.
Where was all the data stored?
We used CouchDB for the data storage. Later we changed the system to Couchbase for more convenience.
How was the work of the microservices organized? The processing of data, so-called profiles, templates and patterns that belong to users – this module worked directly with the database and also analyzed its data. Here we used a combination of logic + Python + Couchbase. That is, the MTP protocol was installed – external services were communicating with it, and a regular external Restfull API based on Node.js was installed. It received all requests from the tags coming from our Arduino servers, which passed through 3G channels. The task of the RestFull API was just to get data and nothing more. Here it transferred the information via the MTP Protocol to the storage.
In other words, there was a certain number of tasks, and the service that worked with the database received them as the queue for processing (que), where all tasks were processed synchronously.
The notification server was connected to Twilio, as well as to push Notifications server. Its task was to get the cell phone number or UID of the mobile device and send the designated text.
We had a connection to the Python service on the background, which connected periodically to FTP Node.js servers, and uploaded hundreds of thousands of records and extra hashes. About a million records were uploaded and stored in the Couchbase. Once an hour it processed a certain amount of data to create a certain group of users with the clear preferences of customers.
We used CouchDB for the data storage. Later we changed the system to Couchbase for more convenience.
The Next Stage Of Integrating And Testing
At the second development stage we were to install more readers in different zones to send the bundle of offers. The key goal, as set by the supermarket, was to provide the promoters with additional communication channels without the advertising load on the trading space.
The supermarket management wanted to see how effective this advertising campaign would be in comparison to alternative marketing methods (for example, banners, leaflets, etc.).
We needed to track how the advertising message affects the result of the purchase. For example, advertising messages with the hypothetical text “buy sausage” was sent to about 10 thousand potential customers in a certain period. It was necessary to calculate how much sausage was sold during this period, compared with the previous results. Depending on the results obtained, we could draw out certain conclusions. An analogy to the online Cost-Per-Action model in the Internet could be applied here where client only pays when specific actions were performed by users/visitors.
To test this phase, 20 supermarket visitors were given RFID tags, and their task was to simulate the behavior of ordinary visitors to the supermarket.
Summary
While this may sound futuristic, visitor oriented recommendations/promotions will appear in every big retail supermarkets in coming year. Amazon already proved that many processes in retail can be automated with their Amazon Go stores. Visitors attention and loyalty is the “gold chest” modern companies are now competing for.